That prediction hasn't come true. We continue to use C++ for almost every useful desktop app (as I pointed out in this post). Games are virtually 90%+ C++ for all platforms.
I've started wondering, "What makes COBOL 'COBOL'?" The last time I used it was in a high school programming class in 1987, so I don't have the knowledge to examine the language at that level. I don't think it's just the fact that the language is verbose and kinda sucky and there's lots and lots of code. I've come up with two things that make might make COBOL what it is besides there being lots of code:
- Domain specificity. It was a language almost entirely used on mainframes for business and data processing. It had no real other use besides that. No real embedded uses, no system-level code. This really led to a situation where the language had nowhere to go -- its userbase was only concerned about one area and the language and community did not ever need to respond to changing needs. This is a significant difference between C++ and COBOL.
- No migration path. The main paths for migrating out of COBOL are a newer version of COBOL, which are in very little use, or a rewrite. Contrast this to C++, where, if you wanted to migrate to Python or Ruby, you could simply SWIG your C++ code and start writing Ruby around it, then migrate the C++ as you see fit.
So let's take a look at the contenders:
C++: I think I've already shown that C++ will not be "the next COBOL." It's far easier to port yourself away from C++ than it ever was for COBOL, and the language is still so general that it's used very widely for various applications.
C: Definitely not. C is the most general, most useful language ever invented. Doesn't fit into either category above.
Ruby, Python: I don't think they fit the bill of being too domain specific. Python has been embedded into 3D applications like Maya and is used to back websites like Reddit and Slide. Also, there is just not enough code. If a Y2K problem came up with either of these languages, it would be drop in the bucket compared to what it was for COBOL.
Java, C#: I'm putting these together because they're similar in that they both run on a VM. I think that will remove the problem of there being no migration path for them. Already on the JVM, there's a large interest in Scala. There's a clear path for integrating Java code with Scala and then porting that code to it. They're also used too generally.
So what is it, what's the next COBOL? I have some ideas:
XML: This isn't a "language" per se but I did want to include it in this list out of loving spite.
. However, because of frameworks like Spring, or anything Sun or Microsoft ever does, there is a ton of data-driving-application information being encoded in this format. It is very wordy, and very, very pervasive. It isn't domain specific, and it should be easy to make a migration to another data storage format.
Perl: Like anyone else who has used it, I hate it. I think it has a shot at being "the next COBOL", but for different reasons. It's certainly not domain specific. Doesn't have a clear migration path though. Mainly, it's just so hard to support and there's so much of it out there. I kind of doubt that super-mission-critical stuff has been done with it for most companies. I always envision Bank of America's IT department when I think of the COBOL case. Companies like Amazon might have a hard time with this, I'm not sure if it will be a general problem.