Why not Ruby?

flounder_p queries: "I have recently started playing with the Ruby programming language and think it's really great. I was just wondering why you guys think Ruby has not caught on more in the open source community than it has? How many of you guys are using it? Will it ever catch on or will it always be looked at as yet another scripting language? Don't get me wrong scripting languages are great (and I live by Perl) but I still hope to see Ruby catch on more. I would like to hear opinions on things on why Ruby is good or bad not on why OOP is good or bad. We have already had that discussion here." On a side note, a little birdy tells me that BlackAdder has plans for Ruby support in its next beta.

Comments

Ruby Resources

[Anonymous Coward]

Ruby is fairly new to the English speaking community, but there are some good resources for it. Dave Thomas and Andy Hunt (authors of the "Programatic Programmer") have been doing a great job of promotting it and getting the information out to all of us non-Japanese speaking programmers.

Here's some references ...

DDJ's January Article on Ruby (Thomas and Hunt)
Ruby Presentation (Thomas and Hunt)
Programming in Ruby Book (Thomas and Hunt. Available from Addison Wesley, online version is under an open content license)

And some web pages ...

Ruby Home Page
Ruby Central

Why not not switch?

[viktor]

I think the simple answer is that most people are quite happy with the scripting languages they already use.

Many people enjoy Perl, many enjoy Python, some enjoy /bin/tcsh. The latter population should however, needless to say, be put into working camps. Many also enjoy other languages, but I see Ruby mostly as a contender with Python and Perl.

So why should people switch to Ruby? Because they can do everything in Ruby they can in their current choice? Not likely. They can by definition already do that already. Because Ruby has an extensive library of ready-made code? No, because it doesn't have one compared to Perl or Python. Becuse it's a nice language design? Thats not enough reason to learn a completely new language if the one you use does what you want.

I might be prejudiced here, but i basically believe that many who like Perl do so because it's a very free-form (write-only :-) language, suitable for quick hacks. And those who like Python do so because it is a "cleaner" language, suited to write easy-to-read code. Both camps also enjoy the fauna of ready-made objects/functions/classes/modules that lets you do things easily without reimplementing the wheel.

There are probably Perlies that think Perl is a bit too loose, and Pythonettes that think Python is a bit too strict, and these people can probably find a new friend in Ruby once it gets the library support Python and Perl has.

But for most people that are already into Perl or Python, I think that the potential gain of switching languages simply isn't even close to the effort. And most Python-lovers don't want a looser language, just like most Perl-lovers probably don't want a stricter one. They're quite happy with what they've got.

In order for a new language to be able to make it as a strong contender to Python and Perl, I think it would have to supply something that neither language has, but that all programmers want (I can't think of anything matching that criterium at the moment, if I could I would've implemented that super language already! :-) If the language was then inbetween Python and Perl, both sides would have an easier time switching.

But only being between Perl and Python, which is just about everything Ruby seems to be at this point, isn't a reason to switch. It's just an advantage to ease migration if you happen to have something unique. Until Ruby actually invents something that makes it that much more valuable, I think most people will stay with the language they already use.

I do however wish the Ruby developers the best of luck. It is indeed a quite nice language, one I could definately imagine myself switching to if it gave me a clear advantage.

Some Annoying Features of Ruby

[cjs]

Well, after a quick look at Ruby, here are some examples for annoyances:

1. Strings are not value objects. Ouch! So you constantly have to worry about aliasing when you're passing strings around. Java got this right. (Though both languages fail on this count when it comes to date/time objects...sigh.)

2. I18N support is poor. Again, Java did this right (or got it much better, anyway)and made Strings sequences of characters, not bytes. This forces you to worry about your character set at the place (input) where you're actually in a position to deal with it, and then you never have to worry about it elsewhere. Ruby has some things (such as the Integer#char method) that just make no sense from an I18N point of view. Return the character represented by the receiver's value? In what charset?

3. Float uses the native architecture's floaing point. So FP programs' behaviour may differ (in very interesting ways, if you work with numbers such as the infinities and NaN) from system to system.

