Remove the Little Pessimizations

The single most useful tip I've ever received as a programmer is a bash alias from Damian Conway.

I already had a handful of bash aliases squirreled away in my .bashrc, but he showed off an alias called realias:

alias realias='$EDITOR ~/.aliases; source ~/.aliases'

By moving my aliases into a file called .aliases and adding source ~/.aliases to my .bashrc, I could use the new realias alias to write an alias in the same shell process. Instead of logging in and out of the shell (manually suspending and resuming any work in progress) or remembering to source the same file I was editing, I could add and use an alias immediately.

I now use plenty of shell aliases.

Only after the tiny pain of setting and using a new alias went away did I realize that the change was an optimization. Put another way, Damian's trick removed a tiny pessimization. Now I use these aliases all the time. I don't have to remember all of the command-line flags to invoke Callgrind or Valgrind in the proper way to profile Parrot or Rakudo. I use the cg and vg aliases. I don't have to remember how to build or publish a book in progress; I use a book-specific alias to build and upload the new version.

When I find myself repeating a complex command line and it's suitable for an alias instead of a script, I make an alias then and there.

Imagine what would happen if we could identify and remove other tiny pessimizations.

Modern::Perl is one attempt to do so. Whenever I use that module, I know what to expect. Whenever I see code which uses that module, I know what to expect as well. I can use say wherever I want without having to remember to use feature 'say';. I don't have to remember that the feature description of given/when is switch.

Yes, these are tiny little pieces of community knowledge that are easy to learn and reasonably easy to remember and they only trip me up for a second or two when I forget them, but sometimes removing a fraction-of-a-second pessimism is enough to keep my brain focused on what I really want to accomplish, not forehead-slapping minutiae related only to the expression of my desires.

Mark Fowler called it the simplest change that'll make the most difference. Adam Kennedy says productivity sometimes means saving ten seconds here and ten seconds there.

Does this apply elsewhere? Of course.

I have more to write about operator-oriented programming languages, but consider that even C has polymorphic behavior when adding integers and floats and Java's println method supports implicit stringification, if you look at it from one direction. Imagine if you had to be explicit about only being able to print (or concatenate) strings or if you needed a special operator to add numeric values with and without decimal components.

Now ask yourself this. What if, in Perl 5, hashes didn't have a single, global iterator? What if, in the Python shell, typing exit actually exited (at least if there were no symbol called exit bound in the current scope)? What if, in JavaScript, you didn't have to create a new function to get a new lexical scope? What if... I'm sure you have your own list.

I'm not saying that these changes are easy, nor that they're simple to implement, nor that there aren't valid compatibility reasons to proceed with caution. The world's not that simple.

Even still, if we're to replace badvocacy with real, working solutions, we should also consider sanding off the tiny, rough corners of our software that individually are small, ignorable distractions. It's surprising how much easier software is to use when even one tiny pessimization suddenly disappears.