Punch cards

[Bill Davidsen]

Les wrote:
> On Sun, 2008-04-06 at 18:51 -0500, John Thompson wrote:
>> On 2008-04-04, Robert Rabinoff <rar113 at columbia.edu> wrote:
>>
>>> When I first learned to program in 1964 we used an IBM 1620, fondly known
>>> as CADET (Can't Add, Doesn't Even Try). 
>> Heh. My one-and-only formal computer class was learning FORTRAN, which 
>> we ran on an IBM 1620. The computer had more important things to do than 
>> run student programs, so we would write them out in spiral bound 
>> notebooks in class and as homework, then come to the computer center 
>> after hours when the keypunches weren't being used for more important 
>> work, punch the cards and put them in the job queue to be run over night 
>> (we weren't allowed to touch the sacred computer). The next day we'd 
>> come back for the job printout (on wide greenbar paper, of course), 
>> peruse the errors in our programs, punch new cards, drop them in the 
>> queue and repeat until it worked. 
>>
> Most of us "old timers" have been through this.  I think that this
> exercise made us better programmers.  We learned to write code with
> fewer errors so that we didn't have to do multiple iterations.  Of
> course it also meant that we didn't do too much exploration with novel
> algorithms, and that was a real impediment to evolution of the
> programming.
> 
> However, without that experience, programmers today are somewhat less
> efficient due to the cut/paste/debug/repeat programming style and when
> something works once, move on.  This leaves some of the more esoteric
> bugs like open ended strings, buffer overflows, memory leaks, openended
> chains and so forth, to be discovered in use, with the attendant
> problems of finding isolating and repairing them falling on other
> shoulders.  The various Programming Proverbs books do a pretty good job
> of pointing out some of the issues, but nothing works like experience.
> 
> One of my favorite books was Algorithms + Data Structures = Programs.
> Don't remember who wrote it, and I'm sure it is somewhat archaic right
> now, but the lessons about how you structure the data impacting the
> speed and efficiency of a program were precious to me.
> 
> When I learned to create double-linked chains for data structures, I was
> able to create new and novel programming techniques, and coupled with a
> good round of lessons on sorting (bubble, double bubble, hash tables,
> quick sort and insertion sort ) along with some illustrations of speed
> of sort vs data table size, and how to utilize one for one type of data
> and another for different data entry, I gained great insight.
> 
> Another algorithm that I love, but don't yet fully understand is the
> PRML algorithm.  I think it has lots of applications if one can
> structure the data as a net.
> 
> Optimal path algorithms are also worthy of some additional study.
> 
> And if you are doing image processing some 2d Fourier Transforms, and
> some efforts with Gaussian filters is great.  If you do not know what
> these are, please look them up.  Some of the new pattern recognition
> stuff is pretty neat, too, but I am not as conversant with them as with
> the others.  Line following algorithms, and other algorithms to help
> separate images from each other are great, too.
> 
> Some of the newer speech recognition algorithms are so proprietary you
> cannot see their underlying algorithms, but this is an area worthy of
> greater study as well.
> 
> Distributed computing is neat, and I am interested in its operation,
> scheduling, flagging data, and separating algorithms are also areas of
> interest.  I still have a book on CAPP architectures here somewhere.  I
> think that the 80386(tm) processor had some special registers to enable
> CAPP operations on a hardware level, but I believe they were dropped
> with the 80486(tm) and later processors.
> 
> You can read libraries of books to learn about what is out there, but
> coding and getting a few dozen good algorithms to work that apply to the
> 80% job of your desired work will take you a long way to being one of
> the top guys.  Then learning how to find and implement new algorithms
> will take you the rest of the way, in my experience.
> 
> And for all the emphasis on Object programming, either OO which only
> works at compile time, or realtime objects, without ultimately having
> good underlying algorithms, the programs are just poor examples of how
> to confuse the person reading or working on your code.  Comments are
> necessary, and for objects documentation about the object, its data
> structures, and the available algorithms is important to make them
> really portable and useful.  
> 
> Repeat after me:  Self documenting code is an oxymoron.
> 
> And even if you are a wizbang programmer, if your code is too obtuse
> (and I have written my share of obtuse programs), if the next guy cannot
> understand it, or what it actually does, it is not effective in the real
> world.
> 
Complex code is an issue, and comments only help a little. I once wrote 
a line of code for a device driver which started with a formfeed and 42 
or so lines of comment explaining it, and why it had to be a single line 
(so the compiler would generate correct code).

Some moron summer intern rewrote it as unmaintainable, and converted it 
to easy to read and understand non-working code. He wasn't offered a job 
after graduation...

-- 
Bill Davidsen <davidsen at tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot