back

Java vs C#, J2EE vs .NET, J2EE vs Ruby on Rails etc. The debate rages on all over the online forums, with advocates from each side arguing for the technology of their respective camps. I see these forums as a good visiting place for those who want to to see experts in today's technologies expressing their views (although you might have to do quite a bit of filtering to extract the useful bits). There is of course a certain amount of bias from those who grow up in one technology when they compare it against other technologies they are less familiar with.

I hate to wade into any of these arguments/discussions, namely because I am not the specialist in any of these technologies. I can do all of them, and can get them to do useful things for me, but beyond that, I would not like to offer, for example, an intricate insight into how the threading works in Java or C#. My simple goal in life is to get something done, and if one particular technology gets me there a fraction of the time quicker, I am willing to take the plunge.

I can think of two main conclusions I have arrived at after programming in C, C++, Java, PHP, Perl, C#, and Ruby (as far as my career goes, it is a pretty accurate reflection of the chronological order too):

1. Each technology is capable in their own right of delivering you the full real world application, whatever the circumstances. There is no such thing as a showstopper which prevents you from fully delivering your solution. You might have to force, nudge and squeeze a bit, but you can always fit ultimately.
2. Each technology has its plus points, together with the minus points. Your mileage and infrastructure have direct bearings on how well your chosen technology will deliver in the end

With the above points in mind, I would like to offer a different perspective into the above technologies, the maintenance and enhancement perspective. See, most of the hotshots who deliver you the wonderful application that your organisation bets its future on are going to want to move on to some other place down the road where the new shiny entry on their resumé will attract substantially more pay and status to go with it. The other reason is, most developers I know do not like the support phase that comes next after the application has reached production. They like bug fixes and enhancements even less, and it is time for them to move on (that leaves you with a problem of recruiting the next generation who are unfamiliar with the code and will most probably recommend a complete rewrite, but that is a different story altogether). So no matter what technology you went for, surely the most important aspect which should be considered has to be how maintainable and extensible it is, right ?

Java and ASP.NET

If I were going to design a collaborative enterprise level web application, I will either go for Java (Tomcat) or ASP.NET (I specifically mention Java and not J2EE because I think the J2EE architecture is a bit too rigid for a web application, but that is simply a personal preference). These frameworks are well supported and well understood, so the chances of you going out to the street and dragging in some readily available talents are not outlandish. The one important factor which I have not seen people mention before about Java and ASP.NET is that the application based on these technologies can be extended at any time along the lifetime of that application. What I am talking about is two years after you deliver your kick ass ecommerce solution serving millions of users, the management turns around and asks you to extend it so it can also trade in Korean Won and Brazilian Real. This means a change in the database schema, stored procedures, the middle tier, and countless templates to render your pages and reports, not mentioning the XML schema and all the WSDL services. Fortunately, this can be accommodated in Java and .NET.

The strongest feature is unfortunately also where the most painful experience will be. As mentioned above, a structural extension will affect every single layer of the application. With something like Hibernate or Castor, you will probably take some of the pain away, but you can not escape the fact that the presentation layer will need to be extensively re-engineered and regression tested. Remember, the more code you change, the more testing you need to do.

I like the ASP.NET framework in it visual aspect, which can increase productivity massively in the prototyping stage, although there is no real visible gain with respect to Java when it comes to introducing and propagating new enhancements, or refactoring (the practice of rationalising and elimination of redundancy in a code base). In fact, Visual Studio .NET (the de facto IDE for ASP.NET) is rather lagging behind the Eclipse IDE (the popular Java/J2EE platform) in certain aspects when it comes to refactoring and autocomplete (sure, you can write macros to do it, but Eclipse already has these facilities built in).

Some people develop Java using the Struts framework, which is a good MVC (Model-View-Controller) based architecture. The Ruby on Rails framework also uses this architecture, but with a difference. Rails uses dynamic discovery and runtime attribute bindings in order to glue the M-V-C components together. Struts unfortunately does not have that, so whatever changes you make will have to be propagated to the models, and the views, and the controllers.

PHP

Why do I make a point about the ability to extend the application once it has gone live in Java and ASP.NET so much ? This is because if you want to do it in PHP, it is almost hell on earth. Sure, it makes life easier if you are the original author because you know where all the changes should be. However, try downloading OsCommerce, install it out of the box, and then extend it to support arbitrary product description fields (which I actually had to do !). Take the example above about having to add support for multi-currencies and exchange rates, and then visualise in your head how many places in your code will have to be modified to accommodate this new feature.

