Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site topaz.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!columbia!topaz!deutsch.PA@Xerox.ARPA
From: deutsch.PA@Xerox.ARPA
Newsgroups: net.works
Subject: Big & little machines & problems
Message-ID: <2079@topaz.ARPA>
Date: Thu, 23-May-85 11:49:34 EDT
Article-I.D.: topaz.2079
Posted: Thu May 23 11:49:34 1985
Date-Received: Fri, 24-May-85 22:20:42 EDT
Sender: daemon@topaz.ARPA
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 52

From: deutsch.PA@Xerox.ARPA

I can't believe that people are taking this PDP-8, Timex, etc. vs
VAX argument seriously!

Seriously, though.  If you want to crack peanuts, use your fingers.
If you want to crack walnuts, use a nutcracker.  If you want to break
rocks, use a sledgehammer.  You won't get very far on the rocks with a
nutcracker.  And you shouldn't be surprised that it takes more effort to
lift and operate the sledgehammer than the nutcracker!

That's half the argument -- that the little machines solve the little
problems better partly because they can't solve the big problems at all.
The other half of the argument is one that can't be made in the breaking-
rocks domain.  Software is truly unlike just about anything else in the
human universe: managing its complexity is a major intellectual task
(again, for big problems).   One of the tradeoffs we're usually
willing to make is to get some assistance from the machine architecture
in this task.  If you have a system made up of 500 modules, and you want
it to be BOTH reasonably efficient AND reasonably easy to understand AND
reasonably easy to modify, then either:
	- you can write it all in assembler and be an "iron man" like
Doug (and me in past lives), and God help you if the person involved
ever leaves, gets run over by a truck, loses interest, etc., or if your
requirements change substantially and you have to change a data
structure;
	- you can write in a HLL, and either:
		- have a slow, complex compiler that produces mono-
lithic output that runs like the wind but can't be debugged
(which, in fact, is a good tradeoff for some of the large-scale
numeric problems like weather simulation), and makes you wait forever
if you want to change the smallest thing in the program, or
		- pay some overhead for hardware that assists modularity,
like the infamous VAX call instruction (which I confess I've never heard
one good thing about).

In other words, some of that machine overhead you're paying at execution
time is intended to reduce the development and maintenance time for
the kind of program that seems to absorb the largest part of
people and machine resources -- big ones.

It's interesting how our environments shape our ideas of what the "real"
problems are.  People using computers as adjuncts to real-time equipment
think the real problems are the small ones requiring fast computation --
that's where FORTH came from.  People in research often think the real
problems are the ones of fast turn-around and development -- that's where
the high-powered interactive environments (Interlisp, Zetalisp, Smalltalk,
etc.) came from.  Physicists think the real problems are big numerical
ones -- they want Crays and FORTRAN.  People at Universities often see
the problem as teaching -- hence BASIC.

-- Peter Deutsch --