Saturday, April 09, 2005

Which Language Will Be the COBOL of this decade?


Because clearly one of them will.

Let me first start out with a discussion of Ruby a little more. I'm having second thoughts about basing any project on this language. I'm probably going to complete my current project and then reimplement it in Python.

Some small reasons are these:

  • Speed. The language is significantly slower. As I mentioned before, this was a concern with Python years ago and they fixed it. However. In 2005, you would hope that anyone looking at writing a new VM would instead just use the Java VM or CLR. They plan to use neither to improve Ruby. That blows. Why the fuck do we need yet another VM that can't interoperate with other languages?
  • Syntax. I'll admit, I am concerned with the use of special variables like "$_", "$1", etc.. They are way too PERL like to make me feel comfortable.
  • Standard libraries. Basically, there aren't a lot. Ok, there are... compared to PERL in 1993, but not compared to Python or C# in 2005.

The largest reason is this:

Ruby is a language that makes me wonder if object-orientation can be taken to the level of obfuscation that something like PERL has with straight code. Take this code posted to the rails list for generating a random password:



def random_password
chars = ['A'..'Z', 'a' .. 'z', '0' .. '9'].collect{r r.to_a }.flatten
(1..8).collect { chars[rand(chars.length)] }.join
end

The original poster was trying to help another guy out, but this post got me thinking. I started wondering, is it possible to take the "object" too far in a scripting language? In making a random string of characters, there are not one, not two, but six method calls in the above code. A for loop would have performed just as well (or better) as the methods and closures and would been more succinct (IMO).

Don't get me wrong, I actually see and can acknowledge the elegance of the code above. At the same time, I ask myself if looking at this kind of code 5-7 years from now is just going to be a pain in the ass -- like looking at PERL written by someone else in 1998 is today. I pretty much can look at Python written at any point in the last decade and understand what's going on there. That's not true for other languages.

So I'd like to know, what's going to be the language that has tons of code written in it and has to be painfully maintained by someone 10-15 years from now. Kinda like COBOL. Let's go down the candidates:

  • PERL. Would be a great candidate if everyone wasn't already trying to ditch it so badly. I never really think PERL got out of the "tricky little script" category of programming except for the web. It definitely never got enterprise. If it isn't already, PERL will probably be out of most websites and be relegated to simple IT scripts within a year or two.
  • Ruby. Not nearly enough people using it to be considered.
  • Python. Definitely possible. Has had an amazing amount of uptake in the last couple years. I was working with a library of Python code today that hasn't been modified in 3 years and found an exception that wasn't declared (which of course bombed out when I triggered that exception). If Python code is not written with unit testing, it could easily fall into the COBOL category for anyone trying to use it years from now.
  • C#. Is actually a pleasant language and development environment to work with. I think that even if there is a lot of legacy code around in a few years, enough people would enjoy working in C# and .NET such that it won't become a huge pain in the ass. We know Microsoft will be pushing this for years and years, so I don't really see it going away.
  • VB 6. This is actually an excellent candidate. There are a ton of apps out there written in VB6 that people either don't want to port to .NET or don't have the resources to. 5 years from now VB6 could be a huge problem. We'll have to see what people do with their legacy VB 6 applications.
  • C++. This should have been the frontrunner. Then something happened: C++ got better and Java came along. The language improved a lot when exceptions and templates came along. Java pretty much took C++'s place for a lot of enterprise work, though I'm sure a lot is still being done.
  • Java. Very possible, but it has nothing to do with the language. It has to do with two things. From what I've heard, using it has mostly been by mandate. Not a lot of developers make a choice themselves to use Java. Second, its future is in Sun's hands and Sun isn't doing so well these days.
  • Objective-C. If anyone actually used this for enterprise stuff, we'd have a clear winner.

0 comments: