coders at work
Peter Seibel
The book is a collection of conversations with some very well known figures in the computing world. These people have done significant contributions to the body of knowledge and are “inventors/practitioners” of Unix/C, Lisp, Java, Erlang, TeX etc.
Peter has done a great contribution to the computing world by bring out this book (not to mention his other great book “Practical Common Lisp”). The subjects seem to have been very carefully chosen and are experts in their respective fields. But did I miss anyone? Yes, Richard Stallman. He has done some really great deal of programming, all by himself. Nevertheless, this book is a great contribution into the field of Computing folklore and biographies and is very very inspirational. Hats off to Peter for painstakingly undertaking this massive activity of researching the backgrounds and also for researching various topics. It is not easy to talk to these great people in the same language.
The questions are spontaneous and encourages the people to open up the story gradually. Mix of context specific ones and generic ones. Peter also seem to have been careful about not getting into a duel on various usual flamewars. For instance, Peter never asked the question “Vi or Emacs?”.
These are some of the questions, Peter seem to have asked everyone.
- When did you start to program? (A great deal discussion follows on details about the machine and methods used.)
- What are your usual ways of debugging? Do you use print statements or use a debugger ?
- Do you consider yourself as a programmer or an engineer or a craftsmen or an artist?
- What are the differences between programming and prose writing?
- What is different in the programming between then and now? This is usually followed by really good discussions of the difficulties of modern day coding with layers on top of layers. Even though source code is available, the sheer amount of knowledge on various libraries and abstractions built by modern day computing systems make it very difficult for a newbie to understand what is going on under the hood. It also make the system inefficient because the computing hardware has become better and cheaper and so no one cares for these things.
- What are your favourite programming books? Needless to say, "The art of computer programming" is in the list. Some said, they read all volumes cover to cover.
- What is beautiful code? Importance of reading good code.
- How do you read code?
It is amazing, how early some of the people touched their first computers. Remember these are 60s and 70s and not even 80s. Contrasting this with my own experiences, I think I am one of the many nfortunates who had no idea what computers are until I went to the college for undergraduate degree.
It is also amazing to see that these folks are still tinkering with the machine and programming, pretty much every day. In contrast, my job is trying to keep me away fron hands on programming. I am instead trying to work with what others have done and bending it to work with other things and in the process, not writing much code at all.
The discussions are very casual and not formal. It will be very interesting to hear the audio recordings of these conversations, which will obviously have much more interesting anecdotes and stories which Peter couldn’t have been able to incorporate into the book. Most subjects are older programmers. There are few younger ones.
- Fitzpatrick: Importance of statistics.
- Peter seem to have researched his subjects very well and have digged most of the information about them off the web. For example, he talks about Fitzpatrick's student day Livejournal entries, one of which said, he was stressed out and hated computers.
- Most people used print statements instead of symbolic debuggers.
- C++ hate seem to be a common thread.
- code reviews as a pre-commit step.
- bottom-up approach to coding. One exception was Joshua Bloch who said, he does the APIs first and then the implementation, which felt like a top-down method to me.
Some quotes from the book.
- "C is a portable assembler"
- "You can reason from effects back to causes. Which is the whole game in debugging"
- "I tend not to buy into religions, any religions, whole hog. Whether it is object oriented programming or functional programming or Christianity or Judaism, I mine them for good ideas but I don't practice them in toto." : Joshua Bloch
- " Oh, it's not worth the time, it's just the name of a variable, just don't get it. You're not going to produce a maintainable program with that attitude." Joshua Bloch
- brilliant quote by Tony Hoare in his Turing Award speech about how there are two ways to design a system: "One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies."
- "Bloch: I believe that code ownership can't be denied. In a way, it's like motherhood - you give birth to the code that you write, and especially if it is large, complex or original, it is yours."
- Joe’s Law of Debugging, which is that all errors will be plus/minus three statements of the place you last changed the program
- “Just start something, no matter how humble.” John Washbrook, a senior academic told Simon Peyton Jones. How true this is, as one begins a new programming project with a blank editor in front.
- "programming languages are the user interfaces of programming": Simon Peyton Jones.
- "Every five pages of my book is somebody's career" : Donald Knuth.
- "The first rule of writing is to understand your audience—the better you know your reader the better you can write, of course. The second rule, for technical writing, is say everything twice in complementary ways so that the person who’s reading it has a chance to put the ideas into his or her brain in ways that reinforce each other." : Donald Knuth
- "The problem is that coding isn’t fun if all you can do is call things out of a library, if you can’t write the library yourself. If the job of coding is just to be finding the right combination of parameters, that does fairly obvious things, then who’d want to go into that as a career?" : Knuth
Guy Steele and Peter Norvig interviews turned out to be great. I then read Simon Peyton Jones and that was great. Every interview turned out to be better than the previous one, whichever order you read it! I just wished there were more. May be dead tree books are a bad choice for such things.
Ken Thomson’s interview had quite a lot of surprises. I just loved this interview. Ken just opens up his mind on various very interesting things.
Peter, though an author of a successful Lisp book, never gets into an argument with Ken Thomson, when he kind of, thrash the Lisp machine concept and the mentality of MIT hackers at that time to compete with the Unix. I was also surprised when Ken said he had not heard of the “Worse is better” paper of Richard Gabriel which compares the Boston style vs New Jersey Style of computing. I also couldn’t justify the vague answer Ken gave regarding Buffer overflowscaused by slppy coding of C/C++ programs. Also Ken said, at Google he has no check-in rights. He also said he despise C++ (like many others in the book and elsewhere) developed by his ex co-worker. C++ has too many features and everyone use a subset of it. Ken clearly says that it is a badly designed language.
Ken also says about the well known story of his wife and kid who went away for a month when Ken was happily programming pieces of Unix at a fast pace. Ken says that when your wife and kid are away, you no longer have to sync with the Sun’s cycle of 24 hours and that he never experienced any stress during that time. Ken also feels (like his friend Rob Pike) that nothing new is happening in the computing world. According to him, the last significant change was the Internet. Ken also shares the same thought, which many others also expressed, that the modern day programming is all about layers on top of layers on top of layers and that a program depends on 40 different libraries which in turn depends on more libraries and at some point, one just can’t keep all that in one’s head. On top of it, things are now distributed with messages being passes from one place to another. Modern day free software projects like GNOME and Mono and gtk are good examples of this phenomenon. Personally, I find it extremely hard and intimidating to even figure out where to start looking if I see a problem and the very thought of it scares me away from such an undertaking. One instance is that on my laptop, the speaker volume control always resets to mute every time I bootup, no matter what the volume level was during the previous bootup. I had been trying to track the problem down for quite a while and finally the layers scared me away and I gave up.
There are some good discussions and contrasting opinions on Unit Testing and how and when to do it. Some of these have hit the headlines recently.
Overall, it is a very inspirational book for programmers and everyone interested in the craft or art or religion or whatever you call it, should read it.
Syndicated 2009-10-04 07:00:00 from Ramakrishnan Muthukrishnan