Niklaus Wirth: A Plea for Lean Software (1995) [pdf]
cr.yp.to
cr.yp.to
And that is the simple fact that employers want their employees to remain busy. If a piece of software reaches a point of exceptional quality - the developers working on it still have to fill 40 (likely more) hours a week to appease bosses. And so they do the only thing available - they ruin the product. This is one of the reasons that I think software engineers should, in certain cases, work on retainer. Domain knowledge of a specific product is very valuable, and companies routinely ignore this. They will shuffle an engineer off to some newer project and leave a more junior person to handle maintenance of the original project - and that junior person will have to fill their time somehow. This serves no one except for the shortsighted manager who determines their self worth by how many and how much they control their employees.
Or this soundbite from a later blog entry of his: "No matter how much it bothers you neat freaks, the market always votes for bloatware."
I wish he were wrong; it bothers me that 512 MB is now considered low-end for RAM in a smartphone. But I guess we just have to accept this reality of our industry.
> [Hardware arguments]
The problem is not really RAM or disk consumption. The problem is that starting up my OS, or my Web browser, or my word processor, or even Emacs for that matter… is not instantaneous. Our computers are million times faster than 30 years ago, and they still lag. Bloat certainly bears some responsibility: if we had less, cleaner code, we could have more efficient programs:
> Efficiency comes from elegant solutions, not optimized programs. Optimization is just a few correctness-preserving transformations away.
Jonathan Sobel http://www.cs.indiana.edu/~dfried/dfried/dfried/mex.pdf
---
> If your software vendor stops, before shipping, and spends two months squeezing the code down to make it 50% smaller, the net benefit to you is going to be imperceptible
Short term benefit will certainly be imperceptible. But in the longer term, dividing the size of the code base by two will mean significantly easier maintenance, including the addition of features. Losing 2 months now may very well gain you 2 years down the road.
---
> [Features]
The problem with too many features is not that software is capable of too much. The problem is the lack of orthogonality. The same level of capability could be achieved with less, simpler features. But I guess that would imply trusting the user to unprecedented level. Like, letting her program her damned computer, like any Excel idiot is perfectly capable of…
Excel is a far more advanced programming environment than any real IDE. There's less room for syntax errors, immediate feedback on changes, you can display and examine all intermediate computation steps…
Most important, the computational semantics of Excel spreadsheets do not include "accidentally delete all the user's files" or "accidental remote code execution" like most other programming languages.
Our code needs to scale down as well as up, but it should do so in the libraries and the abstractions. That is why "big data" was such an issue, we weren't working on abstractions that blurred the lines between in and out of core and now we are.
If we turn from imperative to declarative and any-typed to algebraic the semantics remain consistent and it is up to the runtime to fit the code to the available compute and memory. Cache Oblivious was a good start, memory and compute oblivious is the next level. A Lisp with an RDD [0] feels about right.
[0] http://www.cs.berkeley.edu/~pwendell/strataconf/api/core/spa...
"It led to Oberon, a language derived from Modula-2 by eliminating less essential features (like subrange and enumeration types) in addition to features known to be unsafe (like type transfer functions and variant records)."
Does anybody know what the argument about the safety of variant records is?
If I understand that quote, he means that variant records are dangerous because they make it possible for programmers to interpret data in different ways, thus bypassing the type checks of the compiler and invalidating the whole concept of strong typing. He mentions a little more about this in his paper on The History of Modula 2 and Oberon: http://www.inf.ethz.ch/personal/wirth/Articles/Modula-Oberon....