lesscode.org

Twenty years ago I got involved in a course of AI (Artificial Intelligence) study. Soon afterwards, I’ve learned, much to my dismay, that this field has been, somewhat maliciously, dubbed ‘giant solution in search of a problem.’ Much as I’ve tried to convince myself (and the others) that AI has some pragmatic potential, I had to eventually abandon my efforts, and turn to some of those truly pragmatic solutions (such as RDBMS, for example).

History tends to repeat itself, and so (not surprisingly), I’ve ran into the same scenario (i.e. got involved with more than one ‘giant solution in search of a problem’, or GSISOP) throughout my meandering career.

The first major bump in the road was working with CASE (Computer Aided Software Engineering) tools. Those beasts used to be all the rage in the mid to early ‘80s, but witness the speed with which CASE turned into a dirty word in the early ‘90s. That utopia had to be abandoned promptly.

The next bump came in the form of ‘screen scrapers’ which were proposed as a GSISOP to bridge the gap between the monolithic mainframe apps and the burgeoning two-tier client/server enablers.

One of the biggest GSISOP bumps I’ve ever experienced was Lotus Notes, later dubbed Domino (does anyone even remember that unruly beast?) That platform was so ridiculously clunky, that even the biggest Domino zealots had extremely hard time explaining what is it that this product actually does?

Fast forward to 2005. What is the GSISOP we as a development community are forced to deal with today? CASE is dead as a doornail; screen scraping and client/server are dead as well; so is Domino. Does it mean that GSISOP is dead too? I wouldn’t bet the farm on that.

Ten years ago I’ve abandoned the world of two- and three-tier client server technology for the new kid on the block. That kid was then called the ‘nomadic code’. Remember the ‘network is the computer’ slogan? Or, for that matter, does anyone here remember the ‘PC killer’ – the NC (the network computer, or the glorified dumb terminal that was all the rage back in 1996)?

I remember how in those heady days me and some of my more idealistic colleagues firmly believed that the applications of the future will consist of modules of highly mobile code buzzing around the net, arriving ‘just in time’ to assist with some hairy, highly critical, highly demanding and customized behavior. We furthermore believed that these modules will live in a highly competitive environment, vying for the end-user’s attention, competing to deliver the best, most robust service, thus building their own reputation. Talk about GSISOP!

Yes, we were the Java evangelists. For us, Java was the way of the future.

We had to endure a lot of flack for our beliefs. But we’ve persisted, prevailed, and through Herculean efforts managed to bring Java into the corporate fold. Despite the false and doomsday claims that Java was ‘too slow’, that it ‘wouldn’t scale’, that it was ‘too complex’, today we see that Java is the bread-and-butter of the contemporary corporate computing.

So why am I telling you all this boring stuff? The reason is that today we finally have this ‘new kid on the block’ – Ruby on Rails. Similar to what Java was ten years ago, RoR today promises a completely new way of not only looking at things, but also on doing things.

And similar to the case with Java ten years ago, many people fail to see the true potential of RoR. Not surprisingly, because, same as Java from ten years ago, RoR is not a GSISOP.

Why am I convinced that RoR is not a GSISOP? First of all, it’s not ‘giant’ (same as Java was an agile, small footprint solution ten years ago). Secondly, it’s not a ‘solution in search of a problem’, because it deals with a very specific problem at hand – how to implement the principle of Occam’s Razor. And it does it extremely successfully.

So, if Java is not a GSISOP, why do we need another non-GSISOP? Doesn’t the principle of Occam’s Razor (‘entities should not multiply beyond necessity’) go directly against having two similar solutions?

You see, the problem is that Java WAS not a GSISOP, but (sadly) grew into one over the years. Today, I claim that Java slowly and maybe imperceptibly morphed itself into a GSISOP. One need go no further than examine the Struts framework, for example, if one would like to understand what a GSISOP really is.

As we all know, Java community is getting mighty agitated over the RoR promise. What’s particularly amusing to me personally is how the same people who had to endure unjustified attacks on Java some eight-ten years ago, are now using the same unjustified argumentation to attack RoR!

Of course, a number of Java supporters are now rushing out to perform what I like to call ‘putting a lipstick on a corpse’, in order to prove that Java is indeed capable of doing anything that RoR can do. These are sadly misplaced efforts, which eerily remind me of the long gone days of the screen scraping efforts. Same as the mainframe folks tried desperately to prove that Mainframes can do client/server computing without leaving their comfy OS, Java advocates are now wasting their time trying to prove that ‘Java can be concise too’! It resembles some political PR where a spokesperson of some dictatorial regime claims that their regime can be democratic too. Yes, there is no doubt that it can, but the real question is: why isn’t it? If Java can be concise too, then why isn’t it concise already? Why do we need Struts? If Java is by its nature concise, why did we end up with such monstrosities as Struts and Jetspeed and Expresso and Tapestry, etc., all of which harken back to the bad old days of mainframe programming?

In the future (if the future ever comes for me), I’m planning to discuss the shift in the philosophy of complex system development that RoR brings to the table. I’m planning to focus on the complex-vs-complicated dichotomy in particular.

Comment RSS - Trackback URI