4. It's only related to certain styles, of course, but the semicolon-free syntax is, for me, more annoying than the semicolons. For continuation lines, I often try to split at operators (+, =, etc.) and put the operator at the beginning of the continuation line. Since a statement can't start with an operator (aside from C/Java constructs like ++, which I don't use in those situations), this makes it very natural to see the continuations, but in Ruby I have to put backslashes at the ends of all the continuation lines, now, and worse yet, make sure I edit them in and out properly when reformatting.

5. The Time object includes time zone information. This is confusing. Most stuff (such as comparating two times) seems to operate on the UTC value of the time, regardless of the time zone. But does #hour return the UTC hour or the hour in that time zone? If the latter, we can have two time objects that compare equal but where a.hour != b.hour.

Time zones are complex things. UTC and GMT are not the same thing (as Ruby seems to claim). Time zones do not have standardised unique three-character abbreviations (which is what Ruby seems to use for them. The time zone support, besides being fundementally broken in this way, is also implemented poorly; there's no easy way even to figure out the offset of the time zone of a given Time object.

And all this even before we start to get into date processing. Ruby doesn't seem to acknowledge the existence of different calendars. (Yes, even today different calendars are in use in a fairly major way. Take a look at a Japanese driver's licence if you don't believe me.)

I'm sure I could find more. And there's a bunch of stuff in Ruby that I like, too. But just from this glance, the language seems to have enough annoyances of its own that I can't see any reason for it to take over from Perl, Python, Java, or whatever.

cjs

Advantages over Perl

[Colonel Panic]

Don't get me wrong, I use Perl too, but I'm using it less and less these days. I've been programming in Ruby since about the start of the year and these are the advantages I find:

1) RUby has much nicer OO syntax than Perl - advantage is that when you go back to read the code after a month you can tell what's going on.
2) Perl's alarm doesn't work on the windoze platforms (sometimes in the corporate environement they make you use windoze), Ruby's timeout does.
3) Threads - With perl you actually have to compile a special threaded version. Ruby threads work - even on windoze.
4) Ruby has dRuby a distributed object system that is very easy to use (compared to SOAP, and other XML based approaches).
5) Hashes, arrays, strings have many more builtin functions (methods since they are objects) than Perl's Hashes, arrays and strings.
6) ease of writing extensions in C for Ruby(though Perl's Inline is supposed to make this a lot easier than it was in Perl)

And then there are lots of other things like about RUby like iterators, the ability to extend buit-in classes, built-in support for some design patterns.

Colonel Panic

Because Ruby Rocks! :-)

[CoughDropAddict]

I don't really know anything about Ruby; perhaps it provides something which Perl and/or Python simply can't.

Yes, it does.

A Few Things I like about Ruby, by Joshua Haberman

1. Everything is an object. Seriously. Even if you're not an all-out OO hippie, it gives great consistency:
   
   > 65.chr
   "A"
   > "hello".length
   5
   > [1, 2, 3].last.to_s
   "3"
2. variable punctuation determines scope, not type-- '@' is an instance variable, '@@' is a class variable, '$' is a global variable, and no prefix is local. This makes so much more sense than perl's confusing semantics ($foo[0] is part of @foo, but not $foo). It also lifts the ugliness of self.this and self.that. A constructor might look like this:
   
   def initialize(foo, bar, baz)
   @foo = foo
   @bar = bar
   @baz = baz
   end
   
3. Reading or writing from a class attribute is always a method call. I absolutely love this! It means you get the syntactic clarity of foo.bar = baz (no foo.getBar or foo.setBar), but the safety of hiding it behind a procedure. For example (this one is from The Ruby Book, in the chapter on classes):
   
   class Song
   def durationInMinutes
   @duration/60.0 # force floating point
   end
   def durationInMinutes=(value)
   @duration = (value*60).to_i
   end
   end
   
   And now you can read to or write from someSong.durationInMinutes as if it were a simple attribute when in truth they're methods!

I'm not a Ruby expert, and I'm sure that some of these features can be found in other languages: my point is that people shouldn't just assume that Ruby is another Perl or Python, because it offers several advantages that differentiate it from Perl or Python. (and these are just a start: it features iterators, blocks-as-arguments, threads, and more)

However I completely agree that not having something like CPAN is a serious disadvantage in comparison to perl.

--

I can tell you why *I* am not using Ruby.

[jemfinch]

I've been through my rounds with programming languages -- I started with C, then loved Perl, then moved onto Python and learned what readable code was, and now I'm currently enamoured with O'Caml.

Here are the reasons I'm not, and haven't ever chosen to use Ruby:

First, I don't like the syntax[*]. Python has a beautiful, simple, typing-economic syntax that no language I've seen can compare to. Ruby doesn't -- it uses "end" to denote the end of blocks, it has several prefixes (@ and $) for varaibles to change the interpretation of those variables, and it has a strange (to me) syntax for iterating through data structures.

Second, I don't buy the speed argument. I've tested various trivial scripts and a few non-trivial ones in both Ruby and Python, and found them about equal -- Python is faster in some operations, Ruby is faster in others. In either case, neither is ever much faster or slower than the other. In the world of scripting languages, a 10% difference in speed makes very little difference -- if you need more speed for what you're doing, you likely need an order of magnitude increase, and thus, a compiled language. A 10% increase in speed isn't generally worth switching scripting languages, and except for some pathlogical cases (which exist in both cases!) you won't find Ruby or Python differing by more than 10% in their total execution time.

Thirdly, while many claim that Ruby is "more OO" than Python because even the basic types are classes which can be inherited from, it's not that simple. First, Python provides UserList, UserDict, and UserString modules for those that do need to subclass a basic type (believe me, it doesn't happen often :)). Also, functions in Python are first class objects, whereas functions in Ruby aren't. You can argue about which language is "more OO" all day long, but there are points for each side, and at the end of the day, whichever helps you do more work, no matter how OO it is, is the superior one.

