Programming on Paper

From: Mike Ford <mikeford_at_socal.rr.com>
Date: Mon Jun 19 18:26:36 2000

>On June 17, Dave McGuire wrote:
>> On June 17, Mike Ford wrote:
>> > >Having a machine to interact with allows you to test your code on the
>spot
>> > >and if you are writing in an interpreted language the error-checking
>the
>> > >interpreter provides is a godsend for the coder. Why anyone would code
>> > >without the interaction of the target machine is beyond me.
>> >
>> > I write perfect code, like Mozart it flows out in its final form to the
>> > paper, and then to the system.
>>
>> Time for the hip waders, folks...it's getting deep in here. ;)
>
>Ok, here's a quote from one of my favorite computer scientists
>(Tom VanVleck, who might respond to being so identified as "Me?
>I'm just a programmer!"):
>
>: It is possible to write perfect, bug-free code. I've seen
>: it done, with no tool except a pencil. The essential ingredient
>: is a decision, by the individual programmer, to make the code
>: perfect, and not to release it until it is perfect.

The caveat is that all of the "perfect" coders I know, wrote in assembly
language, which has very little ambiguity. I owe much of my coding skill to
a single mid level class on plotting. Two stinking credits, and one of the
hardest most time consuming classes I have ever taken, with a drop out rate
close to 75%. The title was plotting, but it was all about writing
optimized code in assembly language to be called by a fortran program
running on a IBM 360 with output on some little flatbed plotter. Each of
the half dozen projects reused code from the previous, and by the end we
all had shoebox sized stacks of punched cards, and a VERY keen eye on what
made good code.

It was really many years later into my professional career that I learned
to "spill some blood" and let the compiler find a few errors instead of
spending so much time actually writing the initial code.
Received on Mon Jun 19 2000 - 18:26:36 BST