Much do disagree about. > [Hardware arguments] The problem is not really RAM or disk consumption. The problem is that starting up my OS, or my Web browser, o

Much do disagree about. > [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 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…