Urban sent me a link to Brian Hayes’s American Scientist article “The Post-OOP Paradigm”. Hayes writes:

Every generation has to reinvent the practice of computer programming. In the 1950s the key innovations were programming languages such as Fortran and Lisp. The 1960s and ‘70s saw a crusade to root out “spaghetti code” and replace it with “structured programming.” Since the 1980s software development has been dominated by a methodology known as object-oriented programming, or OOP. Now there are signs that OOP may be running out of oomph, and discontented programmers are once again casting out for the next big idea. It’s time to look at what might await us in the post-OOP era […].

To talk about the post-OOP era, Hayes has to summarize the history of computer programming, which he does brilliantly. In doing this, he addresses something I’ve been thinking about the last few days – namely, what non-programmers think programming is. A common question from users is whether some desired feature would be “difficult” to create. Mostly, it’s not a question of difficulty at all, but of how long it would take. Some features are indeed difficult to find good solutions to, but I don’t think that’s what they refer to – I think they mean the process of writing the instructions for what the computer should do.

I thought about saying something about the vast number of instructions that a computer program contains, and how you must organize them into – using technical writing as analogy – parts, chapters, paragraphs, and sentences. Sometimes it takes longer to figure out how a feature fits in with the existing parts, chapters, etc. Brian Hayes describes how “The very first programs were written in pure binary notation,” and how, later, this task was made easier with the invention of assembly language, “in which raw binary codes were replaced by symbols such as load, store, add, sub.”. He continues:

Assembly language was a crucial early advance, but still the programmer had to keep in mind all the minutiae in the instruction set of a specific computer. Evaluating a short mathematical expression such as x² + y² might require dozens of assembly-language instructions. Higher-level languages freed the programmer to think in terms of variables and equations rather than registers and addresses.

Now, this might not be something that can be presented to a non-programmer, but explaining programming by referring to milestones in the evolution of programming languages seems like an appropriate thing to do.

I strongly recommend programmers to the article. The post-OOP era, according to Hayes, holds things such as aspect-oriented programming, generative programming, and patterns. He also mentions extreme programming. In June, I blogged about a similar article in Software Development Magazine by Grady Booch, titled Through the Looking Glass (registration required), in which he listed patterns, “multiple views in the science and practice of software architecture,” and aspect-oriented programming, as parts of a coming sea change which he (and a few others) calls “multifaceted software”.