Don’t teach your submarine to swim
August 12, 2012 at 10:15 AM by Dr. Drang
A couple of weeks ago, I wrote a post in which I reintroduced my old ;furl TextExpander snippet for inserting the frontmost Safari URL into whatever you’re writing. It got some links, which is always nice, but I thought the most interesting thing about the post was its secondary topic: that the best way to automate a process through programming often isn’t to reproduce a manual procedure. Programming opens up possibilities that aren’t available in manual methods, and treating the two as if they were the same blinds you to those possibilities.
Repeating the late Edsger Dijkstra:
The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.
In the case of my ;furl snippet, the key to making it more efficient was recognizing that using the clipboard as an intermediate holding area—essential in the manual process—was unnecessary. This was just a minor example.
A bigger and better example that’s probably familiar to you is the algorithmic problem of sorting. If you were given a bunch of papers to sort—job applications, for example—you’d probably start by fanning out the papers like a deck of cards and then rearrange them as you scan through the names. If, on the other hand, you were asked to sort a list of strings in a low level programming language that didn’t have a sort command, you’d do something very different. Chances are, you’d look up C.A.R. Hoare’s quicksort algorithm and translate it into whatever language you’re using.
The “deck of cards” approach works for us because we can look at many names simultaneously1 when deciding what’s out of order and how to rearrange it. That doesn’t work in a computer program, which uses pairwise comparison. Hoare’s brilliance was in recognizing that recursion—which computers are much better at than people because they don’t get bored or lose track of where they are in the stack—and pairwise comparison could be combined into an algorithm tuned to the computer’s strengths.
(If you had a large pile of papers to sort, you’d probably divide it into smaller stacks first: A-M and N-Z, say, or even more substacks if the original pile was particularly large. This is like one step of quicksort and may have been one source of Hoare’s inspiration for the algorithm. But nobody keeps recursing that way.)
Another example from my line of work is moment distribution. Moment distribution is a numerical technique for the structural analysis of statically indeterminate beams and frames. It was developed in the early ’30s by Hardy Cross2 and was still being taught when I was an undergraduate nearly 50 years later.
It’s impossible to overestimate how important moment distribution was to the structural engineering profession. Before computers, it was the only practical way to analyze an important class of structures. One of my prized possessions is a booklet put out by the American Society of Civil Engineers shortly after Cross’s moment distribution paper was published. The booklet includes not only the 10-page original paper, but almost 150 pages of discussion. It hit the profession like a bolt of lightning, and everyone recognized it immediately.
In moment distribution, you do your calculations on a drawing of the structure. It’s an iterative technique, so you start with an initial estimate of the moments at every joint and then distribute, re-distribute, a re-re-distribute the moments through a set of simple rules until the results converge. The Wikipedia article does a decent job of explaining the process, but it doesn’t compare to Cross’s.
As computers became more prevalent in the ’50s and ’60s, structural engineers began to think that moment distribution was a natural fit. I have structural analysis textbooks written as late as the ’70s in which the authors talk as if were just a matter of time before we’d all be using moment distribution programs. It never happened.
The reason it never happened is that despite some obvious correspondence between the needs of moment distribution and the capabilities of computers in the areas of arithmetic computation and iteration, the way moment distribution calculations are organized is a little too ad hoc, a little too dependent on human interaction to be nicely automated in a general purpose program.
Also, and perhaps more important, there were direct, non-iterative, ways to solve the equations that arise during structural analysis. These equations are so large and so numerous for a structure of any decent size that they are virtually impossible for people to assemble and solve.3 But this kind of bookkeeping is exactly what computers are good at, and a technique that took advantage of this capability, the direct stiffness method (generalized as the finite element method), supplanted moment distribution when computers came to the desktop.
The moral of the story: While you may start out automating a process by mimicking a manual procedure, don’t stop there. Think about what you really want to accomplish, not just the steps you’ve always followed, and you may come up with something new and better.
-
At least it seems to be simultaneous. Deep down in our neurons it may well be just very rapid pairwise comparison. ↩
-
At, I should mention, my alma mater. ↩
-
The brilliance of moment distribution was how it sidestepped the impossibility of solving these equations by pretending they didn’t exist. ↩
