“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 |
Simon Peyton JonesOne of the instigators, back in 1987, of the project that led to the definition of the programming language Haskell, Simon Peyton Jones is a Principal Researcher at Microsoft Research’s lab in Cambridge, England. He edited the Haskell 98 Revised Report, the current stable definition of the language; he is the architect and lead developer of the Glasgow Haskell Compiler (GHC), the “de facto standard compiler” according to A high-powered researcher and former professor who never got a PhD, Peyton Jones values both the practical and the theoretically beautiful. He learned to program on a machine with no permanent storage and only 100 memory locations, and in college he worked on both writing high-level compilers for the school’s big iron and building his own primitive computers out of parts he could afford on a student’s budget. But he was drawn to functional programming by a professor’s demonstration of how to build doubly linked lists without using mutation and the beauty of the idea of lazy evaluation. Peyton Jones saw the ideas of functional programming “as a radical and elegant attack on the whole enterprise of writing programs”: a way, rather than “just putting one more brick in the wall,” to “build a whole new wall.” In 2004 the Association for Computing Machinery elected him a Fellow, citing his “contributions to functional programming languages.” Among the topics we covered in this interview are why he thinks functional programming shows increasing promise of changing the way software is written, why Software Transactional Memory is a much better way of writing concurrent software than locks and condition variables, and why it is so difficult, even at a place like Microsoft Research, to do real studies of whether different programming languages make programmers more or less productive. |