I recently got to playing with Ruby, something that some colleagues in Lab49 have been big fans for some time. I've never been a big fan of scripting languages, but have grown more of an appreciation for functional programming over the past several months and thought I would give it a try.
Ruby is a very smart language, and I can certainly see why it has some appeal. The "don't repeat yourself" and "defaults over configuration" aspects of the language and its framework are really nice for cranking out simple applications.
ORM and Inference of Properties from database
I am a big fan of the objects that automatically get their properties from the database (a Customer object will automatically be linked with the Customers table when pulled through the ORM). Things like this make it dirt simple to crank out web projects of moderate size without writing tons of redundant code (as is the case with a classic OO approach, using adapters, abstractions, etc).
Even though this is a nice feature, and great for many projects, I am concerned that this is simply not sufficient for larger enterprise apps. Very often your app layer and database layer should be different, as one does not always properly map to the other. I suppose that you could achieve this nicely with views, however for large applications, the lack of abstraction seems a little brittle to me. At the same time, if you did change something in your database, you'd still have to change your abstraction logic, so maybe this isn't all that bad.
Syntax
The syntax of Ruby is very clean and straight forward. I like the bare bones structure, nothing more than needed is written. Reading into it a bit more, I found it interesting that various things can be written in several ways, for example:
while i < 3
print(i)
end
can also be written
print(i) while i < 3
While conceptually this is nice (the latter "reads" better), it is something I have a really hard time accepting. Yes it is nice not to have to write things like "end", however, syntactical differences like this (and others, such as the optional parenthesis around method parameters) concern me. While its great that you can develop your own style, and do what feels comfortable to you, it may be very confusing to other developers. An argument can be made either way, after call you can do this:
if (i < 3) Console.WriteLine(i);
in C#. Nothing stops you. At the end of the day, sloppy code is sloppy code, and its really a matter of having a well trained developer, not a strict language.
Naming Conventions
Here's something that threw me off. Ruby does a very good job of making names intuitive, however some of their names seem to break their own concepts. First of all, names like to_s are just sloppy. If you're making a lanugage thats supposed to be readable, why write cryptic names like this? Also, whats the deal with properties count and length being synonyms? Why have both? It seems relatively dangerous to me to have methods that mean the same thing on objects. A developer who sees count in one place and length in another may think they are different, something that certainly doesn't help code legibility.
Overall, Ruby has been fun to learn (although I'm still a novice), and I can certainly see its value. I'm not sure if I agree with some of its "friendly" tendencies -- being able to write whatever you feel and have it probably compile is not necessarily good. Just because code compiles doesn't mean its good code -- some bugs the compiler may catch now become runtime bugs. On the other hand, things like the ORM make it very easy to build rich apps with little code, something that .NET still comes up short on (just because designers generate LINQ classes doesn't mean that the code isn't there). Looking forward to playing more!