Thomas Duff said
So you don't get to be a mastermind behind a widely used programming language without having a pretty deep knowledge of computer science (and quite a few other things). But you *certainly* don't have to agree with other masterminds on what works and what doesn't. This shows very clearly in the book Masterminds of Programming: Conversations with the Creators of Major Programming Languages by Federico Biancuzzi and Shane Warden. They interview a number of the people behind some of the popular and influential computer languages and record those interviews for the reader. I think what I found most interesting is that there's no "right" answer about what works and what doesn't, and much depends on what niche the language will end up covering.
Contents:
C++ - Bjarne Stroustrup; Python - Guido von Rossum; APL - Adin D. Falkoff; FORTH - Charles D. Moore; BASIC - Thomas E. Kurtz; AWK - Alfred Aho, Peter Weinberger, and Brian Kernighan; LUA - Luiz Henrique de Figueiredo and Roberto Ierusalimschy; Haskell - Simon Peyton Jones, Paul Hudak, Philip Wadler, and John Hughes; ML - Robin Milner; SQL - Don Chamberlin; Objective-C - Brad Cox and Tom Love; Java - James Gosling; C# - Anders Hejlsberg; UML - Ivar Jacobson, James Rumbaugh, and Grady Booch; Perl - Larry Wall; Postscript - Charles Geschke and John Warnock; Eiffel - Bertrand Meyer; Afterword; Contributors; Index
I found this wasn't the easiest book to read, as it got deep into some very esoteric topics, and the interviews were likely to go off in many different directions. As such, it wasn't as if there were a set of questions that everyone answered so that you could directly compare and constrast topics and background. Still, I found a couple of ways in which the book worked for the reader. If you're into language design, Masterminds gives you some of the inner thoughts of people who have successfully built and rolled out a computer language that has been adopted for use by others. One of the most revealing topics is how they all have dealt with the issue of upgrading and enhancing the language without breaking stuff that has been previously built. As a language ages, it has more and more "cruft" from older features that are kept around for backwards compatibility. The language developers are always walking that fine line between adding new features and making sure it will be supportable going forward. You don't really get a chance to start over and correct your mistakes once they are part of a published version.
The second way you can read the book is to use it as a personality study of a language designer. Geeks are not always known for being the most socially adept or "normal" of humans, and language designers seem to take that a step beyond. These individuals appear to be totally consumed with their computer passions, and as such have very definitive personalities and viewpoints. One designer might state that object-oriented programming is without a doubt the biggest scam pushed on developers in the last decade. Others might state with equal conviction that OOP has been the revolutionary turning point in computer science. And what one designer finds as the "must-have" concept in a language, another designer will brush off as hubris. You'd think after all these years, there'd be some points of truth that just aren't arguable. But at least in language design, that certainly doesn't seem to be the case...
Obviously, it's not possible to cover every single language that's ever been written, and I'm sure many will quibble over why a certain language was included or excluded. Regardless of that, Masterminds is still a good read if the topic is one of interest to you. You may not agree with some of the views expressed by the designers (hey, they don't agree with each other!), but at least you'll have a better understanding of why a certain path was followed.
Midwest Book Review said
Federico Biancuzzi and Shane Warden's MASTERMINDS OF PROGRAMMING provides a series of discussions with some of the creators of major programming languages, featuring exclusive interviews with the creators of several historic programming languages. From ideas that led to specific design decisions to goals of the early pioneers of software, this is an outstanding recommendation for any computer collection.
ThomasH said
Pardon me, but some of the "major programming languages" listed in this book are not so major at all. Even if skipping the very early languages like Fortran, many true titans are missing completely: Pascal and Modula, C, and of course ADA! Pascal is not even being mentioned in the index, albeit for example Brad Cox mentions it on several places in chapter 11. This brings me to the poor quality of the index in this book: ADA is being mentioned in the index with page 374, but in fact it is being mentioned by several contributors, for example by Brad Cox on page 258. Reader will quickly find numerous other misses in the index.
It is hardly appropriate to call Forth, APL, Objective-C, Eiffel or Lua etc. as "major languages." All of there were/are in a marginal use at best, or even in a complete obscurity.
Probably the selection of the languages was dictated by the set their creators being available for an interview or willing to participate in this project.
I second the opinion of other reviewers that the author of C++ all too often digresses into compares to Java, some of them of a banal nature "C++ differs from Java in that its underlying machine is the real machine rather than a single abstract machine", what is true for virtually every language translated into a specific machine code. I miss in his chapter any self critical reference to the incurring maintenance problems with C++, which are caused by its cryptic set of syntactic ambiguities and amount of implicit object creations. These features have ultimately led to a ban of C++ in some places, most notably in my company Oracle. I happen to second this decision and I believe that C++ was the most prominent example of a language misdesign, the wrong way into which the programming was pushed by coincidence of coming from the back than so famous AT&T Labs. I was hoping to read some words of self criticism. Instead, if asked why some major projects are still written in C, Stroustrup speaks on page 8 of "conservatism and inertia". Nope, its not true, its rather prudence and need to predictable maintenance.
Of course, this opinion about C++ is my own and in no way diminishing the value of this book. Its authors did asked the critical questions, and they merely quote the answers. C++ is clearly one of the major languages, for good or (as I believe) for wrong. My point of criticism on this book is lack of separation between major and secondary languages, lack of even mention of truly influential languages which changed the world of computing (Algol, Pascal), and its poor index.
Brian Peek said
I've been reading this book off and on for the past week and I have to say I'm really enjoying it. It's great to get perspectives from the creators of a variety of programming languages and learn why they made the choices they did, good or bad.
As one of the other reviewers posted here, there are some unintentional funny moments when creators of one language criticize another and aren't exactly correct in their comments. Personally, I think that adds to the entertainment value of the book and shows that we're all human.
If you're looking for a strict textbook on programming languages, this isn't exactly what you're looking for. But if you'd like to glean some insight on 17 different programming languages, their creators, and their reasoning and opinions on what they and others have done, this is an entertaining and informative read.
KoD said
Most of these "masterminds" come across as rather provincial, making for an unintentionally hilarious read. Stroustrup can't go much more than a page without complaining about Java. The creator of basic opines that, because all languages are basically the same, if you've learned one you can easily learn any . . . then later talks about how he is trying (and failing) to learn objective-C. Guido van rossum asserts that you can define reduce in a couple of lines of python, which you simply cannot do in a functional language. Huh?
reduce f z [] = z
reduce f z (x:xs) = reduce f (f z x) xs
Or is haskell not a functional language in his book, just like lisp is not a functional language?
Don't get me wrong, a few of the interviews are worth reading for something other than comedic value. When creators are actually willing to talk about the mistakes and tradeoffs they made, as the team behind Awk does, the results are sometimes illuminating. The interview with charles moore is completely insane, in a good way. Adin falkoff's comments on apl are interesting, and he does a good job of taking the high road when the interviewer attempts to provoke comparisons to other languages. Unfortunately the overall tone of the book drags it down to not much more than an amusing light read - good for a plane ride, but not worth coming back to.
Comments