I appreciate how the author presented an alternative strategy rather than just bitching. I completely expected the rant to be the end of it, and was pleasantly surprised.
I run into a similar issue around functional programming and FP evangelism.
It’s common for us, in extolling the virtues of functional programming, to show a 15-line imperative solution and a 2-line functional solution and assume that the case is already made. It’s shorter and it doesn’t have “state”. FP wins! Well, not necessarily.
First of all, peoples' aesthetic tastes in programming languages are heavily informed by what they’ve done in the past. Second, the 15-line imperative program is perfectly fine. State isn’t evil; it’s badly managed or unexpected state that causes problems. It’s at the 1500-line scale that standard OOP tends to break down.
Functional programming is worth learning, and it will (if used by competent programmers) make the code quality better in the long run, but at the small scale, what’s going to look best (and what a programmer would actually use) is what’s familiar, not what’s going to perform better at 100 kLOC.
I have a theory, which I think I may have actually cribbed from someone else but can’t remember who, that in the case of FP this is partly driven by the context of paper writing. There are usually two things you have to demonstrate in a PL paper adding a new feature: 1. this feature works, and 2. this feature is worth having. You demonstrate #1 with various kinds of proofs; we show that the resulting type system is sound, typechecking is decidable, etc. But how do you demonstrate #2, which secretly is what people actually want to know, even though #1 might be the formal “result” of the paper? Usually through a compelling example, or a few examples, which have to be small enough to fit nicely in a figure.
The real problem here is that you need 10 or so years to find out whether the tool works for large-scale and long-term projects. Until then, even the author of the tool himself can at best make an informed guess.