One of the hot topics in programming over the last few years is immutability, that is to say not changing the state of values once created. Although this technique has been known for many years, it has only recently become mainstream - why is this?
There are several factors, not least the rise in multi-core CPU's leading to a surge in interest in multi-threaded programming, where immutability avoids a whole class of concurrency bugs.
However in my view this is not the primary cause: Rather it is the case that historically, state was always something unpleasant programmers had to deal with manually in order to achieve acceptable performance, but advances in processor speed, memory size and compiler technology now mean that in an increasingly large number of cases, programmers can afford to ignore the realities under the hood.
And of course under the hood computers are not immutable - they are in fact designed to change state at fast as possible - and therefore immutability imposes an abstraction penalty. Immutability has become mainstream because that penalty is now outweighed for many areas by the benefits immutability brings.
That is the essence of what I call "luxury programming": Coding in a style which is for the ease and benefit of the programmer, while ignoring the additional burden placed the underlying hardware, since the sheer power of modern computers renders this relatively unimportant in many cases. Outside of severely resource constrained (eg embedded systems) or performance critical (eg high frequency trading) environments, this is increasingly the norm.
To put it another way: Modern desktop and server (and to a lesser extent handheld) computers are generally far more powerful than necessary to solve the problems they seek to address. Therefore efficiency is no longer the top concern of modern software developers - instead factors such as correctness, maintainability and time to market are.
Immutability is though only the latest in a long line of luxuries that have graduated from being niche ideas to become common practice. Some other examples are:
In each case, the burden of manual work required from the programmer is reduced at the cost of an additional abstraction penalty that has to be absorbed by the hardware.
If we take this view, then we should ask ourselves what the next luxuries are that we can look forward to becoming staples of mainstream programming? One obvious candidate for which the adoption process is already well advanced is functional programming. Like the others, this is also a technique which has long been known but never became mainstream, at least partly due to the performance penalty when running on computer hardware (which is naturally imperative) was too high. But now it is enjoying a resurgence because the benefits of expressiveness are seen to outweigh the penalties.
Are there any factors to counter this trend? Cloud computing could arguably be one: Pricing models based on CPU or memory usage can, at least temporarily, tip the scales back in favour of the programmer doing more manual work for the benefit of higher efficiency. Google for instance still use C++ for many back-end services because the improved efficiency over more "luxurious" higher level languages can add up to millions in data centre cost savings.
Do you agree? Is life for the average programmer becoming more luxurious? What do you think the next trend in luxury programming will be?
I had not seen it that way, but you are right. Did you refer to virtualization when you mentioned hardware abstraction??
ReplyDeleteBy hardware abstraction I was referring to programming against an abstraction - for instance in the graphics worlds, OpenGL or DirectX, rather than the underlying graphic hardware directly. But virtualisation, for instance Docker, is another good example of this trend.
Delete