Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!uw-beaver!fluke!kurt
From: kurt@tc.fluke.COM (Kurt Guntheroth)
Newsgroups: comp.misc
Subject: Re: MEL - A *Real* Programmer
Keywords: Real Programmer, Hacker
Message-ID: <1990Nov1.175742.5383@tc.fluke.COM>
Date: 1 Nov 90 17:57:42 GMT
References: <7380.271c3129@ccvax.ucd.ie> <1990Oct23.235720.16178@nas.nasa.gov> <6089@nisca.ircc.ohio-state.edu>
Organization: John Fluke Mfg. Co., Inc., Everett, WA
Lines: 35

I am bemused by the people, mostly students, who revile the character Mel
for programming practices of which the acedemic community does not currently
approve.  The fact of the matter is that Mel's programming practices don't
lead to maintainable code.  But...

    1.  Mel lived in the days when 1K of code was a mammoth project, and
	useful systems comprised a couple hundred machine instructions.
	In Mel's day there was much less evidence that these practices were
	suboptimal.
    2.  Mel programmed a computer with far less raw computational power than
	today's pocket calculator.  We have y^x and internal-rate-of-return
	buttons on our calculators, but in Mel's day each was a program,
	written and sold individually.  Hacking drum positions could mean
	the difference between acceptable and unacceptable response time on
	iterative calculations.

So we're all very impressed with how well you can parrot what you've heard
about structured programming.  But lay off Mel.  He was an artist of a kind
that is becomming rare these days; someone who knew the difference between
what he was taught and what was necessary; someone who appreciated the beauty
in attempting to obtain adequate performance against impossible constraints.

Laughing at Mel is like laughing at the Egyptians for building the pyramids
before inventing bulldozers and cranes.  The feat should be considered
greater because it was more difficult.  The fact that Mel's code is more
efficient than the code we write nowadays should give you the creeps,
because in one important way, his code is better than ours, for all our
structured pretenses.

When you go to the store to buy four megabytes of RAM to run OS/2, remember;
the UNIX kernel once fit into 32K; Wordstar and Visicalc, the seminal word
processor and spreadsheet programs, ran on an 8080.  You can always throw
RAM and CPU at an inefficient program to obtain adequate performance.  When
someone learns to do the same job efficiently, however, your product wll be
dog meat.