Selecting the correct programming language for a particular task often feels like a bunfight. Suggestions are thrown around based on the individual’s preferences and desires. The experience is very likely to leave one feeling that programming is an art, rather than a science.
Let’s frame a programming language selection exercise with some real-world considerations. As software engineering leaders, it’s our responsibility to design our systems and processes such that they efficiently solve the problem at hand, and of course tool selection is an integral part of such design. Here’s an opportunity to practice that skill.
Which programming language should I choose to avert the climate catastrophe?
The destruction of the climate by industrial processes is a real-world problem. If programming language selection has no impact on it, then maybe we’re all just wasting our time, creating shiny consumer distractions to make the last few years of humanity that little more palatable for the richest 1% of the world’s human population.
Computers, of course, use energy. The Semiconductor Industry Association forecast in September 2015 that before 2040, the world demand for computers would exceed the world’s ability to supply those computers with electricity. It’s not just the computers that consume the power, though. Computers sat in data centres usually need heating, ventilation and air conditioning. Where they don’t, they’re probably not near their users (who do need HVAC) so additional networking hardware is required. They may not be so close to their operators either, who need to drive out to the data centres in their (currently mostly) petrol-powered vehicles.
On the personal/mobile/IoT side, computers are synonymous with highly-polluting materials extraction associated with battery technology. Battery chargers themselves are inefficient. Worse, consumers often leave their smartphones charging overnight: while this isn’t dangerous, it does leave the phone trickle-charging, shortening the battery’s lifespan and consuming additional energy. Many manufacturers do not allow for user-replaceable batteries. Therefore, when a device’s battery becomes unusable, a whole new replacement device must be manufactured and installed.
Many consumer computers are connected to screens and other energy-using devices, that are inefficient at reacting to context. Some smartwatches, for example, only light their screens when they are in use, but others have inefficient, always-on displays.
There are individual applications of computers with measurable power consumption characteristics. Across the US, data centres collectively consumed 70 billion kWh in 2014. This is currently the amount of electricity estimated to power the bitcoin network.
Maybe we need to carry on research into more efficient computers, and maybe select programming languages based on computational efficiency. That efficiency may not be measured in instructions needed to complete a task, but in ability to use heterogeneous computing equipment effectively. Optimising for efficiency leads us into the realm of Jevons’ paradox: increasing the efficiency of a resource’s consumption increases the consumption of the resource. It does not reduce the consumption. Just think what we could do with all those spare CPU cycles if we deduplicated decoding of Rick Astley videos, or reduced the hash puzzle complexity of a cryptocurrency.
So, Javascript, Go, or Swift?
Cover photo by Martin Adams on Unsplash.
