Exactly. I've often wondered what the heck exactly it is that GNU Emacs, GCC, etc are all doing with those megabytes of code. (In part, probably all those options: "Options. We've got lots of them. So many in fact, that you need two strong people to carry the documentation around.", as that classic hack says. But there's no way the options alone can explain it all.) The thing is that it's not just aesthetics that makes large programs bad; there are very good practical reasons why they are bad, too. The 'takes more resources' isn't such a big deal today, because memory is massive, and there's a ton of computing power to be thrown at things. (Although I'm always amazed at how the active content in Web pages seems to run incredibly slowly on all but the very latest and greatest machines. WTF are they doing?) But more code = more material that someone new has to understand before they can make some change (and long-lived code is always being changed/upgraded by new people). And when people understand a system poorly, their changes tend to be 'a bag on the side', and that's the kind of 'code cancer' that tends to kill systems in the long run. More code also is also more places where there can be bugs (especially when it's changed by someone who understands it poorly, repeat previous comment). Etc, etc. And those will never go away - human brain power is finite, and unlike hardware, not expanding. There's just no reason to have N megabytes of code when .N will do. (I've often thought we ought to make new programmers serve an apprenticeship of a year of two on a PDP-11 - to teach them to 'think small', and to realize you _can_ do a lot in a small space.) Noel