Superfluo

From a one month old post written by Sam Ruby:

The difference isn’t the language, but the libraries. Outside of Weirich and DHH, the Ruby libraries are at best uneven. This even includes libraries which are included with the language. Many seem to be baubles that were created by authors without an attention to detail, and subsequently abandoned.

I have played a lot with the Ruby language in this period and I've the same unpleasant feeling. Maybe, with the continuous growing (intuitively I agree with Pascal Belloncle's comment) in the interest for that language, the situation is going to improve. At least I hope so.

Editorial notes: this isn't a long post but I believe to have already accomplished my plan with an article (in Italian) on Superfluos; although the summer is almost finished, I doubt to be able to write more frequently in the future.

Yesterday I was talking with my fellow in business about Ruby on Rails and my doubts on its adoptability in designers driven projects (we were just going to meet a bunch of designers ;-) ). So I thought of the question again and understood that my conclusions were partially wrong and I was too hurried in writing them (ah, the desire to post!).

The described problem is real: in such kind of projects there are difficulties to organize the work in a way that:

• maintains the most suitable environment for each involved part,
• facilitates the collaboration and the integration of the work.

A perfect solution doesn't exist and it's necessary to come to compromises, I believe.

I sustained that Ruby on Rails wasn't adapt for managing this operational context, particularly in comparison with the JSP or PHP approaches. This is wrong because, except for the simplest cases, also these last ones are destined to break the normal HTML functioning. It's true that they maintain an environment more similar to what the designer expects to find but this alone is a marginal advantage.
Moreover and above all, independently from the adopted technologies, for preserving the designer-friendly pages navigation, one has to renounce to the MVC pattern and often it isn't worthwhile!

So I'm happy because I'll have less hesitations in using Ruby on Rails even in designers driven projects :-) . This doesn't stop me to look at Nitro because it seems to have a lot of flexibility and that's may be useful in a plenty of situations.

I followed the hype too and I've tried Ruby on Rails.

A digression: I think that there is a big difference between the hype in real life and in software development. In real life one can be completely nonconformist and lose nothing (one lives even better!). In software development, instead, the hype matters because it means more interested people and this implies more documentation, more code, more tools, more resources in general. Of course a flawed product remains flawed even if it's over hyped so one must be careful as usual but the hype should be considered a plus.

I was saying that I've tried Ruby on Rails on a little project and I must join to the many that say it rocks. In little time I created a working application and deployed it. In truth it was a very simple job: a products' showcase, whole similar to the depot application described in Agile Web Development with Rails. Anyway I'm sure I wouldn't be able to do it in less time using other technologies, although I'm a complete newbie with Ruby and Rails!

This experience has been enough to make me assert that many of the Rails spot are indeed true. Among them, my favorites are:

1. One language: Ruby

   (from the Apple Rails tutorial). One language should suffice :-) because using multiple languages makes the learning curve steeper and inter operating between them often causes unnecessary impediments.

2. Instant feedback: edit the code, hit Refresh, and the change is in my browser.

   (from Agile Web Development with Rails). I know, the theory blames the change and try approach but the practice teachs me that it's a great value. Maybe it's also a form of agility, related to the working software over comprehensive documentation assertion, and we want to be agile, or not?

In years, as a developer, I've used almost exclusively the Java language and I like it a lot. Some sustain that Ruby is more powerful but frankly I haven't played enough with it to form an opinion on this subject. Instead I can complain about the lack of a powerful IDE and join Dion Almaer in his request for IntelliR :-).
I used RadRails that is nice (and fresh winner of the Eclipse Best Developer Tool Award) but is far away from what can be done with eclipse or IntelliJ IDEA with Java code. Again I agree with Almaer in his response to Bruce Eckel: an evolved IDE is a fundamental tool that can boost your productivity and software comprehension.
An IDEA developer is accustomed to features like:

• code navigation between files, classes and method, etc.,
• sophisticated refactoring,
• code completion,
• error highlighting and intention actions

and strongly miss them when aren't available!

I think that a dynamically typed languages is less inclined to be tamed by an IDE and this is a structural disadvantage. However Almaer (yes, always him :-) may be right when writes:

The real winner though? Nice language AND nice tool. And, it's coming.

especially when looking at what JetBrains and Interact (via Ajaxian) are doing with JavaScript.
Moreover, although I agree the most with the article of Bruce Eckel titled Strong Typing vs. Strong Testing", in my opinion:

• the compiler still does a good job and saves you from writing many tests,
• considering IDE support, statically typed languages aren't so much less productive than dynamically typed ones.

On the other side, the dynamically typed languages are concise and more manageable. Ruby, in particular, seems to have some potent constructions (I'm thinking, for example, to its capabilities in meta-programming) that should be of great utility but, unfortunately, I don't yet know :-) .

However, if it's true that the dear Java language is becoming old and it's time for a change, maybe I'll prefer to choose again in the static realm. There, the Scala language (via Waste of Time) looks very promising but, as Francesco remembered me, it isn't enough used: if being hyped brings more resources, on the contrary, being not much known is an big deficiency :-( .
Ruby instead is gaining acceptance on a daily base and is a nice language: it's a pure object oriented language and reminds me Perl, that I love. Surely it's a strong candidate.

Anyway, I think that the programming language is not the most important thing to take into consideration and that frameworks matter more (perhaps the two things are connected: good frameworks are written with good languages and vice versa ...). Ruby on Rails is a great framework and I may explain why in my opinion in some cases it is the optimal choice. I may also try to compare it with other ones belonging to the Java world, highlighting pros and cons. Instead, as this post is already too long, I'll preserve these ideas for when I'll have the time to write another one :-). So,again, I'm going to focus on what, from a newbie point of view, I believe isn't so good (please Ruby and Rails people excuse me!).

Rails is a pure MVC framework and this is fine in a developers driven project, i.e. a project leaded by the developers in which the designers (if present) are able to work directly on views and check the results through a running web server.

Unfortunately, in the typical situation we have designers driven project. I'm talking about those low budget (but high frequency) jobs in which a designer (or a group of designers) brings to you, developer, a static web site and asks to add some functionalities. The problems in this context are that:

1. designer and developer work separately, this isn't agile but real,
2. designer has the command and is not inclined to change his modus operandi.

Using Rails you have to break the original HTML structure to honor its MVC pattern. On the other side the designer continues to work on the graphics (he must change that awful color, increase the image width of 2 pixels, move the menu from the right to the left and back and so on) and want to do it on a natural (non-Rails) structure. In this way the integration soon becomes a mess.
From this point of view, PHP or Java with JSP (but without taglet) have a cleaner and more convenient approach. It may be that Rails can solve this problem with no effort but I don't know how (probably one can reconfigure the views' locations to resemble the environment the designer expects to find).
Anyway I searched a little and I haven't found a simple workaround. In compensation, I discovered Nitro. Judging from the (terse) documentation and from the demonstration videos this framework (do we need another one?) is very promising and could solve this problem without renouncing Ruby and most Rails peculiarities. Unfortunately, as for Scala, it doesn't seem very used and consequently there won't be a lot of resources. We'll see if it gains popularity, good luck Nitro!

2006-May-07 CEST: Nitro has moved and I've updated the links.