The PHP design process tends to be less visual than ASP.NET and Eclipse in that you can not see the rendered version in the designer. Having said that, PHP makes up for it by being an interpreted language, so you can just change the code and click on browser refresh to see the end result.

Navigating your way through a PHP project frustrates me each time, seeing how modules are 'included' rather than re-used. The strong point about PHP for me is it is very quick to knock together a functioning website as a proof of concept, or verification of a database schema. Personally I hate having to pick up and extend a PHP project written by someone else.

I do not think PHP is suited for a collaborative project due to the 'include' and 'require' architecture. People will start stepping on each other's toes before too long. It is also not suited for multi-tier designs either.

PHP's cool features are built in PDF rendering and built in web clients such as ftp and http. It has straight forward database access, but does not come with sophisticated goodies like transaction or rollback support, or connection pooling. This is probably because it was intended to be used with MySQL, not Sybase or Oracle (and before you say it, my PHP application does use Sybase).

Don't get me wrong, you can do fantastic things with PHP. Look at Wikipedia for example.

Perl

I have done enterprise grade Perl CGI portals before, and the things you will yearn for are template support and object orientation (I mean real OO, not just blessing a lump of code without any access scoping). Perl is powerful as a text processing language, and you can use it for web sites too. However, without the help of periphery technologies like mod_perl or FastCGI, it is not the quickest of technology. I guess versatility has to be traded off with performance.

 I have seen powerfully put together Perl applications, and they can be pretty slick. A Perl/CGI application suffers from the same problem as PHP, in that structural enhancement can be painful and requires a lot of vertical changes and regression testing. If you want to open your mind up to what a Perl application can do, take a look at Twiki, the versatile collaboration tool.

One thing I am not fond of PHP and Perl about is the fact that they support the eval() function out of the box. This to means a badly written PHP/Perl application is quite likely to suffer from buffer overflow, cross site scripting, and SQL injection vulnerabilities. Also, PHP and Perl applications are more likely to make use of the file system to store temporary and permanent things. This is a recipe for disaster if one of the above vulnerabilities is discovered. A writeable file system is how most backdoors are deployed on to compromised web servers.

Ruby on Rails

All the hypes and all the fuss, is this the technology of the future ? Maybe, maybe not. Market forces will dictate. I have been using this framework for the last few projects, and discover that, like all its predecessors, it has strong points, and its has not so strong points. I am not advocating Rails, as I think it will be a while before it finds its way into big corporations. The stumbling block is Rails does not support enterprise class RDBMS like Oracle, SQL Server and Sybase out of the box. Sure there are provisions for extending the adapters to support them, but as I discovered recently, ActiveRecord (the Object-Relational layer) is heavily MySQL centric.

What about maintenance ? A Rails application contains surprising very little code. I have managed to write my Web-In-A-Box application with less than 3500 lines of code. So maintenance is going to be a breeze, even for someone who did not write the code in the first place. Regression testing is also easier because of the little changes involved.

What about enhancement ? the way Rails components are layered and perform dynamic bindings at runtime means there is very little configuration involved. I have had to extend the database schema in my application a few times and the new columns are automatically discovered across all the layers (M-V-C) of my application. More importantly, if I did not use these columns, my application did not complain or throw exception because of them. This would not have been the case with Hibernate or Castor, where the middle tier and the XML will have had to be regenerated and the whole project recompiled and repackaged.

The must have feature I discovered in Rails, which seems to be unique among all the web development platforms, is ERb (Embedded Ruby). This mechanism allows me to embed Ruby as I go about rendering my web pages. You will say, yeah JSP and an aspx page can do that too. Sure they can, but can they do this ?

In other words, from within my html template, I am able to declare a new variable at runtime and make it available as a parameter to the embedded templates I am calling in each iteration of a loop (you can just about do this with a JSP tag by passing the variable in the pageContext, but isn't the above code more elegant ?).

So is Rails the silver bullet ? Well close, but not quite. I would not like to use Rails for my day job (at least not yet), simply because the places I do business with do not have Ruby expertise and some will refuse point blank to support MySQL. However, for my night job, it is definitely more productive than most platforms I have used. Most importantly, I have found with Rails this 'awe' factor which I have not experienced with any other technology I have played with. The 'awe' comes from the few lines of code I have to write, and the amazement that it actually worked as expected, and the amount of functionality I achieved from those few lines of code. For example, this piece of code to interface to a XML RPC server works more or less first time, and I wrote it as I thought it should be after looking at the description of the XML request and response from here, rather than actually consulting the documentations:

As a technologist, it is important sometimes to derive satisfaction from what you do, instead of just getting something to work, is my humble opinion.

^back