Recommended read: Masterminds of Programming

I’ve recently been reading the book Masterminds of Programming, published by O’Reilly.  This book contains interviews with the creators of seventeen historic and highly influential programming languages, including C++, Java, Haskell, Objective-C, Python, and many more.

I’m about halfway through the book and can highly recommend it.  Here are a few good quotations that I have highlighted. (Interviewer questions are in bold.)

Bjarne Stroustrup, creator of C++:

How can we be sure that the advantages of OO are more valuable than the disadvantages? Maybe the problem that a good OO design is difficult to achieve is the root of all other problems.

Bjarne: <…> There is no one “root of all evil” in software development. Design is hard in many ways. People tend to underestimate the intellectual and practical difficulties involved in building a significant system involving software. It is not and will not be reduced to a simple mechanical “assembly line” process. Creativity, engineering principles, and evolutionary change are needed to create a satisfactory large system.

Guido van Rossum, creator of Python:

Is there any characteristic that becomes fundamental to evaluate if we are looking for great Python programmers?

Guido: I’m afraid you are asking this from the perspective of the typical manager who simply wants to hire a bunch of Python programmers. I really don’t think there’s a simple answer, and in fact I think it’s probably the wrong question. You don’t want to hire Python programmers. You want to hire smart, creative, self-motivated people.

James Gosling, creator of Java:

If it weren’t for Java, would Scala be your language of choice?

James: Yeah, probably.

Tom Love, co-creator of Objective-C, on hiring good programmers:

How do you hire a good programmer?

Tom: There’s a big topic. You might or might not know that my dissertation was a study on the psychological characteristics of successful programmers in the 1970s… There are actually some that are still alive. It’s quite amazing. There are certain cognitive psychological traits that you look for: memory ability, attention to detail. I also look for things like communication skills, both written and oral. Working in a team; it’s important that you be able to communicate effectively with the rest of the team and then it’s also important if you obtain leadership roles that you be able to communicate with customers or subject matter experts or other operations and maintenance teams that you need to interact with as you start to deploy products. I don’t make it a requirement, but I look for correlations like really excellent programmers, if I’m trying to hire somebody to be a chief designer and architect for a project. I’ll pay attention to their hobbies. If they’re very proficient in music, that’s a very good thing–proficient means has studied classical music and can perform a piano sonata from memory. That’s a pretty good test of their memory ability and attention to detail, and it should sound pretty good, too!

On a side note, I still require sheet music to perform a violin sonata, but I’m getting better.

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.

Finally, there’s this exchange on the relative success of C++ versus Objective-C, which is priceless:

Why do you think that C++ was used more frequently than Objective-C?

Tom: It had the AT&T moniker behind it.

Just that?

Tom: I think so.

What do you think about Objective-C today?

Tom: It still exists. How about that?

Brad Cox, co-creator of Objective C, who may or may not have read my post on the “I, Pencil” essay, but has almost certainly studied some economics:

What do the lessons about the invention, further development, and adoption of your language say to people developing computer systems today and in the foreseeable future?

Brad: <…> I’ve used the common wooden pencil in some of my writing as an example. When I ask audiences which is “simpler”, a digital pencil like Microsoft Word or a wooden pencil, people agree the wooden variety is simpler. Until I point out that Microsoft Word was written by eight programmers, while the wooden variety involved thousands, none of whom could appreciate the full complexity of harvesting lumber, mining graphite, smelting metals, making lacquer, growing rapeseed for oil, etc. The complexity was there in the pencil, but hidden from the user.

In this passage, you hear echoes of Matt Ridley’s The Rational Optimist, and other economic texts such as The Wealth of Nations:

You’ve probably heard about the problems that the state of California recently had with their systems written in COBOL. Could having a system built with little bricks help us avoid the problem of legacy software in the future?

Brad: I believe very strongly in components, but I don’t want to oversell the idea—components don’t solve everything. Components are how people solve problems above a modest scale; it’s one thing that separates us from chimpanzees. We invented a way of solving problems by simply making it the other guy’s problem. It’s called specialization of labor, and it’s as simple as that. That’s how the humans differ from chimpanzees: they never invented that. They know how to make tools, they have a language, so for most of the obvious things there are no differences between chimps and humans. We discover how to solve problems by making it the other guy’s problem—through an economic system.

And finally, these insights comparing software ecosystems with the natural world:

Does your university background [in organic chemistry, mathematics and biology] influence your vision of software design?

Brad: Absolutely. Constantly.

If you examine ecological systems, you see software as an ecological system in all respects except that the system lacks anything like physical conservation laws—no conservation of mass or energy. The product of our labor is made of bits that can be copied so easily that it’s hard to buy, sell, and own them. The economic system, the ecology, breaks down.

If a leopard could replicate its food as we replicate software, there would be no improvement by either the leopard or its prey.

It’s a constant problem in software, how to own and be compensated for the products and for your efforts.