I went to a Ruby Meetup the other day, where DHH attended. I didn't talk a whole lot (at least, I don't think I did); I'm a Python programmer, and I didn't want to intrude, so I mostly listened.

If anything, I came away feeling even more that Ruby and Python are alike. Not just at the language level, but at the community level as well -- especially when you take away the syntax and other particulars (and people talk with neither begin and end, nor significant whitespace, so all those particulars are gone in conversation).

David had actually read my last post on Rails and we talked about it a little. One thing he cleared up for me is that templates and helpers are not mixed into the controller, so helpers aren't a way of creating private methods, but a way of giving templates access to code. The confusing part, for me, is that Rails copies all the instance variables from the controller over to the template, so the template appears to be the same object as the controller, even if it isn't.

Another thing that people talked about a lot of Ajax (DHTML), which everyone was very excited about. During their discussion of Ajax, one advantage of their "partials" (HTML reuse by composing multipe templates/files) is that these same bits of partial content are used heavily for the Ajax portions -- a typical Ajax request in Rails sends something to the server, and the server rerenders the content of a <div> and sends it back. So in many cases the partial is rendered in isolation and delivered in isolation (then put in place by assigning to innerHTML). I still think it's an unpleasant way to reuse HTML, but this unexpected benefit might change that. I guess it's a move towards page-as-widgets, which has never attracted me before, but Ajax does really change that.

My ASP comparison came up again. Anyway, in that case he explained that he didn't want people to think that Rails had an execution model like ASP, where the URL points to a template, and so forth. I just meant ASP in terms of template syntax, to clarify.

And lastly, on the Rails topic, there's a a complaint I forgot last time ;)

This code from the to-do tutorial shocked and surprised me:

if item.save  # Try to save our item into the database
  redirect_to(:action => "list")  # Return to the list page if it suceeds
else
  render_text "Couldn't add new item"  # Print an error message otherwise
end

I've just been dealing with some Perl CGI code, and one of the things that drives me nuts is how the code -- not horrible code, mind you -- just ignores all sorts of errors (usually causing things to fail at a later point in time). If something isn't successful raise an exception. The only time not to do this is if the function has no side effect and has indication of success/failure as its sole purpose. This does not describe a database save.

Anyway, that's all on that.

Ultimately I'm left unsatisfied. Like all occassions in the past when I've looked at Ruby, I'm left feeling mystified. There's room for multiple languages, but Ruby and Python are so similar, and only seem to become more similar with time. Not just technically, but culturally as well. Sometimes I think people have choosen Ruby because it is less popular, because green field work is more exciting, because they can have a larger influence on the community. I wish them well... but now that they are putting up a real fight for mindshare I at least plan to meet them head-to-head, and leverage all of Python's strength that I can. I don't see any reason to snipe Rails users -- you could do a lot worse than Rails, and that's not a group ripe for conversion -- but I won't let them define themselves as the Next Big Thing in web programming without a fight.

Well, that's a good segway... so, the topic of Rails clones came up at the meetup. David felt that the clones weren't taking the right approach by using pre-existing components, as Subway and Trails are, that they should have rewritten things from the ground up. Of course, this really would put them on level ground with Rails (except a year behind), which is why the authors chose not to do that. People seemed skeptical that anyone could achieve what Rails achieved without total integration and design (and redesign) of multiple components in concert. (For Pythonistas -- we're not talking Zope-2-like integration here, since Rails is heavy on testability which discourages explicit coupling.)

Personally I don't buy that, but I'll let you all think about that on your own.