Masterminds of Programming: Conversations with the Creators of Major Programming Languages

http://oreilly.com/catalog/9780596515171/toc.html

by 10ren • 17 years ago

43 28 17 years ago

oreilly.com

adamc• 17 years ago

No Smalltalk or Lisp? Seems like an odd list.

omnipath• 17 years ago

What about Assembly and C?

nickb2• 17 years ago

or Ruby. Some of the smartest hackers now use Ruby.

10ren3• 17 years ago

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• 17 years ago

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

stcredzero• 17 years ago

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

(Note, this comes from a long time Smalltalker.)

IsaacSchlueter• 17 years ago

Agreed. Of course, talking to the creator of Lisp would be tricky.

I wonder why Javascript was not included. It is the native language of the largest and most relevant software platform in the world.

berntb2• 17 years ago

>> Of course, talking to the creator of Lisp would be tricky.

Huh, McCarthy lives according to Wikipedia. Doesn't he give interviews?

MoeDrippins• 17 years ago

UML?

bigmac• 17 years ago

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

nickb2• 17 years ago

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

rmc00• 17 years ago

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.

uggedal• 17 years ago

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

scott_s• 17 years ago

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)

harpastum2• 17 years ago

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.

10ren3• 17 years ago

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?

harpastum2• 17 years ago

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

dkarl• 17 years ago

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.

comatose_kid• 17 years ago

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• 17 years ago

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.

screwperman• 17 years ago

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.

kmavm• 17 years ago

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.

Masterminds of Programming: Conversations with the Creators of Major Programming Languages

Related Stories