Computing Caverns
Volume Number: 1
Issue Number: 6
Column Tag: Modula-2 and the Macintosh, PART II
The Caverns of Computing
By John R. Bogan, Microcomputing Consultant
The Caverns of Computing
S: January 26, 1985
E: February 14, 1985
Often I think of computing as an extraordinary, Real-Life, Adventure game
beckoning the computer warrior to descend into a yawning cavern riddled with many
dark and intriguing passageways all begging to be explored. At the “end” of each
corridor there lies a treasure, usually small and mostly ordinary but sometimes great
and wonderous. These treasures are all jewels of knowledge and enlightenment about
the marvels of logic.
I honestly believe that we (the computing community) have barely scratched the
surface of our particular Adventure and some of the passageways that extend in front of
us obviously go on for miles, twisting and turning with many small and alluring side
alleys to explore or ignore as we choose.
It is up to each of us to decide which of these passageways we will pursue and to
sift through the myriad of clues we discover along the way to decide which treasures to
seek. Last year about this time several of my favorite and well trod corridors of
computing converged and I found at their juncture a wealth of riches. These corridors
which I have eagerly explored for more than half a decade are low-cost professional
micro systems, the Motorola 68000 and Pascal. All the clues I had accumulated these
past five years told me there would be something special waiting when these paths
crossed. The glittering jewel of logic I found at their confluence now occupies the
position of honor on my desk. It is the Apple Macintosh.
The reason the Mac is such a valuable jewel is that it sheds a piercing light on
such gloomy corridors as “user friendly” and “software integration” and “computing
for the masses”. And as any Adventure fan knows any bright light is a most valuable
tool in the caverns of computing. As an early Macintosh enthusiast who has eagerly
watched the hi-res graphics, mice, windows, icons, pulldown menus and cut and paste
integration passageways blossom into well mapped, well trod aisles of acceptance and
imitation over the past year I could argue the wisdom and majesty of the Apple strategy
and direction long after I ran out of rational things to say. After all the Mac is clearly
the product of wizards and elfin folk who possess great magic (One look at Burrell
Smith proves that). But the purpose of this column is not to look back and congratulate
Apple that it made it this far but to use our new bright light to illumunate some of the
dark passages that lie ahead of us.
Deep Background
It is one of the best kept secrets in Computer Science and Software Engineering
(CSSE) that the proper role of High Level Languages (HLLs) is to permit and encourage
wide ranging experimentation and evaluation of new ideas in a cost efficient and timely
fashion. Since the time I learned the difference between FORTRAN and COBOL I have
followed and participated in the religious wars over which computer language is Best
and I have concluded that most of the time the arguments are largely irrelevant since
they concentrate on the question - What language should our software be written in
when it is shipped to the consumer? As someone who is more interested in exceptional
software requiring extensive R&D I have consigned that question to the trash can. The
microscope people who can focus only on maximizing speed and space will insist on
Assembler (ASM). The puzzle fanatics will choose Forth. The compromisers who can’t
quite give up the chance to get their hands dirty with a little register optimization will
probably choose “C”. But the thoughful scientists and engineers in the R&D labs who
desire to conserve the scarce R&D dollar and even scarcer R&D minute will choose -
Modula-2.
Here’s Why
HLLs are invaluable because they permit the Software Engineer to build complex
and innovative programs, which break new ground, in the shortest possible time and
for the fewest R&D dollars. This means that within a given budget and deadline more
ideas can be explored and evaluated and thus more progress can be made toward
achieving an ideal piece of software. This is not a theory, it is an observation of the
history of microcomputing. Let’s look at some of the most important software
breakthroughs in the past few years and examine the language influences on the R&D of
these milestone products.
o CP/M. Designed in large part in PL/M, a structured HLL. Responsible for the
early success of 8080 and Z-80 S-100 small business systems.
o Visicalc. Designed largely in BASIC. Responsible for the immense success of the
Apple //.
o Lotus 1 2 3. Cloned from MBA Context which was written in UCSD Pascal.
Responsible for the flood of integrated software and the dominance of the IBM PC.
o UCSD Pascal P- system. Contributed to pull down menus and menu driven
Operating Environments.
o Xerox Altos testbed. This system never made it into the commercial world at all
yet it has to be considered the Grandfather of the graphic, iconic, windowed
personal workstation. This system was developed in the HLL Mesa - a Pascal
derivative.
o Apple LISA. The first commercial microcomputer to make it to the marketplace
bearing the fruit of the Xerox Alto. LISA was designed and written in Pascal.
o Apple Macintosh. Designed in Pascal and translated into hand optimized ASM. The
third milestone microcomputer, the most successful introduction of any
professional micro at any time.
o Kildal’s GEM and Tramiel’s “Jackintosh”. Cloned from the Mac.
These are not idle opinions, this is not some wierd hallucination that can be
dismissed with a snort and a wave of the hand, these are verifiable historical facts -
which can not be ignored. They clearly illustrate the major role of HLLs and in
particular - the structured language Pascal - in the software R&D labs throughout the
micro world. The reason for this success is obvious and worth restating. With a
structured HLL it is easy to break new ground and if this new ground is genuinely
helpful and makes small computers more productive and easier to master then the
consumer will eat them up.
Why are structured languages going to be the bright light of choice in the R&D
labs of the micro world for the indefinite future? The answer lies in history and
economics and logic.
Programming as Engineering
Back in the mid 1960’s computer specialists noticed a troubling trend. While
hardware was getting exponentially cheaper, the cost of producing software was taking
off as programs got more complex to take advantage of the improved hardware. The
following graphic illustrates this point.
Following the realization that software costs were getting out of hand the
computer industry gradually started to divert resources from the hardware side of the
industry to the software side. Along with this attention came some discipline ... the
discipline of engineering. A rough definition of engineering is that it is the art of
measuring and optimizing resources.
Thus the productivity boys came in to the Data Processing departments with their
legal pads and stopwatches. The metric (unit of measure) they decided on was the
number of lines of code per day per programmer and to their horror here is what they
found.
o The average programmer could crank out only ten lines of debugged code a day!
o It didn’t matter what language the programmers were coding in, if they were
programming in Assembly the daily output was ten ASM statements, if the
language was COBOL or FORTRAN - ten statements!
The first, and obvious, conclusion that was drawn was that the COBOL and
FORTRAN programmers were ten to one hundred times more productive than the ASM
programmers since each line of FORTRAN could generate ten lines of ASM and some
lines of COBOL could generate 100 ASM statements. I believe that these widely
reported results are in no small measure responsible for the fact that most large DP
departments are now and forever locked into COBOL as their language of choice. So
much for the benefits of Software Engineering!
But before we dismiss Software Engineering as merely the tool of the devil let’s
look at what else was learned in their productivity studies.
When you ask a talented hacker how long he took writing a 1,000 line program
don’t be surprised if he scratches his beard and replies, “Oh, I did that one night a
couple of months ago.” This would seem to contradict the ten statement/day finding ...
by orders of magnitude. But then ask your hacker how long he spent making his
program bug-free. He might just reply, “Well, I expect to get the last bug out of it
anytime now.” One night writing the code and two months debugging it, this is more
common than you might think. Anyways this was the second major conclusion of the
Software Engineers. The piechart below illustrates the traditional division of labor
and hence cost in creating significant programs.
Careful study of the above graphic reveals just how obscene it is. In traditional
programming two thirds of the effort, and money, goes into the toilet known as
maintenance.
MODULE HanoiPuzzle;
(* Declare I/O from Modula-2 Standard Library *)
FROM Terminal IMPORT ClearScreen;
FROM InOut IMPORT WriteLn, WriteString, WriteCard, ReadCard,
Write;
CONST Start = “a”;
Int = “b”;
Finish = “c”;
VAR DiskCount: CARDINAL; Done: BOOLEAN;
(* Get number of disks or set terminate flag *)
PROCEDURE GetInput (VAR NumberOfDisks: CARDINAL;
VAR Quit: BOOLEAN);
BEGIN
ClearScreen;
WriteString(“Enter number of disks (between 3 and 9)”);
WriteLn;
WriteString(“To quit - enter number out of range”);
WriteLn;
ReadCard(NumberOfDisks);
IF (NumberOfDisks < 3) OR (NumberOfDisks > 9)
THEN Quit := TRUE
ELSE Quit := FALSE
END; (*IF*)
ClearScreen;
END GetInput;
(* The recursive guts of the programs ... calculate moves. *)
PROCEDURE Hanoi(n: CARDINAL; StartNeedle, IntNeedle,
FinishNeedle: CHAR);
BEGIN
IF n#0
THEN
Hanoi(n-1, StartNeedle, FinishNeedle, IntNeedle);
WriteLn;
WriteString(“Move disk -”);
WriteCard(n,2);
WriteString(“ from “);
Write(StartNeedle);
WriteString(“ to “);
Write(FinishNeedle);
Hanoi(n-1, IntNeedle, StartNeedle, FinishNeedle);
END; (*IF*)
END Hanoi;
(* Mainline ... control main loop ... get input & do it. *)
BEGIN
GetInput(DiskCount, Done);
WHILE NOT Done DO
Hanoi(DiskCount, Start, Int, Finish);
GetInput(DiskCount, Done);
END; (*WHILE*)
END HanoiPuzzle.
Referenced by (2):