Masterminds of Programming by Federico Bioancuzzi and Shane Warden and published by O'Reilly and Associates is a large (480 pages), dense book packed full of exposition about language design, software engineering practices, software development lifecycle methodologies, Computer Science curricula, and unique insights into computer and computation history.

The format of the book is straightforward. Each chapter is dedicated to a programming language and contains a series of questions by the authors and responses from designers and creators of the language being highlighted.

I expected the chapters on languages I was familiar with to be the most interesting and those I was not familiar with to be the least interesting but my experience was the opposite. Chapters highlighting languages that I have had no exposure to such as Forth, APL, ML, and Lua were full of intriguing information, especially languages that were designed in the 1960s or 1950s. It's fascinating learning about how these languages came to be given the relatively restrictive hardware they were developed with.

Other languages highlighted in the book include:

• Python
• Perl
• Java
• C++
• C#
• Objective-C
• UML
• AWK
• Postscript
• Eifel
• Haskel
• BASIC

The book is just overflowing with powerful quotes that carry substantial meaning to developers, language designers, and managers. Here are a few that stood out to me.

> "Whenever I hear people boasting of millions of lines of code, I know > they have grieviously midunderstood their problem. There are no > contemporary problems requiring millions of lines of code. Instead, there > are careless programmers, bad managers, or impossible requirements for > compatibility." --Chuck Moore in the Forth chapter

> "As processors continue to get faster and memory capacities rise, it's > easier to do quick experiments and even write production code in > interpreted languages (like AWK) that would not have been feasible a few > decades ago. All of this is a great win.

> "At the same time, the ready availability of resources often leads to > very bloated designs and implementations, systems that could be faster > and easier to use if a bit more restraint had gone into their design. > Modern operating systems certainly have this problem; it seems to take > longer and longer for my machines to boot, even though, thanks to Moore's > Law, they are noticeably faster than the previous ones. All that software > is slowing me down." --Brian Kernighan in the AWK chapter.

> "Software engineering is in many ways a very pathetic field, because so > much of it is anecdotal and based on people's judgements or even people's > aesthetic judgements." -- Peter Weinberger in the AWK chapter

> "The software business is one of the few places we teach people to write > before we teach them to read. That's really a mistake." -- Tom Love in > the Objective-C chapter

> "What do you think the chances are that Microsoft applications get slower > and slower because they haven't managed memory properly? Have you ever > met a three-year-old Microsoft operating system that you wanted to use? I > actually operate with a laptop that has a Microsoft-free zone. It's > amazing how much more productive I am than other people sitting in the > same room with Microsoft computers. My computer is on, and I've done my > work, and I've closed it down before they've gotten to their first Excel > spreadsheet." -- Tom Love in the Objective-C chapter.

> "If you study gold or lead from day to day, you can measure the > properties and employ scientific methods to study them. With software, > there is none of that." -- Brad Cox in the Objective-C chapter.

> "C# basically took everything, although they oddly decided to take away > the security and reliability stuff by adding all these sorts of unsafe > pointers, which strikes me at grotesquely stupid, but people have used > most of the features of Java somewhere." -- James Gosling in the Java > chapter responding to the question related to C# being inspired by Java.

> "I think architecture is very important, but I am cautious about labeling > individuals as architects, for many reasons. Many times I have seen > companies with a team of architects that they send to other organizations > to work on projects. That may be fine if they work inside a particular > project, but companies such as big banks usually have a group of > enterprise architects that sit and draw representations of the > architecture. Then they throw this over the wall to the developers. The > developers just ask themselves: 'What is this? It's useless.' In many > companies, enterprise architects sit in an ivory tower without doing > anything useful." -- Ivar Jacobson in the UML chapter

> "Developing software is not rocket science. Look at the 5-10 million > people who call themselves software developers. Very few of them really > do anything creative of fundamentally new. Unfortunately, the outside > world thinks that programmers are creative and brilliant people, and > that's far from reality." -- Ivar Jacobson in the UML chapter.

> "I rarely have met a programmer who understands the principles of > computational complexity and puts them into practice. Instead they fuss > with all kinds of pointless suboptimizations that are 'pennywise and > pound foolish... I think the most important skill in computing (as in > physics and other creative fields) is the ability for abstraction." > --James Rumbaugh in the UML chapter.

> "I have found over my career, whether it be researchers or engineers, > that in addition to the sort of intellectual skills that they manifest, > if they are people who finish what they set out to do, they tend to be > much more productive and have a much larger impact." -- Charles Geschke > in the Postscript chapter.

These quotes are just scratching the surface.

Many of the interviews discuss history of computer science and computation theory. For example, Charles Geschke and John Warnock gave answers in the Postscript chapter detailing how Xerox PARC came into existence out of ARPA's emphasis on digital communications which was the result of thinking within the Eisenhower and Kennedy administrations.

Because of the simple, straightforward format of this book, there is definitely room for improvement. For example, readers unfamiliar with certain languages would find it immensely useful to see examples of the language in use. One thought is that each chapter could start with a code excerpt showing how a programmer might use the highlighted language to solve a generic problem. Readers could then see, in code, how each language differs in their approach to the same problem.

Each chapter is preceded by one paragraph description of the language which may contain brief history of the language's history. This could definitely be expanded upon. This book is big already and I don't think O'Reilly's goal is to make it a computer language text book, but it would be useful if each chapter started with 2-4 pages of introductory abstract about the language.

The authors have placed biographical information about each of the contributing interviewees in a Contributors appendix near the end of the book, but it would be more helpful to the reader if this information appeared at the beginning of each chapter instead.

Masterminds of Programming is available at a suggested price of $39.99. I rate it at four and a half stars.