The software industry is the most fashion-conscious industry I know of.

– Ivar Jacobson

If you take some of the programs that exist today, they are more complex that just about any artefact that humankind has build before.

– Bertand Meyer

The best path to high-quality software is talented experts who share a pretty clear sense of what they want to produce. I have no idea how to produce good software without talented programmers.

– Peter Weinberger

Masterminds of Programming is a fascinating book, where the authors get many of our industry’s most highly regarded veterans to speak out about basically anything software related. The hook is that they’re being interviewed about the programming language they created.

Here are some of the best quotes and most interesting historical anecdotes.

Common themes

Across all the interviews, several things keep coming up.

• They don’t use debuggers. Instead they stop and think, inspect the mental model of the application in their head, and then add a few print statements to adjust that mental model.

• Simplicity is an overarching goal. Ivar Jacobson: “Simplicity is the idea behind being smart.” James Rumbaugh: simplicity “requires a willingness to do too little rather than doing too much.” Only add features to the language if they are useful to multiple groups of users, and solve multiple problems. Keep APIs as simple as possible.

• Concurrency is a problem we need to solve, and it will probably need language support. Functional languages may be part of the answer, as will frameworks.

• Software engineering education is lacking, but there was no consensus on how to make it better.

• Productivity differences between programmers vastly overshadow differences in programming languages.

• You have to maintain backwards compatibility, even though it’s a pain. Anders Hejlsberg: “I’ve never been able to justify breakage.”

Bjarne Stroustrup (C++)

This was one of the most interesting chapters. It made me want to learn modern C++ (which is nothing short of a miracle), probably using his latest book, Programming: Principles and Practice Using C++.

He portrays C++ as having everything, from low-level direct memory access (“some language has to do it”), to “higher-level abstractions such as iostreams, containers and algorithms”. It it multi-paradigm, supporting both Object-Oriented programming, and Generic Programming, the goal being “direct expression of ideas, resulting in code that can be efficient in time and space”.

There has to be a place behind a barrier where code can be written simply, elegantly and efficiently without worrying about random pieces of code abusing random pieces of other code.

C and C++ have provided stability over decades. There is a price to pay for such stability, but languages that don’t provide it are simply unsuitable for large, long-lived projects.

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.

Alfred Aho, Peter Weinberger, and Brian Kernighan (AWK)

Lots of interesting stuff in here. AWK was designed for people to use by copy-pasting other people’s programs and tweaking them. It was designed for 1-line programs (but Peter Weinberger tells a story of a Bell Labs colleague who “had written an assembler for some esoteric piece of hardware in AWK and it was 55 pages of code”). They see Perl as a natural successor to AWK. Unix command line is a prototypical functional language.

Peter Weinberger:

It’s useful to tease out what the “Unix concept” really was. It was a style in which many programs were useful with one input and one output, together with command-line syntax, and system support that made all input and output uniform (read and write system calls, no matter what the device) and system support (pipes) that avoided having to name and allocate temporary files.

Most comparative questions about languages, coding techniques, development methodologies, and software engineering in general, are appallingly unscientific. Software is still a craft, rather like furniture making. [..] so much of it is anecdotal and based on people’s judgements or even people’s aesthetic judgements.

There are two kinds of software projects: those that fail, and those that turn into legacy horrors.

Given a group of people and some project, it really doesn’t matter what the language is, but for individual programmers I suspect it does matter. I think people, for personality, or what they learn first, or whatever, find some kinds of languages easier to adapt to than others. This is where you get these funny debates.

James Gosling (Java)

Java is about strong fault-isolation mechanisms: “the way that memory pointers work and garbage collections work and exceptions work are really about fault isolation.”

He likes Scala a lot.

On the value of a virtual-machine and Just In Time compiler:

You get two advantages when the compiler is running right at the last moment:

• One is you know exactly what chipset you’re running on. [..] It knows exactly how the cache works. It knows exactly how the memory hierarchy works. It knows what instruction set extensions this chip has got.
• Then the other half of it is that it actually sees the application as it’s running. It’s able to have statistics that know which things are important. It’s able to inline things that a C compiler could never do.

Tom Love and Brad Cox (Objective-C)

Tom Love:

100,000 lines of code is a box of printout. It cost $3 million to develop. It takes two people to maintain it. The number of test cases to fully test that box of code is another two or three boxes of code.

You do a really good job of architecture and design of some new system, and then you turn it over to the organization that paid you to do the work, it’s astonishing how fast that orderliness gets lost in the application. People that don’t know what they’re doing go in and start whacking, and they can do a lot of damage in a short period of time.

Brad Cox:

Objective-C started out as C with Smalltalk (by contrast, C++ started as C with Simula). If he started again today, he might not have inheritance at all: Inheritance just isn’t all that important. Encapsulation is OOP’s lasting contribution.”

He is interested in the economics of software components, as it might enable re-usable components. There’s no economical way to “sell” a component, you can’t do DRM on a class. He’s enthusiastic about SOA, because now you can own and rent the components, the economics line up, so we might finally see the dream of re-usable software components (as re-usable services).

Don Chamberlin (SQL)

SQL started life in 1974 as SEQUEL, a query language for IBM’s System R, which was an industrial-strength prototype of Ted Codd‘s new relational model of databases.

However the first commercial product based on SQL was released in 1979, not by IBM but by a small company called Relational Software Inc. The product was called Oracle, a name that was later adopted by the company, which is no longer small.

