A Tantrum Is Not a Software Design Principle

Published at 09:11 on 16 June 2022

Or rather, it should not be considered one. Alas, sometimes it is.

I first ran into this when I encountered the Git revision control system. It was just so disheveled, haphazard, counterintuitive, and disorganized compared to the older revision control systems I was used to. It was even so compared to other “third generation” systems like Mercurial. It still strikes me as such, and is the main reason I self-host my personal projects using Mercurial.

Then I read that a major inspiration for Linus Torvalds to write it the way he did was just to be different from CVS, because he hated CVS. Design by tantrum, in other words.

Around a decade ago I became aware of the then-experimental Go programming language. A lot of it sounded like precisely what is needed: a more modern language than C++, without all the design cruft caused by attempting to graft a modern object-oriented language onto a non-OO systems programming language from the 1970’s, that compiles down to machine code for fast execution.

But, wait. No exceptions, despite how useful they were. No generics (a deficiency that has been fixed). No conditional expression. No support for functional programming. And, due to overall design choices, no easy way to add such support. It all forced one into a very staid, unimaginative, and limited-productivity imperative programming style.

Now I read that one of the motives for making it all that way was that the language’s designers all hated C++ (I can’t blame them) so decided to make the language as unlike C++ as they could whenever faced with a decision they couldn’t sort out via alternative principles. More design by tantrum.

Not everything about CVS was bad. Just because CVS organized its commands and concepts the way it did does not make this organization bad. CVS’s problems lay in a centralized design and poor support for branching and merging. Its overall paradigm organization was actually pretty good. Unfortunately, a temper tantrum about the bad parts of CVS prevented Git’s author from appreciating its good aspects.

Likewise, not everything about C++ is bad. Just because C++ has some feature whose absence can be coded around does not mean said feature is harmful and should be deleted. C++ was, after all, motivated by a very real desire to make C into a more powerful and expressive programming language.

The problem is that choosing to focus on how bad something is can easily get one into a mindset that prevents appreciating the good aspects of it.

Resolved: while disgust at the inadequacies of some existing software system will always serve as the inspiration for attempting to create something better, a tantrum should not be allowed to be a design principle.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.