Pensieri di un lunatico minore

Writing for people, not machines

I admit it: I hate assembler. I hate C, C++, and most everything else other people consider “programming languages.” They are glorified switch-flipping on the front panel of a PDP-8e that we no longer have sitting in front of us. They are tuned for the benefit of the computer, and honestly, as an arrogant bastard, I find my time infinately more valuable. Computers are servants. Technology must bend to my will, not the other way around. That’s just the way I am.

So, it is with great glee that I find the resurgence of discussions about more advanced programming languages. Take an article from eWeek published yesterday.

The man from Mars sees development languages being chosen for the convenience of machines, despite attendant productivity penalties and difficulty of delivering high-quality code, instead of being chosen for the convenience of the developers who are the actual scarce resource.

Continually, I have reminded people that talented developers are expensive, CPU cycles are asymptotically approaching free. They are not being “wasted” when we burn them to make the developer’s life easier—we are freeing his own cycles to contemplate better algorithms, more advanced approaches, more adaptive reasoning.

Like anything that’s been around for several decades, LISP carries the baggage of what “everyone knows” about it that is no longer true.

“Everyone knows,” for example, that LISP is an interpreted language and, therefore, too slow for production applications—except that modern LISPs can compile functions for run-time speeds competitive with those of C or C++ programs in algorithmically complex tasks.

I remember the first time I ran into LISP in a high-performance computing environment. This was in the days when Cray ruled the world of supercomputers, and every cycle was expensive. Some of the fastest programs ever written for a Cray supercomputer came out of their LISP compiler. Why? Because the algorithm could be the focus of the intellectual power of the developer, and not bit-twiddling. It was a shock, and yet logical all at once.

The trade-offs are clear. In a study performed in 2000 by Erann Gat, a researcher at the California Institute of Technology’s Jet Propulsion Laboratory, programmers writing in LISP produced programs with less variability in performance than more experienced programmers writing in C and C++.

The fastest versions of C and C++ programs were faster than most LISP implementations, but the median performance of the LISP implementations was actually twice as good as the median performance of the C and C++ code performing typical tasks (more at www.flownet.com/gat/papers/lisp-java.pdf).

For real-world teams, such reduction of technical risk and improved worst-case scenarios arguably outweigh best-case results.

And that’s the thing. We live in the real-world, and that world is swimming in CPU cycles, memory, and un-tapped resources of our systems. Use them. Don’t waste your time worrying about saving 1 cycle when it means the real problems go unsolved. You might find out that, by focusing on the underlying problem, that the solution comes sooner, with more certainty, and thorugh more interesting work.

These observations to me also apply to Smalltalk and other “research languages,” that people dismiss as “interesting,” but not fast enough. Ruby is another such beast, as is Python, or even Perl—trading “performance” for expressiveness. Worry about “performance,” in it’s myopic traditional measure, when, if you solve the underlying problem first.

Fill your tool-belt with all the tools you need to solve the problem. You might be able to build the Taj Mahal with a pair of dental tweezers and an ice-pick, but it sure won’t be much fun.

[via Phil Windley’s Technometria]