A review of "Coders at Work"

Once upon a time, I was proud to call myself a "hacker".  Those were the often bearded long-haired guys who knew every intimate detail of the machine. But then of course the media got a hold of the word and it came to mean a teenage kid trying to crack passwords and steal information --- also known as the "script kiddies".  I suppose that these days the preferred word might be "coders".

So, I saw a reference to the book "Coders at Work" and checked it out.  It is a collection of interviews with noted programmers and edited by Peter Seibel.  Of course, it's impossible to be completely impartial and his preferences leak out over the course of the book.   I should note that I actually know two of the interviewees and have talked to three others.

I thought I'd also use this book to remember some of my history about learning to program and various trials I've had along the way.  Seibel begins with the same question: "How/where did you learn to program?".  How and when depends critically on the interviewee.  For example, the younger members had opportunities that the older ones didn't.

For myself, the first program I ever wrote was in Sunday School.  My mother believed that children should have a religious education even if they never believed, just so they could at least see what others believed.  Strangely enough, in 8th grade some member of the Palo Alto Unitarian Church agreed to teach the class programming.  We were taught ALGOL-60 --- which was  amazing in itself.  Why ALGOL?  Because SRI had a B5500, that's why.  And so I grabbed some equations from my friend Tracy Mallory's father's physics PhD thesis --- something about waveguides I'm fairly certain.  And I coded it up on special coding sheets.  And it ran.  Of course I had no idea if the numbers were right or not.  As Hamming so famously put it: "The purpose
of computing is insight, not numbers".  But it wasn't until I landed in the Hewlett-Packard Microwave Lab that I really started to write programs.  One of my sponsors suggested that I should learn to program.  There was a small room with four noisy ASR-33 teletypes.  The passwords were on the wall. The programming language was BASIC, either on a GE-645 or the Tymshare SDS-940.  I liked the Tymshare system better but was getting bored writing BASIC and was up for a challenge.  So, I started to write a program to use as many of the OS system calls as possible.  I was spending hours and HP's money.  Because I put my name in the code, I was eventually asked to cut it out.  But by then it was too late, I had found the East Meadow machine room of Tymshare and I was hired that summer.

Back to the book: There are various quotes that stood out.  Here's one from the first chapter: Seibel: "Do you like Perl or is it just handy?" Zawinski: "Oh, I despise it.  It's a horrible language.  But it is  installed absolutely everywhere."

Absolutely 100% in agreement.  Using Perl is awful.  It reminds me of the old Lavoris commercial:  "Do you like the taste of Lavoris?  It's awful, but I use it twice a day!".  I only use Perl when I feel awk is just too painful. It doesn't happen that often.  The next interviewee totally disagrees with the Perl hate and professes his love for Perl.  I know there are people like that.  I don't understand it.

Seibel:: "I've noticed that one thing that separates good programmers from bad programmers is that good programmers are more facile at jumping between layers of abstraction..."

That's a critical aspect of programming and I don't know how to teach it. The idea that you can "drill down" to the bug, fix it and then pop back up without understanding most of the code is challenging to many.  Of course, it depends on the bug.  Some are just too entwined.

Seibel: "Is there a key skill programmers must have?"  Zewinski: "Well, curiosity -- taking things apart.  Wanting to know what's going on under the hood."

I disagree.  For me, absolutely, it's all about the machine.  For others who don't have that aspect, no.

Seibel: "Do you have any advice for self-taught programmers?"  Fitzpatrick: "Always try to do something harder... Read Code...  Then I really enjoyed reading code, because whenever I didn't understand some pattern, I was like, "Wait, why the fuck did they do it like this? ... Wow that is really clever..."

Yes, reading code is how I learned the SDS-940 assembler as well as the  PDP-10 assembler.  There's really no substitute for reading code.   I spent most of my latter high school years code at night.  Sussman at MIT once told me that the way to teach a new language was to have students read code and augment it.  I tried this and was impressed how much the students benefited from this approach.

