I just finished reading the Ruby chapter of the book 7 Languages in 7 Weeks. Asi
ID: 642719 • Letter: I
Question
I just finished reading the Ruby chapter of the book 7 Languages in 7 Weeks. Aside from some syntactic sugar here and there I can't really see anything which can't be done with C# with a similar syntax. I do understand both languages are inherently different, but my question relates to its usage rather than design.
Relevant questions make me believe Ruby offers little more than C#:
Why aren't c# programmers drawn to ruby as java programmers are?
Is Ruby's code block same as C#'s lambda expression?
I hardly worked with Ruby and my understanding of the language is still very limited, so perhaps somebody who experimented with both .NET 4.0 and Ruby can answer with concrete examples.
Which tasks require significantly less work with Ruby than C# 4.0?
P.s.: This question got closed on StackOverflow as too subjective and argumentative, although it did attract some attention. I was hoping it would be merged to here, but instead I'll just have to repost it.
Explanation / Answer
Ruby has literals for Regular Expressions and a bunch of useful syntactic shortcuts for the creation/interpolation of strings. So when your task(s) are primarily related to mixing an matching bits and pieces of strings Ruby might require significant less work (but outside of short helper scripts I must admit I found this to be a very rare situation).
More relevant are Ruby's meta-programming facilities. i.e. #eval, #define_method and friends, which combined with open classes, #include and #extend allow you to create tons of boilerplate code at runtime - you can argue, that code generators/wizards give you some of the same benefits, but you have to live with the - possibly very large amounts - of generated boiler plate code, compared to a relatively small amount of meta-programming code you'd have to read and understand.
A typical use cases for this is, having to interface with some kind of dynamic data provider outside of your application. Rails ActiveRecord is a good example for that.
In the future this might be very beneficial for developing GUIs, as you can generate methods handling events from user interface elements by creating methods during runtime based upon the UI elements ID, type, input values etc. (like Objective-C on steroids, maybe we'll see some of this power when MacRuby matures).
The line between good use and horrible abuse of this feature though is very very thin, and tends - from my experience - to be a major cause for headaches in large Ruby (on Rails) projects. So be careful when you decide to release the Djinn from it's bottle