From mboxrd@z Thu Jan 1 00:00:00 1970 From: usotsuki@buric.co (Steve Nickolas) Date: Sun, 3 Aug 2014 12:14:49 +0000 (UTC) Subject: [TUHS] Unix taste (Re: terminal - just for fun) In-Reply-To: <20140803114952.E1AF518C0B4@mercury.lcs.mit.edu> References: <20140803114952.E1AF518C0B4@mercury.lcs.mit.edu> Message-ID: On Sun, 3 Aug 2014, Noel Chiappa wrote: > > From: "A. P. Garcia" > > > 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.) GNU is, and always has been, a waste of space. I use it, but I think BSD's lean and mean approach is superior. > 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?) EVERYTHING runs incredibly slow. Gates' law - the apparent speed of software halves every 18 months. :P > 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.) QFT. I actually do a lot of programming in an even tighter space: 64K Apple //e target. Horrible machine for C, but it's a relatively simple machine to grok except for the disk controller =P -uso.