It’s been a strange couple of weeks. No, really.
It all started when a friend of mine, let’s call him "Desi", posted a question asking about what he should do in his last few months of college. A reasonable enough question and I guess I’m as qualified as anyone to give him some advice because it was a question about computer science courses he could take rather than general career guidance. Well maybe I’d be qualified to give advice on that too but anyway… let’s at least try to stay on topic.
So far so good. But here’s the kicker, he was considering taking a course in C++ but was dubious about its value because it was "ANCIENT" [emphasis in original].
But… but… it can’t be ancient. I mean, wasn’t it just last week I was reading some OOPSLA notes on C++ — no wait that was 20 years ago. Could it be true?
But wait it gets better.
Then I went to this other talk where people were talking about the importance of C++ and how many companies [many of which are important MS customers] have great investments in C++; they have highly valueable and important codebases that their company’s future is based on. Microsoft of course has huge investments in C++ that we expect to endure for some time.
Wow ok so all that is true but I had this feeling of déjà vu. Hadn’t I heard a talk just like this one while I was in college? I think I had… it was about COBOL. We were too cool for COBOL back then, or perhaps too unenlightened is more accurate.
Let’s see, if we take 1960 as the birth of COBOL (1959-61 seems to be the range of initial activity) that would mean that in 1985 it was 25 years old. Let’s say that my opinion of COBOL in 1985 was not especially high. But wait that same year could arguably be called the birthday of C++ because the first commercial C++ compiler became available then. So let’s see — it’s now 2008…. so C++ is 23 years old. The same age as COBOL when I started college.
The fact that I can even offer this perspective is already making me feel old 🙂
But, aside from nostalgia and pointing out what a nub I was in college, what’s my point? I always have a point right. And I assure you it isn’t slamming folks still working on COBOL because high quality COBOL implementations have continued to show the viability/future of that programming language for my entire career.
My point is this: In many ways the same kinds of problems face our industry today as always. Migration of existing codebases to the latest technology while preserving their value isn’t a new problem, it’s an old one. And I use the word migration loosely because often it’s not really some kind of conversion or retirement of code but rather more like a meeting of worlds.
When I was in college one of the big buzzwords we heard about was 4th generation languages, and sometimes even (ooo, aaah) 5th generation languages. I don’t know if I would really score the industry very high in terms of actual *language* evolution in the last 25 years (though I’ll be the first to give Anders kudos for enabling your average VB programmer to use functional programming constructs without even having to know it). Where I will score us highly is in runtime evolution.
So programming languages are somewhat similar, at least broadly speaking, to what they were say 25 years ago. What’s changed is the environments we like to run in. GUI environments drove event-based programming which caused a need to express those notions. Object oriented programming fit that need well and had other benefits and so many embraced it, or borrowed notions from it (tell me, what’s the difference between a MessageProc (with its associated switch statement) and an object with vtable? Mostly syntatic sugar. But the programming model is fundamentally different than say a console application.
Now its happening again, and the real need facing C++ programmers is somewhat the same as what faced COBOL programmers say 25 years ago. It’s not that the language is out of joint — it isn’t. I mean, ok maybe you like or don’t like COBOL syntax but that doesn’t doom a language and surely C++ syntax is not the zenith of wonderfulness. But that isn’t what’s holding C++ programmers back. The biggest problem, at least in my opinion, is one of accessing new/modern runtime features that may have a different programming environment from the context of an existing environment. Hybrid applications are the norm.
Most programming languages you can name have natural environments that they like to run in and natural kinds of application notions they can express well.
And now, GUI environments are changing; more declarative models like the WPF/XAML programming model are becoming popular. Multi-threaded needs are becoming more mainstream. Then there are all the rich client models like AJAX. And many others. Many of these have complicated resource management problems that make you want to reach for languages that have automatic management of resources (like the .NET family and Java).
The truly successful environments of the future may have more to do with their ability to mesh together many different kinds of assets than defining some new uber language and uber runtime. I’d love to do this nowish because, 25 years from now, I bet there will be something newer/better and I don’t want to have to migrate an industry again. 🙂