Tuesday, February 3, 2009

It's Easy!

I am becoming increasingly annoyed when I read articles celebrating some new programming language or toolkit as being "easy". It has gotten to the point now that for me, such statements count as a strike against the technology in question, rather that a point in favour.

To be fair, I suppose it's not a strike against the language or toolkit, but rather against the author of the statement. I have just gone through an exercise in aggravation that stemmed from this notion. I needed to develop a performance measurement tool for a client. After considering my options, I chose to develop it using the Google App Engine (GAE). My decision was based on 1) Time to market, 2) Cost of hosting, and 3) Reuse of existing infrastructure. GAE is built on the Python scripting language, and though I had never coded in Python, from what I had heard and read, it was supposed to be an easy language to pick up and work with. In truth, it is easy to learn Python. The language is quite well documented, and the syntax is fairly intuitive. It should have been, according to the proponents of scripting languages, really easy to punch out this application. Combine that with GAE, and not having to write a whole user administration component, and I should be laughing.

My mistake was in thinking that the once the Python application is delivered, it will be of the same caliber as its Java counterpart. This is not the case. Python may be a good prototyping language, and it may even serve for simple little scripts. It is not what I would call a carrier grade language. Which surprises me, since Google seems to use it so extensively, I would have expected more. Here are three reasons why I would stay away from the scripting languages, and stick to the more mature languages like Java or C++ for any application for a paying customer.
  1. With Java, when I refactor a method or class name or signature, I am not relying on a keyword search of the code base to find the instances that need to be changed. The IDE will locate all the references to the method or class in question and change them. Should the IDE miss something, the compiler will catch it. With a scripting language, you make your changes, and then have to run the code to see if you have missed anything.
  2. With Java, there are many tools for tracking your code coverage. And in fairness, there may be such tools in Python, but that would mean hunting them down and trying to find out which one are best, then learning how to use them, etc, etc, etc. When I make a change to my code in Java, I can find out almost instantly if it is sufficiently covered with unit tests.
  3. The type safety provided by java is second to none. These languages that allow you to change the type of the variable on the fly (like Python and Ruby) scare me. How can you code with any confidence knowing that the objects you are referencing may cease to be the same type of object the next time it is run? One of my colleagues used to say that "Software doesn't rust". Well, with these types of languages, I'm affraid that it does!
I was lured by easy development, and I am now paying the price for my laziness. It looks like I may be re-writing my application (at my cost) in a language that will last! I sure hope that GAE starts supporting Java soon, it's otherwise a great service.