Turing’s residuum

Erlang can be slow, and I’m reminded of this daily as the mainstream programming community worships things that go fast. I continue to be suspicious of this collective worship, though, as language-sluggishness has yet to compromise my work or contribute to a missed deadline. Simply put: modern languages run plenty fast, so why does a community of craftspeople put so much stock in speed?

Whence

Although the Prometheus of modern programming is anointed to several — like Alonzo Church, Tom Kilburn, etc. — I can’t help but feel that the obsession with speed is a relic from the days when Alan Turing was working on code-breaking.

Turing’s objective was to create a computer to code-break German encrypted messages in World War II. It’s fair to say, elegance wasn’t in that particular specification, nae scalability, nae fault-tolerance. Rather, it had to complete its runs quickly, because if it didn’t, England was ever the closer to Axis defeat.

I’m amazed how repugnant the speed obsession remains today. Nowadays, the stakes are relatively tiny. Plus speedups are something that occur automatically: improving hardware naturally makes our programs run faster every decade without us changing our code.

So why all the fuss?

Stadium seating

Syntax aside, I feel Erlang/OTP doesn’t get the love it deserves from the hacking community. It was designed from day one with demanding engineering challenges in mind like fault tolerance & scalability.

But benchmarks continually have Erlang nearing the bottom of speed tests; even Ruby and scripting languages sometimes prove faster when utilized in everyday tasks. It seems like the humble little language from Sweden doesn’t stand a chance when pitted against the likes of C, C++ & Java.

However, Erlang/OTP wins in a myriad of other events, just not the 100 meter dash. It’s fantastic at running the marathon, even. But can we ever consider such technologies while we continue to breathe life into our ritualistic ‘need-for-speed’ that’s derived from some wartime hacking challenge?

Perchance

The hacking culture seems to be hard-set on speed. And I guess that’s natural: for the same reason architects sport round eyeglasses like Le Corbusier, or air pilots speak with a slight backwoods drawl à la Chuck Yeager, so do we find the need to imitate those first in our field.

But still, while speed sits atop the short list of what makes a solid programming language, I wish we could pierce though the frenzy & make an effort to re-prioritize. We ought acknowledge the challenges that engineers face in our day. Does speed trump security, scaling, energy consumption, etc. ?

Turing’s war assignment ran its course; he had his problem domain, and now we have oodles of new ones. Is it prudent for us to remain obsessed with an objective that has long expired?