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.

Wednesday, August 19, 2009


Stop wasting your time with your underwater mortgage

Here's something I don't understand: why people with underwater mortgages have any qualms about deed-in-lieu. Say you bought a $900K property in 2007 with $800K on the mortgage. Now that property is worth $600K and you still owe $750K. You should hand the keys to your lender and find a new place to live. Trust me, there are kick-ass rentals that are less than your mortgage payments and there will be for several years to come.

The thing I don't understand is why people have a moral dilemma about doing this. Morals aren't an issue because that's the agreement with the bank. They agreed to give you the money, and in the case where you don't pay the money, they agreed to take the house. End of story.

What's really weird is that people don't seem to have a problem with this when the loan is a corporate loan and that corporation goes belly up. Hey, no problem, right? That's capitalism. The lender took a risk with that corporation and lost. But when it comes to personal loans, somehow the banks have convinced people there's a moral obligation as well. Maybe there is a bit of fraud if you charge up a credit card with expensive wines, drink them all, then never pay off the credit card. But there's no moral obligation with a mortgage -- they agreed to buy that house. Just give them the keys and call it a day.