“Absolutely amazing! A page turner, just like Harry Potter for the technically minded.” —Tobias Svensson from review at return 42;

“This book is so interesting I did 60 minutes on the treadmill yesterday instead of the usual 30 because I couldn’t stop reading.” —Joel Spolsky on Joel on Software

“Coders at Work should inspire readers to learn about the wider context of their craft and stop the reinvention of the proverbial wheel” —Vladimir Sedach from review at Slashdot

“Peter Seibel asks the sort of questions only a fellow programmer would ask. Reading this book may be the next best thing to chatting with these illustrious programmers in person.” —Ehud Lamm, Founder of Lambda the Ultimate - the programming languages weblog

“I highly recommend it.” —Andy Mulholland, CTO, Capgemini

“I have long known the names and of the work of about half of the programmers in Peter Seibel’s wonderful book, Coders at Work; and it is fascinating to read their ideas about their lives and their ideas about programming. Better yet, I have now learned about the lives and philosophies of the other half of the programmers in the book, whose systems were known to me but the programmers themselves were not. Anyone interested in computer programming and what makes a great computer programmer will enjoy this book.” —Dave Walden, original member of the BBN ARPANET team

“These are wonderful interviews and this looks to be a bible for any programmer who aspires to be better.” —Peter Christensen, Founder of GeekStack.com

“This book is dead sexy. When it comes out, you should definitely get a copy.” —Joseph F. Miklojcik III from review at jfm3> _

“Superb book!” —Prakash Swaminathan from review at CloudKnow

“Read it, because then you will know the greatest coding brains.” —Amit Shaw from review at Teleported Bits

“One of the other core questions Peter asks is, what books would you recommend to help a developer learn programming? For me, this book joins my short list—it takes you away from the limitations of learning within a single company or community, and shows you the breadth of experiences that can make someone a great developer.” —Marc Hedlund from review at O’Reilly Radar

“The range of topics covered is just astounding.” —Chris Hartjes from review at @TheKeyboard

Guy Steele

Guy Steele is a true programming polyglot. When I asked him what languages he has used seriously he came up with this list: COBOL, Fortran, IBM 1130 assembly, PDP-10 machine language, APL, C, C++, Bliss, GNAL, Common Lisp, Scheme, Maclisp, S-1 Lisp, *Lisp, C*, Java, JavaScript, Tcl, Haskell, FOCAL, BASIC, TECO, and TeX. “Those would be the main ones, I guess,” he added.

He had a hand in the creation of both of the major surviving general-purpose Lisp dialects: Common Lisp and Scheme. He served on the standards bodies that defined Common Lisp, Fortran, C, ECMAScript, and Scheme and was recruited by Bill Joy to help write the official language specification for Java. He is now at work designing Fortress, a new language for high-performance scientific computing.

Steele’s academic career included an AB from Harvard and an SM and PhD from MIT. While at MIT he collaborated with Gerald Sussman on a series of papers now known as “The Lambda Papers,” which included the original definition of the Scheme programming language. He has also been a chronicler of hacker culture as one of the original compilers of the Jargon File and editor of the book version, The Hacker’s Dictionary (subsequently updated and expanded by Eric S. Raymond as The New Hacker’s Dictionary). And he played an important role in the birth of Emacs and was one of the first programmers to port Donald Knuth’s program TeX.

Steele is a Fellow of the Association for Computing Machinery and the American Academy of Arts and Sciences and a member of the U.S. National Academy of Engineering. He won the ACM’s Grace Murray Hopper Award in 1988 and Dr. Dobb’s Excellence in Programming Award in 2005.

In this interview he talks about designing software and the relation between writing and programming, and he gives one of the best explanations I’ve ever heard of the value—and limitations—of formal proofs of correctness.