ndanger.organism

Chris Diggins elaborates on why naive (simple) code should just work (well).

In theory I agree. It’d be great if the simple & obvious case also happened to be the most efficient; but is this possible for a full range of algorithms? In practice, languages balance readability, speed, memory efficiency, etc. Kirit‘s comment points out that the Scheme code is necessary to make the function tail recursive. Tail recursion is required to get O(1) memory usage. Evidently Scheme has optimized for “intuitive” (i.e. recursive) function definitions & memory efficiency over an easy “naive” solution. Is this the right trade-off? Given my real-world Scheme experience–zero–I have no idea.

In this case it seems that complicated idioms are a necessary complexity: for this algorithm written in this language efficiency requires complexity.

I admit some complexity is probably also accidental. The link to The Evolution of a Haskell Programmer and Senzee’s recent developer life stages are ha-ha only serious jokes about alpha-male computer nerdism . No doubt some complexity is caused by the desire to write code so good that the programmer the next cube/commit/blog over assumes you have ultimate computer juju.

The hunt for simple software has led from machine-code to assembly to C to high-level languages, etc. Without a doubt, this will continue. In the future naive code will be more efficient (not just faster because of the hardware, but actually more efficient). But a large part of efficiency will still be the human part: understanding the effects of implementations and making correct choices. So automating programming is automating human decision making–yes, AI.

In the meantime, the solution is encapsulation and easy integration. Encapsulation of your algorithms let’s you swap in a more efficient implementation. Integration lets you write the algorithm in the correct language.

PS: Hmm, it seems that everything I just said has been said better in comp.lang.lisp.