(This begins a series of posts on the rudimentary elements of computing, inspired by Matthew Fullers Software Studies book and a review of an Introduction to Computer Science Course.)
Efficiency is more than the end of computational practice, more than a God, more than an exquisite delight, it is the chimera, the holy grail, the pwnership, the rad ollie, the be all and end all of most programming challenges for to find the more efficient solution is to find the better solution.
Of course, claims of progress, efficiency, and one dominant realm of evaluation lead me (as a good humanities scholar) to doubt the universality of the criteria.
That said, Intro to Computer Science courses stress anticipating (and calculating) Worst Case Scenarios. How many operations might this program have to execute to reach the same or an equivalent answer. Is it the whopping, exponential n^2 or the beautiful, much-slighter slope of n*log(n)
The difference is money. The difference is time. The difference is the possibility or probability that the program would process all day and night without ever stopping for a break or coming up with a solution.
Put such a program inside your traffic light. Put such a program in your tax software. Do you need to go? Do you need to drive?
Yet, somehow, I cant help but wonder if slower is not sometimes better? (Humanities folk can afford to ask such questions.) Could there not be algorithms that do a better job by including more processing cycles? Such a naive question, I know.
Where else is efficiency not just the fetish but an ultimate standard? Engineering? No doubt? Law, not so much.
Again, obfuscation exercises only reinforce this rule.
So whenever we look at code, we evaluate code, we are measuring it according to how efficient it is and all the code it saved.
We can approach software with a sense that one of the paradigms brought to this problem was to maximize efficiency. When reading code, we can examine it against that paradigm. More importantly, we can come to interpret efficiency and what that means for a particular process. We can also take into account that code is not merely the written lines but what those lines of code do when they execute. A program could be five lines long, but 2 of those lines could be iterated hundreds of thousands of time.
In the UK at least, humanities folk can no longer afford to ask such questions – the logic of efficiency has found the humanities wanting. Will there be anyone left to ask which came first, the dogma of economic efficiency or the dogma of computational efficiency?
I think that much of the move towards high level languages and development frameworks over the last few decades has been precisely about trading slower program runtimes for greater programmer efficiency and expressiveness.
In some cases the trade-off isn’t even inevitable. I’m reminded of an anecdote from Steve Yegge’s 2008 Google Talk “Dynamic Programming Languages Strike Back”, in which he’s explaining why he thinks his first employer went out of business after Microsoft’s “slow”, high-level framework out-performed their hand-tuned low-level assembly: