To be fair, he's countering articles that do focus on those exact things (and "Eight Megs and Constantly Swapping" suggests these attacks have a long pedigree).
To take his example of Word, I don't think it really affects users negatively that there are tons of features they don't use. If all you want to do is use it like Wordpad, nothing's stopping you, and many users do just that. But if you want to start automating features with VBA, doing extremely complex mail merges, building a bibliography, or all sorts of other great features, they're there for you. And any reasonably-designed software should be designed so that you don't have to know the whole thing inside and out to work on one feature.
When I think of software I use often, quite of a lot of it is very complex, fully-featured software, and I'm sure there are many features I never use (e.g., IntelliJ, Chrome, Office, JDownloader). In this respect I really don't believe in the "Unix philosophy," at least for GUI programs.
About Eight Megas And Constantly Swapping, I would note that emacs 24 (X11) is 14 MB on a 64-bit linux, 46 MB if you count the associated files (/usr/share/emacs), while the web browser that started at a few MB on NeXT, is now at 163 MB on same 64-bit linux (/usr/lib/firefox).
So on one hand, a full-featured extensible program whose size barely changes over 35 years, and one the other hand, a single purpose application, somewhat extensible, whose size grows exponentially over 25 years (and it's very much NOT limited to the 163 MB on disk space, since if you want to show or run anything in a browser window, you have basically to download it from the Internet, and since the least web page is 300 KB download size...).
At one point, we have to address the question of the programming language. C++ with its templates, and its baroque syntax and typing rules, multiplies the the size of the sources and the object files. Even the lighter C, when used with modern programming techniques (the older ways would lead to too many bugs and security holes), involves a lot of (by-hand!) code duplication (even with _Generic in C11). On the other hand, emacs written (mostly) in lisp uses a programming language that is basically generic. Since types are not checked at compilation-time, but at run-time, any function is essentially a generic function by default, and this leads to a lot of reusability and avoids a lot of code duplication. In addition, the use of a garbage collector (and in some cases, run-time checks for immutable data) means that you can avoid a lot of data duplication; this is not possible in C or C++, therefore you can witness a lot of data copying and duplication in those programs, to ensure manually memory and "const" safety.
"Eight megs" was supposed to be a hyperbolic claim about how much RAM it used, not the size of the application on disk (hence the "constantly swapping" part -- i.e., it's constantly going to your HD's swap partition because it wants to use so much RAM).
... or rather, doesn't take up, resulting in software with tons of broken behaviour (including vulnerabilities) because the developers don't really understand what they are working with sufficiently.
>So I’m starting to suspect that fretting about bloatware is more of a mental health problem than a software problem.
I wouldn't call this style of writing 'pretty good'. Asserting that anyone who worries about something he doesn't worry about has a mental health problem is pretty arrogant.
His point is clearly that they are devoting an extraordinary amount of energy worrying about a paltry amount of resources and thus to the extent there is a problem it is largely a figment of their imaginations.
It's a pursuasive and fun article and feels convincing, because that's just how Joel writes. But it's kind of funny to imagine the same arguments in any field but software. "We could have optimized and improved the car's design, but you would have had to wait two more months and that cost would have been perceptible. Anyway gas has gotten cheaper, so in 'real' terms the car is 'more' efficient! Fretting about elegant car engineering seems like more of a mental health problem." Not saying Joel is necessarily wrong, but it would be nice if software design had some sense of craft....
Perhaps, but the engineering of physical goods is a poor analogy to software, considering the relative ease of changing things in software if you decide they aren't working.
(Also to bdhess) just a note that I'm not trying to say the right thing for a car is also the right thing for software, just that the contrast between the design philosophies is funny (haha and/or peculiar).
To be fair, you did argue that it would be nice if software engineers showed "craft," which suggests that you think the way software is done is the wrong way.
I don't think there actually is a contrast in philosophies. The philosophies are the same for each: do a cost/benefit analysis, and then go with whatever makes the most money.
It just happens that the cost of fixing an automotive defect (i.e., with a recall) is generally way higher than the cost of fixing a software defect (i.e., by shipping an update). So the automotive industry invests more heavily in eliminating defects.
Certainly the philosophy when you're developing software for medical devices or rockets is more rigorous and careful, but the speed would be pretty much unacceptable for, say, Facebook.
Yes. And there's the inherent problem in arguing with analogies.
Here's another analogy:
"This car seats twice as many people, and accelerates twice as fast, but sadly will require twice as much motor oil when it's time for an oil change. We could have optimized and improved the car's design, but you would have had to wait two more months and it would've added $10,000 to the unit cost. It would've been madness to do."
We could sit here all day arguing about which analogy captures the actual situation correctly, or we could just talk about the actual situation.
> "We could have optimized and improved the car's design, but you would have had to wait two more months and that cost would have been perceptible. Anyway gas has gotten cheaper, so in 'real' terms the car is 'more' efficient!
If gas did get cheaper as fast as memory and storage, that would be a correct argument.
> Not saying Joel is necessarily wrong, but it would be nice if software design had some sense of craft....
I'd actually say the opposite: too much sense of craft is the problem with a lot of software development these days.
Interesting analogy, given that this attitude is pretty reflective of the industry as a whole. US manufacturers lobby against fuel efficiency regulations, and stonewall any newcomers to the industry. European manufacturers fraudulently subvert efficiency requirements to make the product seem more efficient than it really is. Presumably some of those resources could have been devoted to actual engineering...
