Ruby’s not ready: comments, corrections, and clarifications

Some good discussion on this one. It’s nice to see Ruby people saying things like this (5th message from the top, from Song Ma):

Interesting. But what I am thinking about is not the attitude of the author, but the points he was trying to make. The deep review and discussion will benefit the language insights.

Or this one (from Trans, on the same forum):

Why is everyone getting so worked up? It’s a critique. Biased it may be, but that in itself does not make it worthless. In fact, it can be very constructive b/c it uncovers “attack points” with the language. With each point we can ask ourselves objectively is this a misconception or a fair point? In either case we have an opportunity, to address misconceptions in our Ruby evangelizing blogs and to work to improve Ruby where a point has merit.

Bias can work both ways. But I think the Ruby community can rise above it, and Ruby will be all the better for it.

And from Peter Cooper at Ruby Inside:

As it is, I think he’s missing the point a lot of the time (he tends to think Python’s better because he likes its conventions more than Ruby’s – not a compelling argument), but it’s an interesting read none the less. Anything that keeps our minds open to the fact that Ruby != perfection is worth a look.

And a comment on the same post:

Let’s take his best points and incorporate them into future versions of Ruby.

Sounds like a plan.

I saw a few counterarguments like this:

Everything he’s saying is well known.

Just because a problem is well known inside a community doesn’t make it any less of a problem.

Everybody who mentioned documentation, even those who disagreed strongly with the rest of my post, agreed that Ruby’s documentation is seriously lacking. In fact, a lot of the mistakes in my original post are due to me not being able to easily find an explanation of something on the various Ruby doc sites. Which leads me to…

Corrections

ranges and slices

I was wrong about Python’s xrange being comparable to Ruby’s .. ranges. If you create an xrange object in Python and then use in to see if a value is in the range, Python iterates to find the range. Ruby’s ranges are smarter, and therefore faster, in this case. Also, someone pointed out a cleaner way to test if a value is in a range:

range.include? value
require and load

Contrary to what I wrote, require and load do search a set of paths for a module. And load has a way to prevent the loaded file from affecting the name-space of the loading program, and I’m glad I was wrong about that. I was misled by the require-farm recipe post that I found, and should have checked the docs more thoroughly. It also appears that require does what it does by calling into load (because the docs for require point to the docs for load). So I’m still confused about why Ruby needs both.

to_s and to_str

Henrik Nyh graciously emailed to tell me that Ruby’s Object#inspect is the equivalent of Python’s repr(). Thanks Henrik. My bad.

print, puts, and p

On Reddit, someone pointed to the documentation for print, p, and puts. I was wrong about these not being documented — I just totally failed to find the docs for them.

According to the docs, the difference between them is just in how they handle arguments. But my question stands: Why does Ruby need all three?1

merge is different from update and merge!

Someone else on Reddit pointed out that:

update is destructive. merge is not.

And they’re right. I completely missed the existence of ordinary merge, because I clicked on update first, instead of on merge, in the Hash docs. And then I left off the ! when I wrote it up. My fault. update and merge! are the same, and merge is the non-destructive version. I’m not sure this makes me feel any better about TMTOWTDI, or the state of the docs, though.

PottyMouth

There was a bit of feedback from people who’d looked at the source of the Ruby port of PottyMouth, so I was able to make it a bit more Rubyish, and roll a new version. It still uses it’s own homemade unit test code, but then again, so does the Python version. Thanks to everyone who checked it out.

Quick clarifications

I never claimed to be providing an “expert” (Last 100 Meters) or “in-depth” (Reddit) review of Ruby. I’m not. Lots of people quote me as saying “TMTOWTDI is bad” without including the rest of the thought. And nowhere do I say that Ruby sucks; I don’t think Ruby sucks. (I have no problem calling out things that suck when I see them.) For example, Ruby and Rails both run circles around PHP, which does suck.

Comments

There are a boatload of comments on the series o’ tubes: Ruby forum, news.YCombinator, Reddit, del.icio.us, and Ceejbot (If I’m missing one, email it to me).

And finally, I’ve found a totally awesome new web framework that makes both Pylons and Rails look like pathetic toys. Oh yeah.


  1. The printf and pp  methods, also in Kernel, would bring the total of print-like methods to five. Except that pp and another method, pretty_inspect, despite being documented, don’t actually exist in the language — neither 1.8 nor 1.9. Huh? []