Superfluo

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.