8 Apr
2006
8 Apr
'06
10:14 a.m.
On 4/8/2006 at 6:17 AM Don Y wrote:
But, your point is well taken -- with faster and
faster
development tools, people seem to just make a change, type
'make' and "let's see if that works" (instead of *knowing*
if it SHOULD work). I think this is where a lot of bugs
creep into designs -- once it *appears* to work, they move
on to the next problem without sorting out why this
problem needed that particular fix...
I used to have in my papers an IBM "Absolute Coding System" pad. What's
that, you ask? Well, it looks like any other coding form, (green and white
bars), but the leftmost column is marked "Address", the next column
"Opcode", and the next "Operands". Yup--machine code programming!
You
write the digits in yourself, satisfying references, computing the next
address, etc. I don't think that using the "absolute" method made me a
better coder, though it did etch in my mind a collection of now-useless
opcodes.
I'm not sure if the non-interactive development methods produce better
code. Programmers still produced terrible code back in the old days. When
I finally got a CRT in my office, the thing I noticed was how QUIET it was.
I never could think straight in a room full of a keypunches banging
away--and when I needed to troubleshoot OS code, I'd grab my dumps and
listings, leaving the system sit idle and find a lounge or conference room
where I wasn't being bombarded wtih 85 dB of white noise from the
equipment.
In the old days, ICs were laid out by hand and a wirewrap prototype
constructed. Now, a designeer can work up his design and get a fair idea
of its operation using simulation software. I think design has benefitted
from the newer "shortcut" methods.
Cheers,
Chuck