Also posted at http://meta.programmers.stackexchange.com/a/2822/226.

Gary Bernhardt took the stage to talk about the evolution of programming languages and technologies. He talked about the fact that languages and technologies evolve in waves: first there’s a wave of expansion where a new language comes along and increases the number of things we can do, and it is followed by a contraction that reduces the number of things we can do but also removes a lot of confusion and therefore enables us to deliver more reliable software with the new toolset.

So, expansion increases capability – our power to express an idea. Over time abundant resources and confusion drive change and we see a contraction that removes 5% of the capability and 85% of the confusion to enhance suitability – the power to deliver reliable software that works.

Many expansions are initially dismissed by the developer community. For example, looking back at Djikstra’s proposal for structured programming, it was met with the following review:

Structured programming is a nice academic exercise, which works well for small examples, but I doubt that any real-world program will ever be written in such a style.

The relational model was met with similar criticism and the same quote can be paraphrased and applied almost universally to new technologies coming out today. Instead of focusing on how something can’t possibly be workable, we should consider what larger purpose it may be serving: either by improving capability or suitability.

Here are some examples from history:

• 1957: Fortran increases capability vs Assembly.
• 1968: Structured programming increases suitability vs Fortran.
• 1970: Relational model comes out as more suitable vs flat files.
• 1985: C++ is more capable vs C by adding object-oriented concepts.
• 1995: Java is more suitable vs C++ by removing some of the complexity and introducing automatic memory management.
• 2004: Rails extends the capability vs existing ways to develop web applications.

Rails displays a culture of capability. The focus is on new gems and new features all the time and when something breaks, it’s easier to just move on to the new working thing than fix the broken one.

Gary made a point that capable systems generate a lot of activity (for example, the gem explosion in Rails), but then a contraction into more suitable tools creates suitable systems where the real progress happens. He described the difference between activity and progress as a developer who commits code lots of times a day but doesn’t necessarily produce a lot of value. That developer is certainly active but may not be making much progress.

So what happens after Rails? Gary suggested that there’s frustration building in the developer community and it’s likely going to lead to a contraction step. Up next are the functional revolution and outside-in top-down London style test-driven development. Which are, of course, impossible since they are nice academic exercises, which work well for small examples, but no real-world program would ever be written in such styles.