From mboxrd@z Thu Jan  1 00:00:00 1970
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun,  3 Aug 2014 07:49:52 -0400 (EDT)
Subject: [TUHS] Unix taste (Re: terminal - just for fun)
Message-ID: <20140803114952.E1AF518C0B4@mercury.lcs.mit.edu>

    > From: "A. P. Garcia" <a.phillip.garcia at gmail.com>

    > the spirit of emacs without the bloat :-)

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