Cycles in Computer Science, or Am I Ancient?

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].

Eeep.

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.  :)

Comments

• Anonymous
  May 05, 2008
  In some sense, C++ was reborn in the 1990s.  STL and Boost have given us a whole new version of the language ("modern" C++) that's still being standardized.  RAII paradigms have given us a better way to manage resource lifetimes than garbage collecting environments (because they're deterministic and cleanly handle ALL types of resources, not just memory). So C++ isn't really 25 years old.  Maybe 10. And don't forget that many of us have codebases that are still partially in C, because those bits pre-dated the advent of C++. As for hybrid environments, VAX/VMS had the best.  Your programs could be written any combination of languages (assembler, BASIC, BLISS, C, Cobol, FORTRAN, Pascal, PL/I), and it all worked because of the common languages runtime environment.  It truly let you pick the best tool for each part of the job. Sounds like I'm the same age as you (old).  I still miss Pascal.

• Anonymous
  May 05, 2008
  There's something askew in this analogy: the languages that replaced COBOL typically weren't written in COBOL. The shiny new VM-based languages and scripting environments that are all the rage today usually have C and C++ at their core. PMP

• Anonymous
  May 05, 2008
  Hey no analogy is perfect, otherwise it wouldn't be an analogy :)

• Anonymous
  May 05, 2008
  The comment has been removed

• Anonymous
  May 05, 2008
  I didn't hear my obsession template metaprogramming. :)

• Anonymous
  May 05, 2008
  You mean Windows 13 would be programmed in C#.NET 12.0? :) Or the C#.NET 12.0b compiler will be written in C# itself? C/C++ are the running blood of computer systems, atleast for now. i dont think it can go out of business any time soon. C++0x is on its way. Unless computers are re-invented (talk quantum computing) C/C++ is going to remain here. Because its a language next to assembler, which is next to machine language, which is next to what our current computer architecture is. C/C++ is as close as you can get average-humanly to your computer system. So as long as there is a need for performance critical applications and appliances, as well as applications that run applications (talk OSes, network drivers, display drivers etc) there will always be C/C++. Personally, i think its only C. what you can do in C++, you can do in .. well C#/Python/Java etc. But then, maybe im not as old to comment like that :)

• Anonymous
  May 06, 2008
  So, if C++ was less suited for hybrid applications, what was COBOL less suited for than C++?

• Anonymous
  May 08, 2008
  >> C#.NET 12.0b compiler will be written in C# itself Mono C# compiler is already written in C#.

• Anonymous
  May 19, 2008
  The comment has been removed

• Anonymous
  May 23, 2008
  Hey! what is going on here. no programming language has ever been invented which is suitable for all the scenarios. So, C++ is good for a lot of things which C# can't do for example system progamming (OSes, drivers etc) but C# can do a lot which C++ can't for instance Reflections. None of these can match the string manipulation provided by perl. So, this discussion is useless. You guys are trying to compare apples with oranges....do you see any similarity other than that both are fruits? similarly C++ and C# are different languages designed with different goals in mind and both pretty well achieve their goals. If you expect C# to be used to write a C# compiler, the compiler itself it will need a .net VM. So, the first C# compiler had to be written in a lower level language like C++. Reminds me of first C++ compiler being written in C and first C compiler being written in Assembly. First assembler was of-course written in machine language. But that doesn't mean machine language is the ultimate language of choice. Neither does it mean that C# is the best. All the successful languages are successful because they achived their goals and their designers had intelligently chosen their goals. Each however is inadequate in replacing any other.

• Anonymous
  May 24, 2008
  Let the religious wars commence :) There's similar discussions happening on Eric.Weblog() and stackoverflow.com -- and I'm sure they won't be the last. For what it's worth, I love C/C++ and I believe learning them has made me a better programmer (as has ASM).

• Anonymous
  June 06, 2008
  These are all blog posts I flagged as being particularly interesting, but ones where I may not have anything