Dorothy Parker said “It’s not the tragedies that kill us; it’s the messes.”
Sometime that’s how I feel about computing. I think of messes such as having to remember that arc tangent is atan in R and Python, but arctan in NumPy and a in bc. Or that C, Python, and Perl use else if, elif, and elsif respectively. Or did I switch those last two?
These trivial but innumerable messes keep us from devoting our full energy to bigger problems.
One way to reduce these messes is to use fewer tools. Then you know less to be confused about. If you only use Python, for example, then elif is just how it is. But knowing more tools is worth the added mess, up to a point. Past some point, however, new tools add more mental burden than utility. You have to find the optimal combination of tools for yourself, and that combination will change over time.
To use fewer tools, you may need to use more complex tools. Maybe you can replace a list of moderately complex but inconsistent tools with one tool that is more complex but internally consistent.
This is goes along with the concept of friction. Things like reading something and the grammar isn’t right. You slow down for an instant to figure it out, mentally say “Ah” and then speed back up. Spelling errors are in the same boat. Code is full of these things because the “rules” aren’t as simple as grammar and most likely shouldn’t be. Compiler weirdness aside, I wonder if programs written to specific rules would be bland. Or if the one hive mind of writing code would free programmers to do really cool things. (with the side benefit of easier maintenance)
This is why we have web browsers ready to search for “control structures Python” :-)
I switch between Perl and R, and on going back to the latter remembered that you *don’t* have to end lines in semicolons or put sigils on variable names.
To my mind, part of the price of doing business. Yes, it would be easier if everything were the same, but there is some boundary point where a certain language has a construct that helps, and other languages don’t. Not sure you can have one without the other.
This is the same kind of ideas as Ivan Illich’s Convivialité (I don’t know the English translation), saying the more powerful tools we have, the more they are focused on their own performance and much less on the user’s experience using them.
Today I had a similar thought when I struggled with sed to do a relatively simple task, forgetting the finer differences between regexes in sed and PCRE.
I finally got it right, but then whipped up a perl one-liner that did the trick. I later had another fight with awk, and similarly used perl to do the same thing with less effort.
Using perl to do one-off command line text manipulations usually works the way I expect it to, and I don’t have to spend time remembering the differences between basic/extended/other/perl regexes.
Tobi: Perl’s a good example of a complex tool that might replace a few other tools. Learning Perl takes a lot of work, but maybe less work than learning sed, awk, etc. and remembering their limitations.