Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!mips!daver!tscs!tct!chip From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.arch Subject: Bloat costs Message-ID: <2662CE6C.3E68@tct.uucp> Date: 29 May 90 19:33:00 GMT References: <2793@crash.cts.com> <265D2FE5.2513@tct.uucp> <640@sibyl.eleceng.ua.OZ> Organization: ComDev/TCT, Sarasota, FL Lines: 33 According to ian@sibyl.OZ (Ian Dall): >Indeed, these days, an employer could be justified in berating a >programmer for wasting time reducing the size of a program instead of >increasing it's speed or functionality or getting it to market >earlier! Well, I'm not advocating a 16K limit on code size, either. :-) However, I consider program size vs. programmer time to be a false dichotomy. I would argue that, once gained, the skill of writing programs that begin and stay small makes a programmer more productive and valuable. It's a part of the overall "think small, do one thing at a time" mentality that produced Software Tools, Research Unix and Plan Nine. (But not System V or BSD, unfortunately.) I agree that it may not be worth the time to modify a working program just for the purpose of making it smaller. However, it is my discouraged opinion that many programmers -- perhaps a majority -- don't take resource usage into consideration when designing and writing *new* code unless forced to do so. The apparent omission of resource considerations from the planning stages of programming is what I detest. The "think small" approach is, in my opinion, a big win over the "just write it the most obvious way" approach. It seems, however, that the latter has a patina of respectibility among new programmers by virtue of all the bloated programs they use as they learn. "GNU Emacs is huge, X is huge, SunView, System V, BSD, SunOS, AIX are all huge -- why should I have to think about how to use less memory?" Sigh. -- Chip Salzenberg at ComDev/TCT ,