Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!orville.nas.nasa.gov!fouts
From: fouts@orville.nas.nasa.gov.UUCP
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Small is Beautiful (was Re: Free Software Foundation)
Message-ID: <2640@ames.arpa>
Date: Tue, 1-Sep-87 13:56:35 EDT
Article-I.D.: ames.2640
Posted: Tue Sep  1 13:56:35 1987
Date-Received: Wed, 2-Sep-87 07:22:50 EDT
References: <8520@utzoo.UUCP> <1883@encore.UUCP>
Sender: usenet@ames.arpa
Reply-To: fouts@orville.nas.nasa.gov.UUCP (Marty Fouts)
Lines: 29
Xref: utgpu comp.arch:1919 comp.unix.wizards:3725 comp.os.misc:119

In article <1883@encore.UUCP> adamm@encore.UUCP (Adam S. Moskowitz) writes:

> . . ., but why add the size limit?
>Why kill yourself to deal with what many people feel is a bad hardware design?

I do much of my work on a Cray 2.  It has 2 gigabytes of REAL memory.
I still try to write small programs.  (Some are even under a gigabyte
;-)  Seriously, small is something that a reasonable amount of effort
should be put into achieving.  Like most programming credos, it should
be practiced in moderation, rather excess.  When you can do it without
destroying maintainability, you can accomplish:

1) Faster code.  By taking the time to come up with a compact
   algorithm, you can usually find one faster than you were 
   going to use in the first place.

2) Easier to understand code.  This is only true if you try for
   moderation, but less code, if it is well thought out, means
   less to understand when trying to comprehend the program.

3) More useful code.  The more people who can use your code, the
   better off you are.

You can carry the less is more credo to far and get unmaintainable
code.  You can take memory is cheap to far and get unusable code.  As
always in engineering, truth lies in the middle ground, near the
swamp.

Marty