Key bits of the world's infrastructure still run on a bunch of flimsy shell scripts that seem like they'd break all the time but don't. If a computer program works reliably at all it will probably work reliably indefinitely, assuming the environment it lives in does not change substantially.
We probably all trust our lives to high end routers and medical equipment powered by shell scripts (or worse) every day. The code would scare you but, surprisingly, it will probably never fail you.
I'd say that it at least feels this way, because the "global state" in a shell program depends on a lot more properties of the system than the "global state" of a Python program. C/C++ or even entirely static binaries from Go for example (I'm not a Go expert) all eliminate state being 'imported' from the host machine.
They string together other programs with widely differing interfaces. For example BSD sed and GNU sed work very differently, at least when you accidentally use a non-standard option.
Ruby, JavaScript, Perl, Python, Java, C++ all have a stable base vocabulary (core library).
bash doesn't.
this is actually a really pragmatic set of hackers
that just hack on Ruby, hack on C and spend their
time working on more interesting things using a
more stable stack, rather than chasing after the
latest and shiny tech.http://shayfrendt.com/posts/upgrading-github-to-rails-3-with...
I definitely prefer working with a stack I know how to wield, and using it to solve problems. New things are good and useful, but having a focus means you can understand all the nuances that go along with it.
It's great to hear these core values are baked into their culture. I remember recently reading they were running Github pages on something like a pair of dedicated servers lol. Hats off, Github rocks.
Our team recently started using Jira for issues instead of Github ones. I have to say, if Github offered a $1 more per repo cost for better issue/wiki tier, I'd rather use that in a second.
OT, but has anyone else tried this? I've often fantasized about working while embedded in a beautiful nature setting, but I imagine it's tough to find good internet in such a place. I'm in California ... any recommendations?
I've also thought of copying Antony Garret Lisi's 'science hostel' idea [1] but for coders / entrepreneurs :)
[1]: https://en.wikipedia.org/wiki/Antony_Garrett_Lisi#Science_ho...
Otherwise you'll just be sitting there in your cabin reading Hacker News.
To be clear I think both approaches are excellent and all depends on the in-house talent, but nonetheless it's interesting to see how GitHub is sticking to a traditional, Rails-inspired document-based approach that minimizes front end complexity while other companies do not, even when both have similar UX complexity.
- a DSL for describing specifications
- the ability to mock functions and commands
- detailed, human-readable output
You can find some sample-tests in the spec/ folder (bash-specs eats its own dog food by testing itself ;)).
Dokumentation is lacking and the mocking is currently broken but both will be fixed within the next days.
As for static typing, agreed, though considering that shell is basically a scriptable FFI, real static typing would probably add a lot of complexity? Attempts at "typed shell" don't seem to go over well, maybe due to "worse is better" dynamics.
BTW, re: testing shell scripts: https://github.com/sstephenson/bats
I was less productive and equally happy. All existences become the norm quickly. Even living in a tropical paradise, or surrounded by snow capped mountain wilderness.
- Most people who write shell scripts really don't want to write a 'ps' or 'ip' (or for non-Linux, 'ifconfig') replacement. On the other hand, Python and Ruby have libraries that talk to /proc and the network ioctls directly.
- most shell script authors don't even use bash arrays, and higher level data types don't exist. It's hard to represent a C struct in shell. C libraries are therefore exposed to shell scripts by scraping their stdout.