SQL is still very widely used. He puts that down to a few things such as being an ISO standard, SQL manages persistent data, which has a long lifetime, but also the fact that SQL is declarative, not procedural. This gives a much greater opportunity for query optimizers to work, so performance has kept up with data growth, and the language remains relevant.

Anders Hejlsberg (C#)

He is very excited about LINQ, mentions it a lot. Languages have to evolve, otherwise they die. Functional ideas are entering imperative languages. Many languages today, the learning curve is dominated by the ecosystem, not the language itself.

A lot of these new innovative solutions that we see in programming languages are great at the 10% new, but then they are terrible at the 90% that every language must do in order for you to really be able to write programs. It’s very, very important to understand that there’s a bunch of boring standard stuff that has to be in every programming language. If you don’t get that right, you will fail.

Platforms live maybe 10, 15 years and then they cave in under their own weight, one way or the other.

I’ve seen lots of Java programmers defect to Ruby just because they’re dying in frameworks and Struts and Spring and Hibernate and what have you.

Paul Hudak, John Hughes, Philip Wadler and Simon Peyton Jones (Haskell)

This is the other chapter that made me want to learn the language. It sounds like a very different approach. (I’ve done Miranda in the past). This is easily the most academic interview, with talk of publishing papers, theory, and formal proofs.

The main benefit of functional languages is lack of side effects. Functional languages have influenced mainstream languages, through garbage collection, generics (Philip Wadler worked on Java Generics), iterators, and anonymous functions.

Simon Peyton Jones:

It’s not out of the question that some recognizably functional language might eventually make it into mainstream. (But my guess is that even if it does it will be called Java3).

Where OO folks draw UML diagrams, Haskell folks write type definitions. This is much, much better, because it’s precise and machine checkable.

James Rumbaugh, Grady Booch and Ivar Jacobson (UML)

They all agree that UML 2.x is bloated, most users only need a simple subset of it. Ivar Jacobson’s training company teaches a subset called Essential UML.

Ivar Jacobson’s interest is process, how software is made. Software is built by teams, not organizations. He advocates a team in the sense of a soccer team, complete in of itself (functional teams), self-organizing, and led by a coach.

He has seen software process change drastically every second or third year, more frequently than the whims of fashion. The old process is thrown out entirely, good with the bad, so there is no incremental improvement. Later they realize the new process had some bad too, so it is again replaced entirely. The result of this is a lot of wasted effort as old truths are rediscovered but cloaked in apparent new clothing..

To fix this Ivar Jacobson and Bertand Meyer are working on SEMAT, aiming to find the kernel of practices that underlie all processes. They goal is to find that core of things which we always have or which we always do when we build software.” and extract it, so processes can be compared and evaluated more rigorously.

Simplicity is the core idea behind being smart.

Process in the past was just a soup of ideas. We make the process a bag of practices. [..] Instead of working on a big methodology or a language, focus on working with on practice at a time.

We really don’t have a theory for software engineering. To most people software engineering is just a soup of ad hoc ideas. This is one of the most important problems to fix.

The “agile” movement has reminded us that people matter first and foremost when developing software. This is not really new – this theme resurfaces every decade or so as naive managers try to mechanize and commodotize what is basically an exercise in creative problem solving.

James Rumbaugh:

The main problem facing the computing field [is that] most of its practitioners have no understanding of computing history, and so they are condemned to repeat the same mistakes. Unlike scientists and engineers who built upon past discoveries, too many computing practitioners treat each system or language as a new thing, unaware that similar things have been done before.

Grady Booch:

Consider that our industry has transformed the world in, essentially, one generation. To me that’s fast, not slow.

Abstraction is largely a problem of classification.

Larry Wall (Perl)

He is interested in linguistics, and that influences Perl more than mathematics. Larry Wall is pretty much unique in this. The other designers often mention that programming languages are like mathematics, never like human languages.

John Warnock and Charles Geschke (PostScript)

They made PostScript a language, rather than a data-format, because they didn’t know what kind of devices it would be used on in the future, and because they knew there would be bugs: a full programming language would allow us to program our way out of things we forgot or did not anticipate”

Interpress, the pre-cursor to PostScript developed at Xerox PARC around 1982, was nearly all done remotely. Remote working isn’t new, and doesn’t need fancy tools:

Except for John and myself, the six of us who worked on that project were never in the same physical location until we completed the project. We did it all by email and using the ARPAnet to transfer information around during the entire design project.

Bertand Meyer (Eiffel)

Designing Eiffel didn’t take any design time: “it was the absolutely obvious thing to do”. Eiffel had generics / templates as early as 1986.

Object-Oriented Programming was part of structured methods right from the beginning. Structured Programming was for programming-in-the-small aspects, and Object-Oriented Programming was for programming-in-the-large, but there was no gap between the two.

C is a reasonably good language for compilers to generate, but the idea that human beings should program in it is completely absurd.

One of the characteristics of software is that any software element you look at is the specification of something that is more concrete and the implementation of something that is more abstract.

Eiffel has pre and post-conditions (contracts). One of the most interesting things this allows is automatic test case generation.

The tool creates objects almost randomly, and then it calls all the routines, all the methods of the corresponding classes, with mostly random arguments. Then we just wait. We call this “Test While You Lunch”. We start the push-button test, and come back from lunch an hour later, and see the postcondition violations. But you can only do this with a language that has contracts built in.

And more

There’s also interviews with Guido Van Rossum (Python), Tom Kurtz (BASIC), the Lua designers, and others. A very interesting book indeed.