Blogs

RedMonk

Skip to content

Can Code be Green? Does Beauty Matter?

At an IBM green event, James asks:

On that note I am beginning to wonder if beautiful code is green code. Code generation tends to generate pretty ugly code – but is it less efficient? Developers that write beautiful code may end up in great demand for their green coding: but this is pure conjecture at this point…

Tragically, I don’t think there’s a great deal of corelation between beauty of code and it’s greenness. The more beautiful code is, typically, the further away it is from machine language, assembly, and other “low level languages.” My assumption would be that converting the beautiful code down to that layer takes extra energy. Thus, the most energy efficient code would probably be assembly (I don’t think we would expect people to write in machine code).

How Much Energy Does Beauty Take?

It’s like: is a manual screwdriver or an electric, cordless drill/screwdriver more green? Human labor seems more green at first, but maybe it takes a whole apple of energy for a person to turn a screw, and just 1/4 of an apple for a cordless drill to do it. I just apples here as some unit of energy.

Then again, you could say, all of the time it took to write in assembly instead of higher level languages – including re-learning and new people picking it up – uses more energy.

But, the fact that it seems like you could go either way means to me that “beautiful code” is less than a sure shot for green.

The Problem with Beautiful Code

Also, it should be noted that “beauty” in code is highly subjective, even more so than hardware. Beautiful code to an Ada developer is crap to a Java developer is utter madness to a ruby coder. JavaScript can look magnificnet to an Ajax developer, but a hard-core Java develoepr will disagree with the dynamic nature of JavaScript so much that it will look like ass all the time.

More generally, we’ve tried to establish “beauty” and “health” in code for decades which – as we should sort of expect with a properly functioning 20th century mind – just sets up the new traditions that the next rebels will break to get software language innovation. If beauty is maximum configuration with XML, along comes rails with the new beauty.

Disclaimer: IBM is a client, as is Sun.

Technorati Tags:

Categories: Programming.

Comment Feed

6 Responses

  1. There are many different flavors of efficiency to be considered, but working in an open source development shop I argue that beautiful code (well organized, streamlined, reusable and commented) is in the long term green simply because more people can reuse it. Also the effort can be spent on improving the existing code versus having to start from scratch.

    I'm not sure that beautiful code is more efficient at the microeconomic level of "watts per execution" versus, say, machine level code, but the total cost when all the externalities are accounted for should be less over time.

  2. Beautiful code should be understandable by others. This allows them to figure out if it works and to fix it when they find out it doesn't. It should be elegant – which is to say, attractive to the eye and appropriate to purpose. You know it when you see it.

    I take exception to the notion that beautiful Ada code will look like crap to a Java programmer, etc. Even if the Java programmer doesn't write Ada, she should be able to get a sense of what's going on in the code.

    Yes, perhaps no one but an APL programmer can see beauty in that language, but for most folks, clean and elegant code garners respect, even if in a foreign tongue.

  3. Carl: nice slipping in of APL 😉

  4. As someone who programs in a dialect of APL: It really just takes a month or two to start appreciating it.

    It helps if you work on large, mostly regular data sets.

    It’s also as fast as hell.

  5. Holy API efficiency batman this is turning into an awesome discussion. Sweet – i have some twitter back channel feedback too. thanks Cote.

  6. wait i just realised. carl kessler is commenting here. bot not on my blog! bah humbug carl… 😉 but i think you make a great point