“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
Dan Ingalls
If Alan Kay is Smalltalk’s father, Dan Ingalls is its mother—Smalltalk may have started as a gleam in Alan Kay’s eye, but Ingalls is the one who did the hard work of bringing it into the world. Starting with the first implementation of Smalltalk, written in BASIC and based on one page of notes from Kay, Ingalls has been involved in implementing seven generations of Smalltalk from the first prototype to the present-day open source implementation, Squeak.
Originally a physicist, Ingalls started programming with Fortran, made a business selling a profiler he wrote while in grad school, and eventually found his way to Xerox PARC, where he joined Kay’s Learning Research Group, which built Smalltalk and explored the use of computers in children’s education.
While at PARC, Ingalls also invented the BitBlt operation used in bit-mapped graphics and coded it in microcode for PARC’s Alto computer, allowing the high-performance bit-mapped graphics that enabled UI innovations such as pop-up menus that we now all take for granted. (At one of Ingalls’s in-house demonstrations of the Smalltalk system, a pop-up menu caused the subject of my next chapter, L Peter Deutsch, to leap to his feet and exclaim, “Did you just do what I thought you did?”)
Now a Distinguished Engineer at Sun Microsystems, Ingalls is working on Lively Kernel, a Smalltalk-like programming environment that runs completely in the browser using JavaScript and browser-provided graphics. He received the Association for Computing Machinery Grace Murray Hopper Award in 1984 and the ACM Software System Award in 1987 for his work on Smalltalk. In 2002 he won the Dr. Dobb’s Excellence in Programming Award.
In our conversation, we talked about the importance of interactive programming environments, why it was a lucky thing he never learned Lisp, and why it’s better to build flexible, dynamic systems and then lock them down rather than building static systems and then trying to add dynamic features.