What do you think?
Rate this book
Masterminds of Programming: Conversations with the Creators of Major Programming Languages
Masterminds of Programming features exclusive interviews with the creators of several historic and highly influential programming languages. In this unique collection, you'll learn about the processes that led to specific design decisions, including the goals they had in mind, the trade-offs they had to make, and how their experiences have left an impact on programming today. Masterminds of Programming includes individual interviews with:
Adin D. Falkoff: APL Thomas E. Kurtz: BASIC Charles H. Moore: FORTH Robin Milner: ML Donald D. Chamberlin: SQL Alfred Aho, Peter Weinberger, and Brian Kernighan: AWK Charles Geschke and John Warnock: PostScript Bjarne Stroustrup: C++ Bertrand Meyer: Eiffel Brad Cox and Tom Love: Objective-C Larry Wall: Perl Simon Peyton Jones, Paul Hudak, Philip Wadler, and John Hughes: Haskell Guido van Rossum: Python Luiz Henrique de Figueiredo and Roberto Ierusalimschy: Lua James Gosling: Java Grady Booch, Ivar Jacobson, and James Rumbaugh: UML Anders Hejlsberg: Delphi inventor and lead developer of C# If you're interested in the people whose vision and hard work helped shape the computer industry, you'll find Masterminds of Programming fascinating.
Adin D. Falkoff: APL Thomas E. Kurtz: BASIC Charles H. Moore: FORTH Robin Milner: ML Donald D. Chamberlin: SQL Alfred Aho, Peter Weinberger, and Brian Kernighan: AWK Charles Geschke and John Warnock: PostScript Bjarne Stroustrup: C++ Bertrand Meyer: Eiffel Brad Cox and Tom Love: Objective-C Larry Wall: Perl Simon Peyton Jones, Paul Hudak, Philip Wadler, and John Hughes: Haskell Guido van Rossum: Python Luiz Henrique de Figueiredo and Roberto Ierusalimschy: Lua James Gosling: Java Grady Booch, Ivar Jacobson, and James Rumbaugh: UML Anders Hejlsberg: Delphi inventor and lead developer of C# If you're interested in the people whose vision and hard work helped shape the computer industry, you'll find Masterminds of Programming fascinating.
480 pages, Paperback
First published April 3, 2009
71 people are currently reading
1576 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 39 reviews
November 27, 2009
Masterminds of Programming Conversations with the Creators of Major Programming Languages by Federico Biancuzzi 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.
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.
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 UML 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.
August 22, 2009
Interesting and fairly engaging, but not essential.
This was an impulse buy which threw an interrupt into my current-reading stack.
I'm glad I got it at a steep discount, because much of this looks like material one could just as profitably read on a webpage, and O'Reilly's listing it at $39.99.
As far as the content goes, I can say that it consistently held my interest. There are some entertaining snipes between various language designers about each others' work, but also a diplomatic (and, I would think, sincere) respect for each other as language designers faced with tough choices.
I'll see if I can't go back and see which of the interviewees said this, but I have to say I find seductive the statement that we don't really have a science of programming language design yet. In fact, we don't really even have a science of program debugging yet. As Knuth (not interviewed here, and only barely mentioned) famously pointed out, one can prove a program correct and yet it will still have bugs. This is often (or necessarily? I don't know) because we humans can misstate our constraints, or even forget to state them at all.
Are we in the alchemical stage of language design, searching for a philosopher's stone? Who is to be our Boyle, our Lavoisier, our Berzelius?
Or can we not answer those questions until we have first--or in conjunction--developed a solid science of mental processes? Can I goad a certain machine learning expert of my acquaintance to comment? (UPDATE: He did; see comment below.)
This book's value would have been increased to me had it contained a concluding chapter integrating much of the material presented and offering some analysis. That's probably out of its intended scope, and would likely have angered parts of the audience that didn't want to see the authors injecting themselves into the subject matter to that degree (or, by delegating authorship of such material out to another language luminary, crowning that figure as first among equals).
Though I can understand the decision to demur, I'd still like to see this material. I can make out some tensions in the philosophy of language extensions; that is, does one extend the language "directly", by adding new lexemes, or by adding new functions (usually as methods operating on an object)? I've worked with only a small number of the languages presented, but I get the impression that Forth, and some uses of Lisp/Scheme, follow the former approach, whereas the C family, Python, and Perl follow the latter. Warnock and Geschke, authors of PostScript, acknowledge that human interpretation of the language demands that the state of the stack be kept in mind for program statements to be comprehensible. This also seems to be the case with Forth and Lisp/Scheme; I find myself wondering if this trait is isomorphic to the language extension question. It doesn't seem obvious to me that it should be so--but perhaps there are constraints placed on the language designer such that one typically dictates the other? Or maybe this is just coincidence. Again, real analysis is needed.
Another area where consensus has yet to be reached involves the domain of verifiability, provability, and automated testing. Unit testing is popular in industry and among some of the interviewees, but I don't think anyone can argue that it isn't tedious. This matter, perhaps not surprisingly, dominates the interview with Bertrand Meyer more than anyone else's, and he holds forth with great confidence about his approaches. I find it tricky to reconcile that confidence with (what I perceive to be) Eiffel's ultra-minority status as a general-purpose programming language. Still, Meyer comes off as impressive and his book on OO programming is an acknowledged classic, so I think his work demands more of my attention.
Meyer also noted the SPARK language, a stripped-down form of Ada (and thus related to Pascal) which is provable (evidently in large part because it lacks pointers, and thus aliasing of memory addresses). Meyer dismisses SPARK as too limited to be broadly useful. However, I think he is hasty. I have written many small tools in my career, usually in a scripting language of some sort, and I wouldn't mind in the least if someone handed me a limited language I could use, and prove my little tools correct. I think I'd get a fair amount of satisfaction from that, particularly if it reduced the time I spent instrumenting them and chasing down bug reports about them. There is a large space of mundane little problems in the world, and I think it's a win, not a lose, if we can implement our solutions to those small, mundane problems in robust little boxes. It has to beat shoehorning more places into a complex system where things can go wrong.
Most of the classic Unix shell utilities are written in non-OO C. Wouldn't it be awesome if we could re-implement them in a provable language? (Admittedly, many/most of them use pointers extensively for reasons of speed/efficiency/elegance, and the C standard I/O library will do so, on the file streams you're manipulating, even if you don't. Oh, well--one can dream.)
Finally, I have to admit that some of the material in the book goes over my head. For example, at one point Meyer notes that dynamic binding and function pointers are incompatible language features. I have to assume this is because the way dynamic binding is implemented is by keeping function pointers internal to the implementation, such that they are rewritten as necessary at runtime once an object's type is determined. If one let the programmer muck with the pointers as well, there would be no guarantees that a method call would be resolvable (or sensible) at runtime. But I'm having to guess at this, so I could be wrong. Perhaps folks with a stronger background than I can get more out of this book.
This was an impulse buy which threw an interrupt into my current-reading stack.
I'm glad I got it at a steep discount, because much of this looks like material one could just as profitably read on a webpage, and O'Reilly's listing it at $39.99.
As far as the content goes, I can say that it consistently held my interest. There are some entertaining snipes between various language designers about each others' work, but also a diplomatic (and, I would think, sincere) respect for each other as language designers faced with tough choices.
I'll see if I can't go back and see which of the interviewees said this, but I have to say I find seductive the statement that we don't really have a science of programming language design yet. In fact, we don't really even have a science of program debugging yet. As Knuth (not interviewed here, and only barely mentioned) famously pointed out, one can prove a program correct and yet it will still have bugs. This is often (or necessarily? I don't know) because we humans can misstate our constraints, or even forget to state them at all.
Are we in the alchemical stage of language design, searching for a philosopher's stone? Who is to be our Boyle, our Lavoisier, our Berzelius?
Or can we not answer those questions until we have first--or in conjunction--developed a solid science of mental processes? Can I goad a certain machine learning expert of my acquaintance to comment? (UPDATE: He did; see comment below.)
This book's value would have been increased to me had it contained a concluding chapter integrating much of the material presented and offering some analysis. That's probably out of its intended scope, and would likely have angered parts of the audience that didn't want to see the authors injecting themselves into the subject matter to that degree (or, by delegating authorship of such material out to another language luminary, crowning that figure as first among equals).
Though I can understand the decision to demur, I'd still like to see this material. I can make out some tensions in the philosophy of language extensions; that is, does one extend the language "directly", by adding new lexemes, or by adding new functions (usually as methods operating on an object)? I've worked with only a small number of the languages presented, but I get the impression that Forth, and some uses of Lisp/Scheme, follow the former approach, whereas the C family, Python, and Perl follow the latter. Warnock and Geschke, authors of PostScript, acknowledge that human interpretation of the language demands that the state of the stack be kept in mind for program statements to be comprehensible. This also seems to be the case with Forth and Lisp/Scheme; I find myself wondering if this trait is isomorphic to the language extension question. It doesn't seem obvious to me that it should be so--but perhaps there are constraints placed on the language designer such that one typically dictates the other? Or maybe this is just coincidence. Again, real analysis is needed.
Another area where consensus has yet to be reached involves the domain of verifiability, provability, and automated testing. Unit testing is popular in industry and among some of the interviewees, but I don't think anyone can argue that it isn't tedious. This matter, perhaps not surprisingly, dominates the interview with Bertrand Meyer more than anyone else's, and he holds forth with great confidence about his approaches. I find it tricky to reconcile that confidence with (what I perceive to be) Eiffel's ultra-minority status as a general-purpose programming language. Still, Meyer comes off as impressive and his book on OO programming is an acknowledged classic, so I think his work demands more of my attention.
Meyer also noted the SPARK language, a stripped-down form of Ada (and thus related to Pascal) which is provable (evidently in large part because it lacks pointers, and thus aliasing of memory addresses). Meyer dismisses SPARK as too limited to be broadly useful. However, I think he is hasty. I have written many small tools in my career, usually in a scripting language of some sort, and I wouldn't mind in the least if someone handed me a limited language I could use, and prove my little tools correct. I think I'd get a fair amount of satisfaction from that, particularly if it reduced the time I spent instrumenting them and chasing down bug reports about them. There is a large space of mundane little problems in the world, and I think it's a win, not a lose, if we can implement our solutions to those small, mundane problems in robust little boxes. It has to beat shoehorning more places into a complex system where things can go wrong.
Most of the classic Unix shell utilities are written in non-OO C. Wouldn't it be awesome if we could re-implement them in a provable language? (Admittedly, many/most of them use pointers extensively for reasons of speed/efficiency/elegance, and the C standard I/O library will do so, on the file streams you're manipulating, even if you don't. Oh, well--one can dream.)
Finally, I have to admit that some of the material in the book goes over my head. For example, at one point Meyer notes that dynamic binding and function pointers are incompatible language features. I have to assume this is because the way dynamic binding is implemented is by keeping function pointers internal to the implementation, such that they are rewritten as necessary at runtime once an object's type is determined. If one let the programmer muck with the pointers as well, there would be no guarantees that a method call would be resolvable (or sensible) at runtime. But I'm having to guess at this, so I could be wrong. Perhaps folks with a stronger background than I can get more out of this book.
June 30, 2014
Výborná kniha, na kterou mě upozornil Ondřej Sýkora.
Jestliže vás programovací jazyky zajímají víc než jen jako důmyslné "lopaty" pro zápis algoritmů za účelem pravidelného zvýšení zůstatku na účtu, budete z této série rozhovorů s duchovními otci jazyků C++, C#, Java, Python, UML, Eiffel a mnoha dalších nadšeni. Rozhovory mají vysokou úroveň nejen kvůli odborným i lidským kvalitám zpovídaných individualit, ale také proto, že dotazy, které jsou jim pokládány, jsou většinou promyšlené, dostatečně odborné a neuráží inteligenci odpovídajících osob.
Také se pobavíte tím, jak (skoro) každý autor se zápalem obhajuje typické konstrukce svého jazyka, takže třeba při čtení pasáží o jazyce Forth jsem se nemohl ubránit dojmu, že tento jazyk je všudypřítomný a jediný důležitý, protože všechny ostatní jazyky je jen jeho nepovedeným nebo překombinovaným derivátem.:)
Mě nejvíce zaujaly rozhovory s tvůrci jazyka UML, protože se z jejich odpovědí dá často vyčíst, jak jsou sami znechuceni, co se z UML stalo. Z jejich vypiplaného, slušně vychovaného, bezprostředního a i přes nedostatky ve formální specifikaci talentovaného dítěte se stalo korporátní monstrum, které si s sebou vleče zátěž OMG standardu, pověst přihlouplého nástroje pro naivní analytiky (use case stačí každému, woe) a od praxe odtržené systémové designéry, kteří složí bez problémů UML OCUP zkoušku, i když nikdy žádný systém nenavrhli, protože se tyto formální zkoušky zaměřují jen na schopnost nabiflovat se zpaměti specifikaci.
Jestliže vás programovací jazyky zajímají víc než jen jako důmyslné "lopaty" pro zápis algoritmů za účelem pravidelného zvýšení zůstatku na účtu, budete z této série rozhovorů s duchovními otci jazyků C++, C#, Java, Python, UML, Eiffel a mnoha dalších nadšeni. Rozhovory mají vysokou úroveň nejen kvůli odborným i lidským kvalitám zpovídaných individualit, ale také proto, že dotazy, které jsou jim pokládány, jsou většinou promyšlené, dostatečně odborné a neuráží inteligenci odpovídajících osob.
Také se pobavíte tím, jak (skoro) každý autor se zápalem obhajuje typické konstrukce svého jazyka, takže třeba při čtení pasáží o jazyce Forth jsem se nemohl ubránit dojmu, že tento jazyk je všudypřítomný a jediný důležitý, protože všechny ostatní jazyky je jen jeho nepovedeným nebo překombinovaným derivátem.:)
Mě nejvíce zaujaly rozhovory s tvůrci jazyka UML, protože se z jejich odpovědí dá často vyčíst, jak jsou sami znechuceni, co se z UML stalo. Z jejich vypiplaného, slušně vychovaného, bezprostředního a i přes nedostatky ve formální specifikaci talentovaného dítěte se stalo korporátní monstrum, které si s sebou vleče zátěž OMG standardu, pověst přihlouplého nástroje pro naivní analytiky (use case stačí každému, woe) a od praxe odtržené systémové designéry, kteří složí bez problémů UML OCUP zkoušku, i když nikdy žádný systém nenavrhli, protože se tyto formální zkoušky zaměřují jen na schopnost nabiflovat se zpaměti specifikaci.
Read
August 15, 2015Programming is a fickle profession. It's one that encompasses pragmatism and elegance, fashion and science. Much of the entire body of knowledge involves things somebody has already figured out and the rest of us have forgotten. It's a young discipline, and a confused one. We fight turf wars over all the wrong things. Is OO the best? Is functional programming the best? What IS true OO? What IS true functional? What language should I use for everything? What is the killer app of this language? Why should I learn something new? Why should I avoid the novel in favor of something old and stable? We all build our philosophies about how to approach programming out of these questions and anxieties, but mostly we choose our sides arbitrarily for one simple reason:
We don't know what's good. We quantify very little. We call ourselves a science but we (largely) don't perform experiments on our tools and languages. We call ourselves engineering but we don't work with materials that have consistent properties. We call ourselves mathematics but our theorems are partial and fragile and often broken and incomplete. We call ourselves artists but we don't know our audience.
The most interesting thing about programming language designers is that they don't seem to get embroiled in these turf wars. They have philosophies, but they're built of smaller parts. How do you feel about late binding? How general should a language be? What makes a language maintainable? When should you say yes to your users? When should you say no? Should you enable your users to do as much as possible? Should you rein them in? Should your language be like something that already exists? Should it be completely different?
Each language seems to be a collection of 3 or 4 core ideas. Most languages seem to be successful by accident. Many of the best ideas are not the ones you're writing blog posts about, because stacks aren't so hot right now, contracts aren't so hot right now, regular expression pattern matching isn't so hot right now, generics aren't so hot right now. Almost nobody interviewed in this book seems to embrace the same values as are embraced by their communities. Larry Wall can sell me on perl. Guido Van Rossum can make me more skeptical of python. Lua sounds beautiful.
The way language designers think of languages is so different than how programmers think of them. In a way, when we're programming, we're constantly doing language design. In this way we have much to learn from them.
We don't know what's good. We quantify very little. We call ourselves a science but we (largely) don't perform experiments on our tools and languages. We call ourselves engineering but we don't work with materials that have consistent properties. We call ourselves mathematics but our theorems are partial and fragile and often broken and incomplete. We call ourselves artists but we don't know our audience.
The most interesting thing about programming language designers is that they don't seem to get embroiled in these turf wars. They have philosophies, but they're built of smaller parts. How do you feel about late binding? How general should a language be? What makes a language maintainable? When should you say yes to your users? When should you say no? Should you enable your users to do as much as possible? Should you rein them in? Should your language be like something that already exists? Should it be completely different?
Each language seems to be a collection of 3 or 4 core ideas. Most languages seem to be successful by accident. Many of the best ideas are not the ones you're writing blog posts about, because stacks aren't so hot right now, contracts aren't so hot right now, regular expression pattern matching isn't so hot right now, generics aren't so hot right now. Almost nobody interviewed in this book seems to embrace the same values as are embraced by their communities. Larry Wall can sell me on perl. Guido Van Rossum can make me more skeptical of python. Lua sounds beautiful.
The way language designers think of languages is so different than how programmers think of them. In a way, when we're programming, we're constantly doing language design. In this way we have much to learn from them.
September 10, 2017
Not one star because of the APL interview which is really enjoyable and because of one interesting aspect: the predictions of the language designers. The book is almost ten years old now so it's interesting to see language designers saying "X is the future of programming" (Hint: they're mostly wrong)
Here are the notes I took while reading it:
The first interviews (c++, python) are really bad. The questions aren't interesting, the answers are sexist (programmers are always "he" in this book, and the authors could use the singular they, c'mon it's time to grow up a little.). Some answers are *really* ugly: "he is/is not a real programmer". This culture must die and seeing a book fostering it is pretty upsetting.
I did like the AWK interview a bit. There are interesting cues about learning and how to use teaching for your own learning.
Not sure I can recommend a 2-star book, but I guess one may be curious about one language or the other. Surely, I'm not reading it again.
Here are the notes I took while reading it:
The first interviews (c++, python) are really bad. The questions aren't interesting, the answers are sexist (programmers are always "he" in this book, and the authors could use the singular they, c'mon it's time to grow up a little.). Some answers are *really* ugly: "he is/is not a real programmer". This culture must die and seeing a book fostering it is pretty upsetting.
I did like the AWK interview a bit. There are interesting cues about learning and how to use teaching for your own learning.
Not sure I can recommend a 2-star book, but I guess one may be curious about one language or the other. Surely, I'm not reading it again.
December 23, 2020
Chapter on Eiffel and Forth was decidedly best reads. Some of the language designers may have gone a bit too philosophical and off-ground as to my liking.
December 15, 2012
In everyday life people usually discuss a programming language looking at their practical usefulness, either for certain tasks or for the applicability to a wide range of problems and fields. It is absolutely natural for engineers and business people to focus on this aspect of economy. However, there's a second stream (not a creek!) that speaks about the beauty of a language or program code, about elegance, coherence, etc. To a person who comes from the humanities' end of the academic spectrum, this is naturally a very appealing aspect.
In this book inventors of programming languages discuss their views, justify their language design decisions and sometimes put them into a wider context. Some of the major/mainstream languages of today are here: C++, Objective-C, C#, Java, Python. Yet the most interesting interviews in the book are the ones that come from the margins or that have some peculiar design decisions. I especially liked the remarks of the fathers (why are there actually no mothers at all here?) of Basic, APL, Forth and Eiffel. And it is great to see that there is a great philosophical mind behind Perl, a language that is often considered to be messy, difficult to read and maintain. I wasn't particularly aware of it, but now I see that the wonderful thing about Perl is that it is very much modelled after natural languages than any other programming language. The approach in designing Perl has been linguistic, not mathematical, as is usually the case. And therefore Perl is not messy at all: It is very thoughtfully and coherently designed.
Speaking about mathematics: That's maybe a little detriment of those language designers, that they over-estimate the need to know mathematics very well. Their point is understandable: To design a computer language and to write a compiler requires strong mathematical knowledge and skills. But the "ordinary" or even casual/occasional programmer out in the wild can often get quite far without much more than simple arthimetics and some Boolean logic.
In the end my reading of this book comes down to this: If I'm going to learn another programming language, I will very likely pick one that is not "useful" in the aforementioned economic sense, but one that is designed in an interesting way by an interesting person.
In this book inventors of programming languages discuss their views, justify their language design decisions and sometimes put them into a wider context. Some of the major/mainstream languages of today are here: C++, Objective-C, C#, Java, Python. Yet the most interesting interviews in the book are the ones that come from the margins or that have some peculiar design decisions. I especially liked the remarks of the fathers (why are there actually no mothers at all here?) of Basic, APL, Forth and Eiffel. And it is great to see that there is a great philosophical mind behind Perl, a language that is often considered to be messy, difficult to read and maintain. I wasn't particularly aware of it, but now I see that the wonderful thing about Perl is that it is very much modelled after natural languages than any other programming language. The approach in designing Perl has been linguistic, not mathematical, as is usually the case. And therefore Perl is not messy at all: It is very thoughtfully and coherently designed.
Speaking about mathematics: That's maybe a little detriment of those language designers, that they over-estimate the need to know mathematics very well. Their point is understandable: To design a computer language and to write a compiler requires strong mathematical knowledge and skills. But the "ordinary" or even casual/occasional programmer out in the wild can often get quite far without much more than simple arthimetics and some Boolean logic.
In the end my reading of this book comes down to this: If I'm going to learn another programming language, I will very likely pick one that is not "useful" in the aforementioned economic sense, but one that is designed in an interesting way by an interesting person.
January 1, 2014
Absolutely astonishing book. Not "must read", but very tasteful and refined reading.
By the way this book is great example of sophisticated interviewing.
By the way this book is great example of sophisticated interviewing.
September 13, 2014
a fun but long read
April 29, 2020
This was a lengthy book. The interviewers did a fantastic job with their questions and covered a range of expert programmers and language designers across the spectrum. The important thing I gained from reading this book was my "enthusiasm" again for different programming languages and styles.
Each different language creator had some "opinions" about the state of affairs and went about in a personal way to do something about it, create a language, create a community, solve the problem, and usually building on top of what the person had learned from others. The language creation is both a scientific process (standing upon the shoulders of giants), as well as the unique taste that each language designer brought to the table. I was excited to learn more about AWK, Haskell, Perl, and Eiffel as languages after reading this book.
Each different language creator had some "opinions" about the state of affairs and went about in a personal way to do something about it, create a language, create a community, solve the problem, and usually building on top of what the person had learned from others. The language creation is both a scientific process (standing upon the shoulders of giants), as well as the unique taste that each language designer brought to the table. I was excited to learn more about AWK, Haskell, Perl, and Eiffel as languages after reading this book.
March 15, 2018
10 lat w informatyce to kawał czasu, ale ta książka jest ciągle aktualna. Może teraz są i jakieś nowości, ale czy np. w matematyce zasada dodawania się zmieniła ostatnio? Nie. Autorzy języków programowania są już dość leciwi i nie wiadomo czy autor by zdążył z nimi wywiady zrobić, przynajmniej ze wszystkimi, więc dobrze że książka powstała. Perl, Python są przecież z lat 80-tych i 90-tych!! Zaś C, Basic, AWK są jeszcze starsze. Ten egzemplarz to gratka dla programistów i historyków programowania (Chociaż nie wiem czy jest ktoś taki). Długo się czyta, ale warto!
August 15, 2018
What a fascinating way to look under the hood of one of the most tricky and powerful design processes! A great blend of qualitative insights into entertaining personalities, and real bare-metal technical considerations. Some chapters go more slowly than others, but the good ones a *great* and in no short supply. One of my most frequently-recommended books.
January 19, 2019
While programming language focus, it have a lot of wisdom on building a system for people. Highly recommended
April 18, 2020
Really good book for any level of programmer. Stories brought out in interviews with language founders in particular offer a good feel for recent history of the subject!
March 9, 2013
I was very excited about the prospect of this book, but in the end, it wasn't terribly satisfying — I gained no particular insights about language design, except that everyone, even the designers of utterly baroque languages, likes to quote Einstein ("... as simple as possible, and no simpler."). This book is worth skimming, but certainly not worth owning.
The interviewer is, generally, knowledgeable and passionate, but the interviews are poorly edited, giving the sense that many of the interviews were chopped up from emails without much review, or in other cases transcribed without much care (there are some awful gaffes that can only be the fault of transcription without careful editing... "a fete complete"!).
The authors clearly took the advice of their final interviewee, Bertrand Meyer, who says, "... 90% of the people will read 50 pages and then stop, even if the book is very good"; the first couple of interviews are, IMHO, better and more insightful than most of the rest, with the exception of the AWK interview which is fantastic, almost worth the price of admission.
Perhaps the most unintentionally interesting aspect is seeing how disconnected and uninformed the majority of the interviewees seemed; at best, most were myopically aware that other things were happening outside the sphere of their language, and at worst, were completely oblivious not only to the present, but important developments which were contemporaneous with their work.
The most tragic aspect for me is that Ken Iverson had passed before this book had been written (conceived?) — I think as designer not only of APL, but also J, he would have had some very interesting things to say, while Falkoff unfortunately gives the reader the impression that APL is a dead language (one reviewer here seems to even confused it with FORTRAN! Horrors!). Also, Arthur Whitney is alluded to by Tom Love... why not interview Whitney? He's probably one of the most interesting and controversial language designers living.
No one from the Lisp or Smalltalk world is represented. Chuck Moore has to say basically the same things he's said in every interview ever, so Forth fans will find nothing new here.
The interviewer frequently allows the subjects to wander off on uninformed rants, while missing great opportunities to give insight about language design stories that haven't been told yet (for example: Charles Geschke brings up his work on BLISS — and the interviewer does nothing with it!). This, along with the title of the book, gives the impression that there was no clear focus as to the intended audience of the book.
I only protest so much because this is a book, and a concept, with so much potential, that is squandered here.
The interviewer is, generally, knowledgeable and passionate, but the interviews are poorly edited, giving the sense that many of the interviews were chopped up from emails without much review, or in other cases transcribed without much care (there are some awful gaffes that can only be the fault of transcription without careful editing... "a fete complete"!).
The authors clearly took the advice of their final interviewee, Bertrand Meyer, who says, "... 90% of the people will read 50 pages and then stop, even if the book is very good"; the first couple of interviews are, IMHO, better and more insightful than most of the rest, with the exception of the AWK interview which is fantastic, almost worth the price of admission.
Perhaps the most unintentionally interesting aspect is seeing how disconnected and uninformed the majority of the interviewees seemed; at best, most were myopically aware that other things were happening outside the sphere of their language, and at worst, were completely oblivious not only to the present, but important developments which were contemporaneous with their work.
The most tragic aspect for me is that Ken Iverson had passed before this book had been written (conceived?) — I think as designer not only of APL, but also J, he would have had some very interesting things to say, while Falkoff unfortunately gives the reader the impression that APL is a dead language (one reviewer here seems to even confused it with FORTRAN! Horrors!). Also, Arthur Whitney is alluded to by Tom Love... why not interview Whitney? He's probably one of the most interesting and controversial language designers living.
No one from the Lisp or Smalltalk world is represented. Chuck Moore has to say basically the same things he's said in every interview ever, so Forth fans will find nothing new here.
The interviewer frequently allows the subjects to wander off on uninformed rants, while missing great opportunities to give insight about language design stories that haven't been told yet (for example: Charles Geschke brings up his work on BLISS — and the interviewer does nothing with it!). This, along with the title of the book, gives the impression that there was no clear focus as to the intended audience of the book.
I only protest so much because this is a book, and a concept, with so much potential, that is squandered here.
December 29, 2010
Over 400 pages of interviews with a bunch of programming language designers, who come out all too human. Bjarne Stroustrup thinks that C++ is superior to Java because in C++ you can write a multiplication operator to multiply a matrix and a vector, and in Java you have to arbitrarily assign it to the matrix class or to the vector class. James Gosling thinks that C#'s unsafe pointers are "grotesquely stupid". Anders Hejlsberg is "puzzled" about why Sun doesn't evolve the Java virtual machine. Chuck Moore thinks that operating systems are redundant, and computers should run Forth interpreters on bare hardware. Don Chamberlin says that SQL injection attacks is something the designers of SQL "never dreamed of." Bertrand Meyer "could not believe [his] eyes" when the first version of C# came out without generics, and says that .NET 4.0's code contracts are "only like 23 years after Eiffel." This is the first time I saw Meyer's and Claude Baudoin's Méthodes de programmation mentioned in print; this was my first programming book. Meyer thinks he can say without exaggeration that it served to train a couple of generations of French software engineers - also Russian software engineers.
August 30, 2014
At first, I planned to read this book because someone recommend me to do it, and I didn't have any interests of any other languages but java and SQL. So I decided to only read about them.
The book is an interview between the writer and each creator of the languages, just question-answer conversation.
In SQL, it talks about the story behind the invention of this language and the challenges and the methods they used and he mentioned some of the useful tips that might helped if you are claiming to create your own language. And in the end he talked about his new language XQuery and it features.
In Java, unlike SQL, he didn't talked about the history of it. He just talked about different aspects needed in the language like simplicity and power and then he talked about AWT, swing, JVM, and debugging. In one part he talks about threading issues and API design and language design in another. Finally he mentioned that the most important thing in designing a language is not designing a language, but figuring out what the language is for.
The book is an interview between the writer and each creator of the languages, just question-answer conversation.
In SQL, it talks about the story behind the invention of this language and the challenges and the methods they used and he mentioned some of the useful tips that might helped if you are claiming to create your own language. And in the end he talked about his new language XQuery and it features.
In Java, unlike SQL, he didn't talked about the history of it. He just talked about different aspects needed in the language like simplicity and power and then he talked about AWT, swing, JVM, and debugging. In one part he talks about threading issues and API design and language design in another. Finally he mentioned that the most important thing in designing a language is not designing a language, but figuring out what the language is for.
April 14, 2015
[3.5 stars]
Pretty interesting look into the thought processes of the people who invented various different programming languages. Mostly for how closely intertwined the objective aspects of the language were with the various tastes and prejudices of their authors (though of course they probably wouldn't see it that way). Chuck Moore of Forth thinks you've been swindled into buying a machine with an operating system (who needs that?), Larry Wall of Perl fame views himself as the linguist out to save programming from the tyranny of mathematics, Bjarne Stroustrup of C++ looks at the sprawling chimera of object-oriented and straight procedural constructs that he created and says "Mistakes were made. But at least we're better technologically and morally than Java." And James Gosling of Java creates an AbstractInterviewManagerFactory to answer all possible questions. heh.
All in all, it's pretty interesting, but you'll burn yourself out if you try to read straight through. If you pick this up, have it as something you occasionally pick up and read.
Pretty interesting look into the thought processes of the people who invented various different programming languages. Mostly for how closely intertwined the objective aspects of the language were with the various tastes and prejudices of their authors (though of course they probably wouldn't see it that way). Chuck Moore of Forth thinks you've been swindled into buying a machine with an operating system (who needs that?), Larry Wall of Perl fame views himself as the linguist out to save programming from the tyranny of mathematics, Bjarne Stroustrup of C++ looks at the sprawling chimera of object-oriented and straight procedural constructs that he created and says "Mistakes were made. But at least we're better technologically and morally than Java." And James Gosling of Java creates an AbstractInterviewManagerFactory to answer all possible questions. heh.
All in all, it's pretty interesting, but you'll burn yourself out if you try to read straight through. If you pick this up, have it as something you occasionally pick up and read.
February 12, 2012
A book of interviews with the authors of some of the current popular and interesting programming languages. For a book of interviews, the quality and interestingness is directly proportional to the interestingness of the people in the interview. Not surprisingly, some of the interviews are more engaging than others, but the overall quality is surprisingly high.
The book is an interesting view to the minds of the people responsible for the languages. And for some of the people, it was interesting to observe their obsessions which lead them to designing the language exactly the way they did, most remarkably Bjarne Stroustrup's (C++) obsession with generic containers and type checking (which is arguably quite weak in C++).
The choice of languages and people to interview is good and it covers quite a lot of different types of languages. Though, I'd like to see in the book is an interview with someone working on LISP languages (ideally McCarthy himself) and Martin Odersky from Scala.
The book is an interesting view to the minds of the people responsible for the languages. And for some of the people, it was interesting to observe their obsessions which lead them to designing the language exactly the way they did, most remarkably Bjarne Stroustrup's (C++) obsession with generic containers and type checking (which is arguably quite weak in C++).
The choice of languages and people to interview is good and it covers quite a lot of different types of languages. Though, I'd like to see in the book is an interview with someone working on LISP languages (ideally McCarthy himself) and Martin Odersky from Scala.
August 11, 2016
This book provides an interview format where the author (interviewer) asks the same questions (for the most part) to the creators of popular programming languages (C++, Python, FORTRAN, BASIC, Haskell, UML, Postscript, etc). This format allows the reader to compare and contrast the thought processes, perspectives, and beliefs among the various creators. In that vein, it really succeeds, and you'll no doubt notice many more similarities than differences. But when there are differences, they are vast and evident in the resulting language (for example, strict typing versus loose typing, or the design of garbage collectors and extension mechanisms). At times, the book gets very technical, but is very educational in that respect. Recommended for serious students of computing history and programming language theory.
October 1, 2011
I think I have a hangover from my computer science undergraduate days as seeing language developers with a certain amount of awe. One side-effect of reading this set of interviews is that I have a much better picture of the diversity of language designers and it seems much more approachable now.[return][return]A few of the interviews seem rough, as if the interviewer and interviewee weren't quite talking about the same thing. Also, it seemed like for one or two of the group interviews that there were separate interviews that were combined. [return][return]There isn't as much computer science history in here as I had expected. More discussion revolved around current programming practices and future challenges. Not a bad thing, but it is a little suprising.
March 3, 2015
Очень неровная книга. Каждая глава имеет свой стиль. Обычно после первых пяти-шести страниц становится понятно, стоит ли дочитывать главу до конца - кто-то из мастермайндов жутко зануден и все вопросы сводит к одной и той же теме, кто-то говорит сплошными абстракциями, так что после десятка страниц ни черта не понимаешь, о чем вообще речь, а кто-то вообще несет адский маркетинг-буллшит, как будто презентацию своего языка докладывает. Однако посреди этого есть несколько довольно интересных бесед. Для себя я выделил Haskell, Python, Fort, Perl.
А еще в книге сильно не хватает примеров кода. После некоторых глав я находил туториалы по этим языкам и только после их прочтения становились понятны вещи, о которых говорил автор.
А еще в книге сильно не хватает примеров кода. После некоторых глав я находил туториалы по этим языкам и только после их прочтения становились понятны вещи, о которых говорил автор.
January 29, 2024
Fantastic book for those who want to know more about implementing/designing and maintaining a programming language.
The book does a great job at interviewing authors that come from very different backgrounds and motivations. It does neither only includes popular languages in industry nor it's focused on academic languages. It does a very good job overall in terms of diversity.
It's also not a very dry and technical book, so I think even if you know nothing about programming language design/implementation you should be able to understand the discussions easily. But some background probably will make things more enjoyable.
I found this book highly entertaining and including quite a lot of practical wisdom.
The book does a great job at interviewing authors that come from very different backgrounds and motivations. It does neither only includes popular languages in industry nor it's focused on academic languages. It does a very good job overall in terms of diversity.
It's also not a very dry and technical book, so I think even if you know nothing about programming language design/implementation you should be able to understand the discussions easily. But some background probably will make things more enjoyable.
I found this book highly entertaining and including quite a lot of practical wisdom.
January 12, 2016
I read only the first three or four interviews. It was kind of interesting to read about the programming languages I use or I had used in the past but the majority was totally boring for me.
If you want to dig a little bit into several programming languages I recommend "Seven languages in seven weeks. I think an interview part would fit to this book much better but a book of pure interviews was just boring over time.
An audio version of the book with the voice of the real visionaries might be better.
If you want to dig a little bit into several programming languages I recommend "Seven languages in seven weeks. I think an interview part would fit to this book much better but a book of pure interviews was just boring over time.
An audio version of the book with the voice of the real visionaries might be better.
August 20, 2014
This book was unreadable. I quite liked Design and Evolution of C++ by Stroustrup. And I've liked the various other interview/survey the greats of software - but not this one. The questions were dumb, the answers uninteresting. There weren't enough details. Perhaps it gets better later - but 100 pages in - C++, Python, APL, Forth, BASIC - I think I've got enough of a feel for it. Though Forth still looks cool. 1 of 5.
August 9, 2011
Not a bad set of interviews with language creators. As you might expect with a collection of this sort, some interviews were better than others. And YMMV, depending on your tastes and familiarity with the various languages. Nearly no code was included, so it's accessible to any programmer type, even if they don't know all of the languages (although I found that my attention wandered for most of the interviews with creators whose languages I didn't know).
July 4, 2012
To be honest, I didn't read the whole book but just the UML chapter. It contains very inspirative interviews with three authors of UML not always about UML. I write down all interesting thoughts or mentions and make some comments on them (http://blok.ocup.cz/2012/07/co-si-aut..., sorry, in Czech only).
I am about to read about SQL and C# in the future. Am missing the chapter dedicated to Pascal which I used to use for 13 years before I dropped out of programming.
I am about to read about SQL and C# in the future. Am missing the chapter dedicated to Pascal which I used to use for 13 years before I dropped out of programming.
December 31, 2011
More enjoyable than I expected. That may sound like faint praise, but after having this book sitting on my shelf for a couple of years I simply decided I wasn't interested in the history and motivations of language designers. But I started flicking though, and conversations about language adoption, attitudes to change and marketing issues were illuminating.
August 10, 2011
This is a wonderful book - I wish there were more like it. The author does a brilliant job of going pretty deep with each of the subjects. This is reflected in how clearly the personality of each "mastermind" shines through - in some cases revealing almost hurtful arrogance, in others a deep respect for the work of others. I found it to be a very entertaining and educational read.
November 23, 2011
Interesting interviews, and a few nuggets of insight from language designers who've shaped the modern software industry, even if their language(s) are not mainstream/in wide use.
Worth a read, but don't expect to be held spellbound throughout, as it's pretty dry in places.
Would have been better with more story & background.
Worth a read, but don't expect to be held spellbound throughout, as it's pretty dry in places.
Would have been better with more story & background.
Displaying 1 - 30 of 39 reviews