Dr. Dobb's Journal September 2006
This is a wonderful time to be a software engineer.
Every new frontier is the exhilarating domain of inventors and explorers. Life on the frontier can be primitive and even dangerous, but in return pioneers have an overwhelming compensation: There's so much room, so much uncharted territory, and everything is just waiting to be discovered and invented.
The 1950s and 1960s were like that. Computer science was new, and you know the pioneers—names like Edsger Dijkstra and Sir Tony Hoare. But have you ever felt that all the cool stuff was already done back in the '50s and '60s, back when electronic computers were new? Consider that all of the major "new" technologies of the past 15 years were originally invented in those early days: Garbage collection? Java didn't invent it; McCarthy invented it for Lisp in 1958, and published his paper in 1960. Object-oriented programming? Smalltalk and C++ didn't invent it; Simula did, vintage 1965, and released in 1967. Parameterized generic types? Ada and C++ didn't invent those; Strachey did, also in 1967. Incidentally, 1967 was a banner year; it also saw the first design meetings for the ARPANET.
But bringing those technologies to mainstream programmers required developing them further, including doing new R&D to make the technologies more broadly usable (think Mosaic), and making them into widely usable polished products. Languages like Smalltalk, C++, Java, C#, Python, and many others, and all the smart people who developed them and worked on their many implementations, deserve huge credit for making that big engineering leap.
So, yes, it surely is humbling to realize that all the hot stuff that seems so new today actually existed back when our parents still had to carry their stacks of punched cards to school in snow up to their armpits and uphill both ways. But Java did bring garbage collection to the mainstream, Smalltalk and C++ did the same for objects—and next we're going to do the same for concurrency and parallel programming.
Just think: For the first time in the history of computing, mainstream computers will no longer be von Neumann machines—they will be parallel. Given that our applications are going to run on parallel machines, this is a time of enormous opportunity, along with a great deal of work. Sure, concurrency has been done before; parallel computing was researched by some of the very people already mentioned (see Hoare's seminal paper on "Communicating Sequential Processes"), and companies like Cray have been doing it for years. But the mainstream programmer and mainstream environments have most certainly not been doing it routinely, and we have only now just begun the process of bringing concurrency and parallel programming to the mainstream.
In 2004, I wrote that "the biggest sea change in software development since the OO revolution is knocking at the door, and its name is Concurrency" (http://www.ddj.com/184405990). The concurrency revolution now getting underway will be as significant as the object revolution of the late 1980s and 1990s in its impact on programming languages and development tools. Just as during the early 1990s we attended conference sessions with breathless topics like "what is an object" and "what is a virtual function," in coming years we'll attend conference sessions with breathless topics like "what is an active object" and "what is a future."
Sometimes it might seem that all the cool stuff was invented in the 1950s and 1960s, and that the pioneers had all the fun when everything was new and waiting to be discovered. The truth is that our industry is still in its infancy. We can admire the contributions of the Galileos and the Newtons, but they themselves stood on the shoulders of earlier giants just as we will stand on theirs.
Yes, this is a wonderful time to be a software engineer. For the rest of this decade and into part of the next, we're going to do for concurrency what we did for objects and garbage collection: Stand on the results of past giants, develop their ideas still further, and bring the concepts into the mainstream. It'll require using the best techniques of the past, developing new ones, and a pile of work to turn it all into broadly usable products. But, unlike the object revolution, we can see the concurrency revolution coming.
Pedal to the metal, everyone. The world awaits.
DDJ