Friday, August 21, 2009

What language will be "the next COBOL"?

I've been thinking about this for maybe 15 years, when my friend from college Ed Burns (also check out his book) handed me a copy of The Unix Hater's Handbook (this link is the complete book). In that book, there's a chapter called "C++: COBOL of the 90's"

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.

Javascript/DHTML: I am very curious if this will be it. It is domain specific, has a ton of code and zero migration path. ALL companies on the web are using it extensively (including Bank of America). As far as domain specificity, I know that people really want to break Javascript out of the web browser, but for now that is mostly just experimentation. No one in their right mind would back a website or write a desktop application in Javascript at this juncture.

Additionally, JSON is making Javascript even more rooted in its place in the web browser (as opposed to allowing for Python to run there and using a generic data exchange format). It seems hard to believe, but someday maybe there will be a better mechanism for communicating these online applications than, oh I don't know, plaintext HTML and Javascript?

I don't hate Javascript. However, Javascript is domain specific, there is no migration path, and it's mission critical to virtually all websites. I think we've got a contender.

1 comment:

Anonymous said...

I've heard that this has already happened to some extent with Microsoft COM, or more specifically, COM in C++. Apparently there was a point where everyone rushed over to .NET, and after the initial hangover, some companies found a need to go back to the old ways. Unfortunately, no one bothered to learn COM recently, so the only choice was to hire a senior engineer with C++/MFC/COM experience for a high price.

It's not likely to happen any time soon, but I'd actually vote for VB. There are two reasons. The first is that there is very little you can do in VB.NET that you can't do in C#, since both are .NET based languages. The second reason is that Microsoft is clearly putting a bit more emphasis on the C# side. Both are completely reliant on Microsoft for longevity. It'll only take another VB.NET style push where Microsoft decides to strand VB.NET on either support or functionality for the language to effectively be dead-ended.

Note that there is a side problem in that in order for this phenomenon to occur, you need a system that outlives its programming pool. I'd say that doesn't happen much anymore, because applications and systems aren't usually bulletproofed and kept stable to the same extent as in the mainframe days. Some days I can look out the window and watch the frameworks come and go.