Computerworld is undertaking a series of investigations into interesting programming languages. In the past we have spoken to Larry Wall, creator of the Perl programming language, Don Syme, senior researcher at Microsoft Research Cambridge, who developed F#, Simon Peyton-Jones on the development of Haskell, Alfred v. Aho of AWK fame, S. Tucker Taft on the Ada 1995 and 2005 revisions, Microsoft about its server-side script engine ASP, Chet Ramey about his experiences maintaining Bash, Bjarne Stroustrup of C++ fame and Charles H. Moore about the design and development of Forth.
More recently, we heard from Groovy Project Manager, Guillaume Laforge. He told us the development story behind the language and why he thinks it is grooving its way into enterprises around the world.
This time we spoke with Brian Kernighan — a figure who helped popularise C with his book, co-written with the creator Dennis Ritchie, The C Programming Language and contributed to the development of AWK and AMPL.
Want to see a programming icon interviewed? Email Computerworld or follow @computerworldau on Twitter and let us know.
You maintain you had no part in the birth of C, but do you think the language would have been as successful as it has been without the book? Brian Kernighan: The word is not ‘maintained’; it's ‘stated accurately’. C is entirely Dennis Ritchie's work. C would have done just fine on its own, since as a language it achieved a perfect balance among efficiency, expressiveness, and power. The book probably helped, though I think more in spreading the language early on than in its ultimate acceptance. Of course, it helped enormously to have Dennis as co-author, for his expertise and his writing.
In the ten years since you launched The Practice of Programming, a separate book written with Rob Pike, has the way programmers operate changed enough for you to consider amending any parts of the publication?
Programming today depends more and more on combining large building blocks and less on detailed logic of little things, though there's certainly enough of that as well. A typical programmer today spends a lot of time just trying to figure out what methods to call from some giant package and probably needs some kind of IDE like Eclipse or XCode to fill in the gaps. There are more languages in regular use and programs are often distributed combinations of multiple languages. All of these facts complicate life, though it's possible to build quite amazing systems quickly when everything goes right. I think that the advice on detailed topics in The Practice of Programming is sound and will always be — one has to find the right algorithms and data structures, one has to test and debug and worry about performance, and there are general issues like good notation that will always make life much better. But it's not clear to me or to Rob that we have enough new good ideas for a new book, at least at the moment.
What advice do you have for young programmers starting out? Would you recommend a grounding in Cobol like you had, for example?
Every language teaches you something, so learning a language is never wasted, especially if it's different in more than just syntactic trivia. One of Alan Perlis's many wise and witty epigrams says, "A language that doesn't affect the way you think about programming is not worth knowing". On the other hand, I would not suggest Cobol as a primary focus for most people today — I learned it as part of a summer job and long ago, not because it taught me something new (though it did that as well). No matter what, the way to learn to program is to write code, and rewrite it, and see it used, and rewrite again. Reading other people's code is invaluable as well. Of course all of these assume that the code is good; I don't see a lot of benefit in reading a lot of bad code, other than to learn what to avoid, and one should, of course, not write bad code oneself. That's easier said than done, which is why I stress rewriting.