Seibel always asks a question about Knuth's books.  Everyone admits to  at least glancing at them.  Some of the interviewees admit to being not very mathematical (and Knuth's books can get very mathematical) but my impression is that everyone asked the question knows and appreciates them. I got my first volume as a going away present from Tymshare when I went to college (Thanks Norm and Ann!)

Another popular question for Seibel is "What is the worst bug you have ever had to track down"?  For me, the answer is easy: it was the compacting relocating garbage collector in Bravo, the first WYSIWYG editor.  The problem was that it would crash but of course this was the result of a bad pointer.  And when you have a compacting GC, you are moving data around and possibly not updating pointers.  As I recall, it took me two days of concentrated and painstaking work.

Seibel: "Because, like the Spanish Inquisition, no one really expects floating point".

One assumes that the realm of floating point only belongs to the numerical analyst.  In fact, numerical programming haunts everyone when they deal with signals from the real world.  And so I discovered when I wanted to process audio signals.

Seibel: "As a programmer, do you consider yourself a scientist, an engineer, an artist or a craftsman"?

I think this is a matter of self-perception.  These days I view myself as a kind of sloppy engineer.  The advantage of software is that mistakes can often corrected rapidly.  In hardware, it can be horrible --- like the time I reversed a 32 bit bus and had to unwrap all the wires and then rewrap them. (Wire wrapping is why rock and roll was invented, I am sure).

Guy Steele: "I set out to be a pure math major... and then discovered I had no intuition whatsoever for infinite dimensional Banach spaces. That's what did me in."

I regret to say that's what did me in, in a matter of speaking.  In my  case it was Real Analysis.  I realized I just didn't have the insight. It didn't matter that I could do multi-dimensional calculus until the cows moo-ed.  This was different.

Steele: "It's hard to find good code worth reading.  We haven't developed a body of accepted literature..."

I couldn't agree more.  With the emphasis on open source, we (as a community) recognize various programs as being exceptionally well written.  Of course, who makes that decision?

Peter Deutsch: "If you look at programming languages I would make the strong case that programming languages have not improved qualitatively in the last 40 years. There is no programming language in use today that is better than Simula-67"

No comment!

LPD: "The reason I don't program in Lisp anymore: I can't stand the syntax."

This is remarkable.  Peter wrote one of first interpreters of LISP for the PDP-1 (he was in high school).  He wrote his dissertation in LISP (as I did as well).  And now...

LPD: "Well, my description of Perl is something that came out the wrong end of a dog.  I think Larry Wall has a lot of nerve talking about language design --- Perl is an abomination as a language.  But let's not go there."

Tell it!

Ken Thompson: "But I love the teaching: the hard work of the first class, the fun of the second class.  Then the misery of the third."

Amen!  Tell it!

KT: "The PDP-11s a great LISP machine.  The PDP-10's a great LISP machine. There's no need to build a Lisp machine that's not faster."

This was lesson of Symbolics and the lisp machine craze.  The moral of the lesson (I learned this as well) is that Moore's Law waits for no one.  And you can emulate a Lisp machine on stock architecture as faster than custom hardware.  A hard lesson.

KT: "99% of the time something simple and brute-force will work fine."

This is really important.  Often we often tend to grab these real fancy dancy all-singing all-dancing data structures but in fact a simple linked list search will do Just Fine.

Fran Allen: "We have seriously regressed since C developed.  C has destroyed out ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a HLL to the machine.  This is one of the reasons compilers are ... basically not taught anymore in the colleges and universities."

I disagree.  That's not the issue.  In fact, much of compilers have become boiler plate --- lexical analysis and parsing are both table driven these days.  So, what does that leave us?  Also, the regularization of machine architecture means that the wide variety of machine designs are gone.  So all those fancy algorithms are not required (remember Call by Name?!?).  Also, there are Domain Specific Languages (DSLs) that require compiler construction techniques.

The last interview is with Don Knuth.  And that's an appropriate end to an interesting book --- I'm not sure I learned anything new, but I enjoyed seeing how other programmers approached their art/craft.