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.
