Is Ruby coming?

First I have to admit that despite owning the pickaxe book and Ruby On Rails, I have yet to read either of them. But the ‘Is Ruby the next wave’ debate seems to continue to rage. Bruce Eckel seems to be the latest person to start asking these questions, pondering on Bruce Tate’s conclusion in ‘Beyond Java’ that Ruby is ‘it’. Even Bruce Eckel seems to be moving away  from his initial hostility.

 

Some of the spur is attribued to the failure of the EJB architecture to deliver for Java developers. It is percieved to be over-complex for many of the problems it has been used to solve. The .NET commnunity has never seemed to suffer from this problem to the same degree – despite the availability of Enterprise Services (COM+) the struggle in the .NET community seems to be more to move enterprise developers away from the datasets connected to web pages toward a more OO approach than the other way around. The Java communities urge to bring up the big guns never seemed to happen within the .NET space.

 

But why are the ‘thought leaders’ of the Java community looking to produce rails like RAD platforms in Java. Why move to Ruby?

 

Partially I suspect the answer may be that all frameworks begin to develop a ‘barrier to entry’ and Java may have hit its barrier. 

 

A lot of genre TV shows have the problem that as they progress the knowledge, gleaned from previous episodes, becomes essential to later episodes. Watching series three of Buffy the Vampire Slayer would be hard if you had never seen the first two, too many assumptions about vampires, slayers, watchers, and witches would be lost on you. This problem is usually called the ‘barrier to entry’ At a certain point the obstacles to becoming a viewer become too great and you get no new audience. Over time attrition wipes out your initial audience and you cannot replace them. Your hit show slowly declines toward certain cancellation. An in the same way frameworks can be start out simple but build over time to plug gaps and adapt to new paradigms. If you have been following along from the beginning the work load to keep up to date is usually never too bad, but for a newcomer it can be overwhelming. And as old paradigms are discarded, backwards compatiblity forces their retention and cloudis the difficulty of learning the framework with questions like: ‘Which of these options, that seem to solve the same problem should I use, and why?’. Frameworks, hard to refactor because of their many consumers, then begin to look like the kind of code every developer has experienced in the first days on a new site when they look at a legacy application and find themselves asking ‘Why?’ While internally we can refactor, if we have tests, to try to move away from the big ball of mud, pity the framework designer who can never refactor your code to use the newer API and must support everything for eternity.

 

I bet the VB team were partly glad that .NET gave them a fresh start.

 

Version one of the MFC, the C++ framework for writing Windows client code, did very little apart from offer you collections and simple window wrappers. There was little barrier to entry. Version two brought in the document/view architecture and there was a fair amount to learn but by version 2.5 we had support for OLE and the amount of effort you needed to invest to learn MFC grew and grew. A lot of the growth comes from morphing the framework to fit new paradigms. MFC became so convoluted to do COM programming in that a new framework ATL, built on templates evolved to simplify it.

 

Ruby’s advantage for now is that Rails is a new and therefore simple framework. People who want to do simple tasks are not distracted by the support for the complex ones. MFC became complex when OLE support wieghed it down – and most people never used Active Doucments in their applications – and came to regret it if they did. Java became wieghed down with EJB until many of its supporters moved on Ruby because it is ‘simpler’. Of course they could have used simpler Java frameworks; but the pressure to conform, to be a ‘proper’ Java programmer probably kepth them away from a simpler approach of say using Hibernate and Spring (which themselves may be overkill in some instances). If Java has become too compex, reject it and move on.

 

I don’t think that the .NET framework has reached it barrier to entry yet, but the arrival of WCF and WPF will expand the framework to match new paradigms. C# 3.0 will introduce new paradigms via LINQ that many developers will find increase what they ‘need to know’.  Maybe, looking back in the future, one of these will be seen as the point that the barrier to entry began to grow.

 

So can .NET overcome this obstacle?

 

What is interesting for the .NET framework is that while it supports many languages few are championing a lightweight, small framework language for developers to use on that platform.VB seems to want to fight with C# over who gets to be the general purpose language, instead of cutting its own jig, and many a VB developer I have spoken to rankles at my suggestion that VB needs repostioning as a lightweight, low-complexity development language, fearful of being seen as lightwieghts. That is a shame because the lightweight language that VB once was might have been so well supported in a world where components authored in different languages can easily interact that it may have moved in the wrong direction and missed a trick.

 

IronPython holds some promise as being a lightwieght dynamic language for the CLR, but where are the Rails like frameworks for it. I know that Monorail is trying to provide a Rails like RAD platform for CLR developers, but I’m amazed that no one is focusing on a language or CLR framework that can do a lot in a simple, yet  OO paradigm, and easily use assemblies written in other CLR languages when it needs to. Isn’t that multi-language support exactly what the CLR was for?

 

What we nmay well need is a Ruby/Rails like paradigm for the CLR, and seeing as Ruby and Rails have been many years in the making, perhaps its time someone started planning for the point at which the .NET framework is no longer the main or only platform for doing productive work on the CLR.