Wednesday, September 19, 2012

The energy cost of software language choices

After trying unsuccessfully to build a 32 bit version of Perl to work on OSX for testing a cron job to dump Oracle tables, I'm reminded yet again of how irritating Perl can be.

It isn't just the uglier-than-sin choices of syntax. It isn't just the utter inexpressiveness of the language. Perl ticks me off because Perl codebases seem to degrade rapidly into junk, defying attempts to repair and improve.

I'm conjecturing here that there is a more or less quantifiable floor of syntactic and semantic complexity inherent in the grammars and processing models assumed by any given computer language.

Perhaps that is something too obvious. Or maybe it isn't really objectively sense, but only in some fuzzy probabilistic sense. The key idea is that somewhere amongst the skills acquirable by your average joe (or jane) programmer and the expressiveness of the language, there is a best fit curve whose slope describes the technical debt one incurs just by participating in the ecosystem.

Think of it this way: in order to stay alive an organism needs to expend some amount of energy on a daily basis. In peaceful environments with plenty of free food, the outlay may be small, whereas in hostile environments with limited food availability the energy demands may extinguish populations.

There is an energy cost associated with just existing. That cost is modified by the ruggedness of the terrain, by the existence or absence of predators, parasites, and symbiotes, the relative ease with which food/fuel can be acquired, and the relative instability of the environment.  In software, the landscape is formed of choices, of technologies and techniques and artifacts; the legacy of code is the crud that forms the ecosystem.

Computer languages were originally devised to study the behavior of living systems.  One does not normally associate "energy expenditures" with programs, except in a trivial sense of big-O run-time estimates or CPU cycles. The outlay is not (just) in the running of a program, but in the attention and on-going investment that programmers and other stakeholders must make just in order to stand still in the ecosystem.

Some choices, like Perl, show great fecundity and stability, but pose a high on-going cost as well in the form of near-gratuitous abuse of syntax and parasitic idioms. Others, like Ruby, show great attention to forming symbiotic DSLs and component acquisition, but often does so at the cost of living on the quasi-stable edge of package dependency chaos, beyond which is the wild and wooly domain of PHP.  The V8-Node-NPM-Coffeescript-esque ecosystem is still relatively young but is similar to the Ruby ecosystem.  Still others, like Java and C# require not-insubstantial inputs of capital to prevent the codebase from seizing up into a dead crystalized mass.

Then again, there is a cost associated with leaving one ecosystem and entering another. That has implications on components and packaging, but I'll leave that musing for another day.