Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!ucbcad!ucbvax!WILMA.BBN.COM!dan
From: dan@WILMA.BBN.COM
Newsgroups: comp.society.futures
Subject: Re: Where are the small thinkers?
Message-ID: <8710291802.AA00830@bu-cs.BU.EDU>
Date: Fri, 30-Oct-87 07:13:27 EST
Article-I.D.: bu-cs.8710291802.AA00830
Posted: Fri Oct 30 07:13:27 1987
Date-Received: Wed, 4-Nov-87 07:09:13 EST
References: <8710290600.AA05997@bu-cs.BU.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 50

I agree; smallness is good when it refers to smallness of the design,
not smallness of the code.  It's really a matter of the complexity of
the mental model you have to carry around when you want to think about
the whole system.  Most systems grow more complex when people work on
them, because they enhance by adding a new feature.  But it's usually
better to go over the assumptions that went into the design and try to
add or change one assumption.  Unfortunately this requires a global
view of the system that most maintainers don't have, as well as a
strong commitment to the ideal of simplicity; it's HARD to enhance a
system this way!

If you can't add a capability merely by rethinking a design
assumption, you could try instead to keep the total number of features
constant: if you are adding a new feature, take an old one out.
During a Berkeley Steering Committee discussion a few years back about
adding symbolic links to UNIX, Dennis Ritchie argued that if symbolic
links were going to be added, then hard links (that is, the ability to
have multiple hard links to the same file) should be removed.  There
should only be one way to do something: if you're adding a new way
because the old way wasn't good enough, then the new way should
replace the old one.  I didn't agree at the time (and neither, I
think, did anyone else) because of the compatibility problems it would
cause.  Now, I'm not so sure.  Keeping the old feature around makes
the system harder to think about.  Supersets should supersede!

So what happened to the small philosophy?  It's just temporarily
suspended.  Originally simplicity in programming was a virtue because
there just wasn't much room to do things in.  Now that's not a problem
anymore, but we've found a new reason for simplicity: it makes a
system easier to understand, use, and maintain.

But it's hard to design systems that way, even though it's worth it.
It doesn't come naturally to most computer programmers, even good ones
(even ones who've enhanced UNIX in significant ways).  In the future I
think we'll see more emphasis on design skills in computer science.
Planning a large computer program requires as much design skill as
planning a large building, but while architects take classes in
design, computer programmers usually take no classes in design at all.
In the future I think that will change.  Already there are computer
classes (at Berkeley, I think) in which students write a program in a
team, then give the program to another team to modify.  They are
scored both on the original program and how easy it was to change.

I would also like to believe that object-oriented languages encourage
better design, because they can make it easier to think about the
design assumptions and the whole design process.  But I don't know if
that's really true.  Perhaps someone who has modified someone else's
large SmallTalk program can comment...

	Dan Franklin (dan@bbn.com)