Just to be a difficult fellow, I recently changed from the venerable-and-fiendishly-complex ZShell to the lightweight, spiffy and pretty Friendly Interactive Shell.

It made me realise a few things. Primarily that shell development has been hamstrung by the perceived need to remain compatible with Bash, so while shells have become better, they’ve kept using ugly/outdated syntax, had awkward structures and been stuffed with unnecessary features.

The Fish design document has some interesting commentary on all this. Several things stand out to me, firstly the “law of orthogonality”:

The shell language should have a small set of orthogonal features. Any situation where two features are related but not identical, one of them should be removed, and the other should be made powerful and general enough to handle all common use cases of either feature.

Secondly the “law of minimalism”:

The shell should only contain features that cannot be implemented in a reasonable way outside of the shell. A large performance decrease, as well as some program complexity increase is acceptable in order to improve separation..

Both these principles are strongly compatible with development in Ruby, where consistency, readability and structural/syntatic elegance are prioritised over performance or mathematical elegance.

Thirdly (and my favourite), “configurability is the root of all evil”:

Every configuration option in a program is a place where the program is too stupid to figure out for itself what the user really wants, and should be considered a failure of both the program and the programmer who implemented it.

Again, this meshes nicely with Ruby and Rails development. Ruby is what is termed “opinionated” software: it has strong implementation preferences and sensible defaults, explicitly discouraging manual configuration or non-standard implementations. One of the benefits of this is that consensus around best-practice can be formed (and enforced) more readily, and the overall Ruby code-base is much more consistent than that of other languages.

While these principles obviously only apply to specific families of development (although I suspect cases where they don’t apply are relatively specific; firmware, banking, etc), they’re very valuable in the right context. Software development has inherited a specific set of practices and concerns from previous generations of developers: but many historic problems are no longer concerns, and I think many historic priorities have proved to be long-term detrimental. This is partly a consequence of technological improvements (better languages, hardware, etc), but also I think a function of collective experience.

Garbage collection, dynamic typing, mutability and introspection are all code concepts that caused consternation when first introduced, but it’s become clear over time that the potential issues with these were over-emphasised, and the benefits of using them in the right contexts are large.

My favourite comparison is between SOAP and REST. While in an abstract sense, SOAP might be argued to be a more complete/extensive/engineered solution, REST is much more functional: being lightweight, simple, easy to implement and more elegant. As a consequence, since the introduction of REST there has been a proliferation of APIs using it: which are consistently formatted and have a low barrier to access. SOAP is characteristic of a previous generation of software design, whereas REST is fairly typical of more modern practices.

Obviously, like I stated above, these principles and changes only apply in some contexts, and there are many problems that need low-level solutions: but for the most part they’re quite sound.

This is mostly an exercise in making fun of Java