Python OO is, by the way, far more reflective than Ruby OO -- you won't find anything in ruby that's as flexible as python's getattr/setattr functions and __getattr__/__setattr__/__dict__ attributes of objects. Esoteric stuff like the Meta-Object Protocol is thus far easier to implement in Python than in Ruby.

Python has a more active user community in the US and Europe (though I hear Ruby has a more active community in Japan.) The standard library in Python is to die for, and much more extensive than that included with Ruby.

Features that don't affect me as much, but still played a part in my decision not to use Ruby: It's less portable than Python and the C interface is (in my opinion) not as cleanly implemented. Python has several implementations available, whereas Ruby has only one.

In short, Ruby and Python both have their advantages and disadvantages. I prefer Python (and feel that compared to Ruby is comes out way ahead,) but even if Ruby ended up slightly ahead after an objective evaluation, it would be hard to justify learning an entirely new language for the barely incremental increase in productivity.

Jeremy

[*]: Yes, those of you who know/have looked at O'Caml have seen its syntax, and probably noted that it's far worse than Ruby's. I can agree, however, O'Caml has numerous features to compensate: static typing, tail recursion optimization, blazingly fast native code compilers, support for several programming paradigms...the list continues. O'Caml has an ugly syntax, but in most cases (and definitely in O'Caml's case) syntax is a one-time cost, and O'Caml pays back that cost nicely.

PS.: If I'm wrong on any of the above points, please correct me -- that's what I've learned from a cursory examination of the language, I don't claim to know it in-depth.
--

Python

[Cheshire Cat]

Currently I'm using, and loving, Python. It has a very active and helpful community, plus tons of modules that come with the system. While I do like Ruby, it doesn't have the support behind it that Python does. Thats why I use Python, and not Ruby.

Answer is simple

[Billly Gates]

Politics.

If I were a boss I would be nervous to let a programer use a langauge like RUBY for a project. My fear would be that the employee would leave and no one would support the RUBY based app. I know this sounds stupid, untechincal and irrational in chosing a langauge but politics in the bussiness world is very important. I was reading a comment here a few days ago about slashdotter who needed a firewall solution. His boss chose an inferior solution over openBSD because the users and his boss was more familiar with the company name. Picking a political solution also looks good on my resume and to reports to directors and CIO's.

Second fear: what if the RUBY project turned out to be a diaster and nothing got done? MY boss and my boss's boss would like to know why in a detailed report. What would they think if they found out it was based on this so called experimental langauge called Ruby made by some hacker and not a corporation? I would not be employed for long if this ever occured.

Programming langauges are just as political as chosing a platform. I would encourage open source developers to increase the amount of projects based on ruby and if Ruby becomes more popular then it might be less risky for a Ruby based solution in the bussiness world.

I for one hate office politics but they are a fact of life and explains why MS is so popular.

The real question: Why Ruby?

[rknop]

The question to me isn't "Why not Ruby?" The question I would need answered is "Why Ruby?"

We've already got Perl and Python. Both scripting languages are quite powerful (way beyond what simple shell scripting can do). Both have strong communities behind them and are well supported. Both have a lot of programmers working on extentions and modules. And, importantly, both languages are open and free. Perl and Python are different enough in structure that they appeal to different people. Some like both, some like one or the other. I wouldn't want either language to go away; I don't want to see Perl "beat" Python or vice versa, since they are different enough in concept. There is a place for both of them.

But, given that we have Perl and Python as free scripting languages, and that both are powerful and supported, why do we need yet another? Mind you, I don't really know anything about Ruby; perhaps it provides something which Perl and/or Python simply can't. But unless it does, I simply don't see the point of having Ruby. If Perl or Python were controlled by a single entity (as is the case with C#, and even to some extent Java), I would see the point of having another language. But given that Perl and Python belong to anybody who want to have it belong to them, unless Ruby provides something they don't, there is simply no point to Ruby, so far as I can tell.

If you want a scripting language to do something, rather than writing a whole new one, I would say put your effort into writing a module for Perl and/or Python. The world will be better served by that. Again, all of this is unless there is something fundamental and useful about Ruby which Perl and/or Python simply can't do.

-Rob

because..

[PragDave]

• I already know a language, and it is perfect.
• I don't have time to learn something new.
• Someone once told me that a friend of theirs knew someone whose uncle said it was slow.
• It's new.

There are valid reasons not to deploy applications with Ruby. It doesn't (yet) have a library the size of CPAN. It doesn't (yet) own a stack full of books at your local bookstore. It doesn't (yet) have the performance of Java (although it is faster than Python in most benchmarks). That's why the people who currently use and love it tend to be more adventurous, and more forward looking. They believe that Ruby will be a significant language. In Japan, where there are a number of Ruby books, and where there is currently more Ruby support, the language has more users than Python.

So, a couple of years from now, we'll probably see Slashdot readers saying "but I already know Ruby, why should I switch to xxxx?".

In the meantime, the book Programming Ruby is available online. Maybe it's worth a look. You can download Ruby from ruby-lang. Maybe it's worth a play. You never know...