19 Jun
2000
19 Jun
'00
8:08 a.m.
On June 17, Dave McGuire wrote:
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 quote is from an article of his on the Multicians web site:
http://www.multicians.org/thvv/evolution.html
I left my last job as a full-time programmer in 1990. A young
Russian (who had written some of the software tools used in
generating the control programming for Snowflake, the never-used
Soviet space shuttle) was assigned to take over my work. In the
month we worked together, we became friends, and so stayed in
touch after I left.
A couple or three years later, Dmitri and I were having lunch,
and feeling a mood which had me wondering if I'd done the right
thing in giving up programming, I asked him how much trouble
he'd had with my code. "None." I probed deeper, knowing he was
a good programmer and that he might have misinterpreted the
thrust of the question. Right out, I asked him if he would
character the severity and frequency of the bugs left in the
extensive codebase I'd pushed. He stopped me, saying he'd
understood me perfectly the first time, and said "No bugs
in your code, Doug; you write best assembly language."
If only I could have found an employer who felt that way!
I was ultimately fired because the boss cared more about
expeditiousness than about quality. That, and I think he
tired of some of my behavioral quirks..... ;-)
-doug q
-doug q
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. 
19 Jun
19 Jun
9:14 a.m.
Douglas Quebbeman <dhquebbeman(a)theestopinalgroup.com> wrote:
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.
Hi
While it is possible to write bug-free code on paper,
it is generally considered a waste of valuable time
to no use feedback methods that include running the code
on real machines. What is actually important is getting
a bug free product in the shortest amount of time.
It is better to have a method of incremental testing that
can uncover bugs early than to have someone that spends
weeks analyzing code by inspection on paper. Most people
that program don't consider testing their code as they
write ( I'm guilty as well ). The best and the fastest
coding I've ever done included regular testing to make
sure it was working correctly. I've found from my experience
that the best code had about 50/50 write to test time
and that if I wrote code for more than 2 hours without
testing, the debugging time would increase.
Following good programming rules helps to generate good
code but doesn't guarantee it. I will break these rules
cautiously when it is desirable towards that end result.
It is vary important that one understand the potential problems
this can later cause and include test code ( commented out )
that a later programmer can use to make sure it is
functioning correctly.
Rules like " Don't make self modifying code." are good
general rules but entire languages are based on doing
just that. Does it make the language bad? No, it is
just that one must use careful and restricted use of things
that can be more easily messed up. Incremental testing
is still the key. Without it, even Ada is a bad programming
language.
IMHO
Dwight
2:26 p.m.
On June 17, Dave McGuire wrote:
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.
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. 
3:10 p.m.
Mike Ford wrote:
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.
It's certainly the case that as a consequence of all the time I spent
writing code in assembly lanaguage (and all those damn code generation
and optimization courses!) that I always find myself thinking in terms
of what kind of code I expect the compiler to generate as a consequence
of the way I structure my code. On the other hand, there are some things
that the compiler is simply better at than I am; a good example of this
is instruction scheduling, particularly on superscalar machines. I'd
rather the compiler figure out how to keep the pipes full and avoid
slips rather than spend my time doing so (and probably screwing it up).
On a related topic, I too miss greenbar. Lots of room to scribble
out new code and my scrawled representations of the data structures,
all bound together in one place. I still do this on the stuff that
spews out of laser printers, but there's not nearly enough real
estate and I always end up with extra bits of paper that I am
almost certain to lose at some point or another.
--
Chris Kennedy
chris(a)mainecoon.com
http://www.mainecoon.com
PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97
3:38 p.m.
Now that brings back some memories! 1969-72 at Franklin Pierce College
writing assembly and Fortran IV stuff for a 360/60 that we timeshared
with a bunch of other schools. I/O was a Teletype machine with a
cardpunch and reader hooked up to it. The good old days??? I don't think
so! You've never know true Hell until you drop a huge deck of cards
you've worked on for a week. Craig
: 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. 
20 Jun
20 Jun
1:15 a.m.
New subject: new list for Apple II
The low end mac site just started a new list for Apple II users (all flavors).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Apple2list info at <http://lowendmac.com/lists/apple2.html>
To get single messages, send email to <get-apple2list(a)lowendmac.net>
To get digests, send email to <set-apple2list-digest(a)lowendmac.net>
To be removed from the list, send email to <no-apple2list(a)lowendmac.net>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
8804
days inactive
8805
days old
6 comments
6 participants
participants (6)
-
chris＠mainecoon.com -
dhquebbeman＠theestopinalgroup.com -
elvey＠hal.com -
eric＠brouhaha.com -
ip500＠roanoke.infi.net -
mikeford＠socal.rr.com