Interesting claim that "language designer" == "mastermind." Being great at designing notation for algorithms (which is what languages really are) is conceptually distinct from what most people think of as being a good programmer. It so happens that some language designers have found themselves in that place by virtue of being great programmers (the example that jumps to mind is Dennis Ritchie), but the two coincide less and less often as the field matures, and languages become less of a "systems" problem. At least in academia, the programming language people are perhaps the least likely to ever have to write a line of code in anger.
This gap between coming up with neat notation and the resources need for a world-beating implementation of a language is one of the tragedies of the "dictator-for-life" that has arisen for the "developer productivity" languages (perl, python, ruby...) The language equates in practice with the particular implementation that the designer banged out and maintains. The presence of this reference implementation strangles other implementations in the crib, because users know that libraries, .deb's, new language features, etc., will appear first in the dictator's implementation. Thus, we have datacenters full of nice fast CPUs that spend their lives executing Joe's-favorite-language's switch-on-bytecode VM loop, when they could be running a compiled implementation with more sensible resource usage.
From a brief examination (my university has a subscription to Safari Books--one of my favorite parts of being a college student), this book seems like it lacks direction.
As much as it's useful to read a detailed account of what Chuck Moore was thinking when he created Forth, or chuckle as Tom Love takes pot shots at Bjarne Stroustrup [1], I really don't see a cohesive message across the whole work. Obviously, this won't be a problem for many people, but really, as many of these stories are already all over the web, I'm not sure how much original value this work is providing.
[1]Tom Love (co-creator of Objective-C): There's the successful direction, and then there's the approach that Bjarne took with C++. In one case, it was a small, simple—dare I say, elegant—programming language that was very crisp and well defined. In the other case it was a pretty ugly, complicated, difficult language that had some really troublesome features. I think those are the distinctions between the two.
The issues addressed in the table of contents appeal to me; but I expect you're right, that there would only be cohesiveness within each section, not between them.
BTW: I've heard good things about Objective-C. Any idea why it was not successful outside Apple? Was it because of Apple's proprietary approach?
As far as I can tell (as an amateur mac developer), the major advantage Objective-C has on the mac over other platforms is the extensive support that Cocoa [1], Apple's giant grouping of APIs/Frameworks/etc, lends. It's so helpful, in fact, that many Mac developers refer to programming in Objective-C as "Cocoa Programming" (also, it's the title of the best programming book I've ever read [2]).
Sounds like it's branded/positioned as "Cocoa"... and possibly support is lacking on other platforms (I guess you mean libraries - they're crucial for language success).
From the interview with Tom Love, co-designer of Objective-C:
"Does productivity depend more on the quality of the programmer or the characteristics of the programming language?
Tom: The effect of individual differences will far outweigh any effect of the programming language. Studies from the 1970s show for programmers with the same educational background and same number of years' experience, the number was 26:1 individual differences. I don't think anybody claims that their programming language is 26 times better than somebody else's."
I wonder what others think of this, especially in light of Lisp vs. blub debates?
It's mostly true. But it also means programming languages attract certain kinds of programmers, a language that fits their individual differences. The reason I moved to Lisp is simple. I was tired of syntax. I was tired of the language straight jacket. I'm always surprised that these things never bother other programmers. It surprises me even more that programmers tediously compare the features of their language when any non-trivial program means a large API (that is a language on top of another language). Once you realize that, who really cares about language features? What you want is something malleable. You want something that can program the program. You want (as has been said elsewhere) a language for growing languages. Instead of wasting time learning about each language's arcane meta programming facilities- learn how to write macros, and you can have all the meta programming facilities you'll ever need. But this doesn't seem to interest most programmers, I guess that's part of the individual difference thing.
I suspect that success with creating a language depends a lot on the ego and personality of the creator. The network effects, the community, the culture, the shared wealth of libraries and code all have as big an impact on success as technical excellence of the language itself.
I might be downmodded for this, but I suspect that Python is a success in large part because Guido has big cohones! (Especially when it comes to saying no to people smarter than him.)
You can make a good argument about lambda-notation and Lisp, etc. BUT people talk about creators of types of mathematics. Newton and Leibniz developed calculus, etc. (Maybe sloppy, but a common colloquialism.)
O'Reilly has come up with some decent books recently, including The Productive Programmer and Beautiful Architecture. They don't seems to have got much attention.
Which languages to cover is an interesting question in this day and age. Should a book like this strive for completeness, or should it exclude topics that are well-treated elsewhere? I doubt they got any new stuff out of Bjarne Stroustrop, Guido, or Larry Wall. The images of Java and C# are professionally managed, so talking to their creators seems likely to produce the same old party lines. I'll definitely buy it for the other chapters, though.
I saw Grady Booch give a presentation at SIGSCE one year -- actually a very interesting guy and a dynamic speaker. He said a quote that has stuck with me since: "Hardware eventually fails. Software eventually works."
Theres often more interesting stuff to be said about why something failed than about a language that is mainstream designed by committee and compromise.
I don't think it's fair to say UML itself failed. We did get to a point where to see a project modeled in UML gives you a strong desire to turn and run (and this is usually the correct thing to do), but it's more to do with abuse and stupid users who don't even make the difference between modeling the behavior and modeling the implementation.
Don't get me wrong, UML needs some serious change. However, there is some value in the process and thought that goes into creating the UML diagrams for projects, especially larger, more complex projects. I find that it helps me better visualize what I'm making and spot problem areas before they become real problems.
This gap between coming up with neat notation and the resources need for a world-beating implementation of a language is one of the tragedies of the "dictator-for-life" that has arisen for the "developer productivity" languages (perl, python, ruby...) The language equates in practice with the particular implementation that the designer banged out and maintains. The presence of this reference implementation strangles other implementations in the crib, because users know that libraries, .deb's, new language features, etc., will appear first in the dictator's implementation. Thus, we have datacenters full of nice fast CPUs that spend their lives executing Joe's-favorite-language's switch-on-bytecode VM loop, when they could be running a compiled implementation with more sensible resource usage.