
Masterminds of Programming: Conversations with the Creators of Major Programming Languages - 10ren
http://oreilly.com/catalog/9780596515171/toc.html
======
kmavm
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.

------
harpastum
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._

~~~
10ren
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?

~~~
harpastum
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]).

[1]<http://developer.apple.com/cocoa/>

[2]<http://www.amazon.com/gp/product/0321503619>

~~~
10ren
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).

~~~
dschobel
more so in objective-c which is really a simple language.

the framework is everything.

------
comatose_kid
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?

~~~
swannodette
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.

------
adamc
No Smalltalk or Lisp? Seems like an odd list.

~~~
10ren
And no Scheme (Guy Steel is perhaps the broadest language designer there is).

It's perhaps to do with who had time/was willing to have a conversation.

~~~
chromatic
I've worked on many interview projects before; it's always about who has time
and interest to have a conversation.

------
screwperman
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.

------
dkarl
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.

------
MoeDrippins
UML?

~~~
bigmac
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."

~~~
nickb
Grady's a smart guy but UML has been an utter failure.

Here's a good summary as to why:
[http://littletutorials.com/2008/05/15/13-reasons-for-umls-
de...](http://littletutorials.com/2008/05/15/13-reasons-for-umls-descent-into-
darkness/)

~~~
okmnjiuh
Theres often more interesting stuff to be said about why something failed than
about a language that is mainstream designed by committee and compromise.

------
uggedal
Good luck getting the reader to complete the book when you start with C++.

~~~
scott_s
You don't have to like a language to learn from what its designer has to say
about it.

Although I would be surprised if Stroustrup says anything that wasn't said in
D&E (<http://www.research.att.com/~bs/dne.html>) and his recent HOPL III paper
(<http://research.ihost.com/hopl/HOPL-III.html>)

