3 ms·

The answer is in Lehman's laws of software evolution. Most systems "must be continually adapted or [they] becomes progressively less satisfactory". The argumen

The answer is in Lehman's laws of software evolution. Most systems "must be continually adapted or [they] becomes progressively less satisfactory". The argument is simple. The world changes all the time and most software interacts with the world. Therefore, software needs maintenance in order to keep up with the changing world.

jlundberg 5y ago
Software close to the user have this need for adaption. However, my experience is that the building blocks for making even large software systems are increasingly more stable and Debian GNU/Linux is a prime example of this.
TeMPOraL 5y ago
Yeah, but the rate of that change makes all the difference. Consider biological systems: they're constantly evolving, constantly in flux - and yet, all living things we can see with unarmed eyes are fixed in the scope of a human lifespan. Most of those don't show meaningful changes withing lifetime of a human society. Cooking recipes of our great grandparents are still valid today, because fruits and vegetables and meat didn't change that much[0] over the last century. Wood still works the same way it did 1000 years ago. Being able to change much faster is good - as long as the changes tend to lead in useful direction. Software seems to be changing way faster than it's needed, because it's changing for the wrong reasons - instead of improving the value it provides, it's usually about one-upping competition, or forcing recurring payments, or forcing competitors to waste money (e.g. by introducing incompatibility on purpose). Software industry resembles a rain forest, in terms of both diversity and frequency of senseless murder (er, "survival of the fittest"). But as humans, we've dominated this planet by being smarter than that, by being more efficient than natural evolution. -- [0] - Despite being optimized directly by our industrial processes.
buu700 5y ago
That's a nice, succinct way to put it. Software that doesn't interact with the world can be finished. Software that does ends when the world does. I suppose then that a benefit of pure functional programming is that you can statically analyze whether a given piece of software is plausibly "done" or simply unmaintained, depending on whether and to what extent it uses monads.

jlundberg 5y ago

Software close to the user have this need for adaption. However, my experience is that the building blocks for making even large software systems are increasingly more stable and Debian GNU/Linux is a prime example of this.

TeMPOraL 5y ago

Yeah, but the rate of that change makes all the difference. Consider biological systems: they're constantly evolving, constantly in flux - and yet, all living things we can see with unarmed eyes are fixed in the scope of a human lifespan. Most of those don't show meaningful changes withing lifetime of a human society. Cooking recipes of our great grandparents are still valid today, because fruits and vegetables and meat didn't change that much[0] over the last century. Wood still works the same way it did 1000 years ago. Being able to change much faster is good - as long as the changes tend to lead in useful direction. Software seems to be changing way faster than it's needed, because it's changing for the wrong reasons - instead of improving the value it provides, it's usually about one-upping competition, or forcing recurring payments, or forcing competitors to waste money (e.g. by introducing incompatibility on purpose). Software industry resembles a rain forest, in terms of both diversity and frequency of senseless murder (er, "survival of the fittest"). But as humans, we've dominated this planet by being smarter than that, by being more efficient than natural evolution. -- [0] - Despite being optimized directly by our industrial processes.

buu700 5y ago

That's a nice, succinct way to put it. Software that doesn't interact with the world can be finished. Software that does ends when the world does. I suppose then that a benefit of pure functional programming is that you can statically analyze whether a given piece of software is plausibly "done" or simply unmaintained, depending on whether and to what extent it uses monads.