On Ruby

[jerith]

A programmer I admire greatly twittered the following today:
Dear Ruby haters: I used to be afraid of the table saw until I learned how to use it safely. This did not involve nerfing the table saw.
I have great respect for this man, but we have a fundamental disagreement about a language he uses by choice and I use by necessity. I have a bunch of

Comments

[chalain]

There's a refreshing backlash coming through the culture recently. I think the metaprogramming chickens are finally coming home to roost a bit, and people are realizing that pretty, unmaintainable code is just pretty unmaintainable code.

I have to agree with everything you're saying about the culture, however (even though I live in it and embrace it).

For me, nearly the entire allure of the language is the fact that nothing is set in stone. All of the tools are made of soft clay. If a bit isn't quite right, eventually skilled hands will grab it and reshape it, and if it's misshapen enough, then those hands can be mine, right here and right now.

[jerith]

A lot of my frustration with Ruby is that it's (in my opinion) the wrong things that are made of soft clay. There is a lot of cleanup required, and many of the fixes I would like (proper named parameters, like Python has, for example) are pretty invasive if not backward-compatibility-breaking.

"Static" metaprogramming is way too easy and "dynamic" metaprogramming is way too hard. I can easily reopen someone else's class and add my own things to it, but adding an arbitrary method at runtime (or even compile-time (insofar as Ruby has compile-time), as opposed to write-time) is messy and hard.

Community pressure against random use of method_missing() and such is a definite good thing and a move in the right direction. It's just not happening fast enough for my liking.

[chalain]

it's (in my opinion) the wrong things that are made of soft clay. There is a lot of cleanup required

This sentence has a very strong statistical correlation with trying to program other languages in Ruby. I felt exactly your pain a few years ago, and I lucked into running across (or perhaps afoul of?) a Ruby guru who took one look at my Ruby code and said "if you want to write C++, go write C++." Fortunately for me, he THEN said Refactoring such code can be instructive" and proceeded to reduce about 200 lines of my code to about 15.

adding an arbitrary method at runtime (or even compile-time (insofar as Ruby has compile-time), as opposed to write-time) is messy and hard.Hmm. I don't experience this pain. Can you give an example? You know that adding methods to Kernel add globals methods, right? I actually wouldn't use that method much; I would much rather constrain the method add to a helper class that the code downstream from me could expect to use. That way, for example, a method to help the view code isn't unnecessarily visible

[jerith]

This sentence has a very strong statistical correlation with trying to program other languages in Ruby.

This is possible. For a long time I tried hard to write Python in Ruby, but I think I'm pretty familiar with the idioms these days.

adding an arbitrary method at runtime [...] is messy and hard

I may be heading down the wrong path, but the last time I wanted to write a method that added another method to a class, I had to use module_eval(). Here's a silly example of an extensible RPC class:

class MyClass
def self.client_api(name, *args)
module_eval(<<-End, __FILE__, __LINE__ + 1)
def #{name}(*myargs)
remote_call("#{name}", #{args.inspect}, myargs)
end
End
end

def remote_call(name, argnames, args)
str = "Remote call: #{name}("
str += argnames.zip(args).collect { |k,v|
"#{k}=#{v.inspect}"
}.join(", ")
str += ")"
puts str
end

client_api :sum, :operands
client_api :difference, :lhs, :rhs
end

foo = MyClass.new
foo.sum([1,2,3])
foo.difference(7, 3)Apart from the

[kazriko]

For some reason, I just had a nasty flashback to the days of Perl with your table saw analogy.

This leads me back to the whole pendulum theory of computer languages. It swung way over to Java for its nice safe code, then way back over to Perl as a response to the unpleasantness of so much safety, then back to Python as a response to the unpleasantness of that power combined with such chaos... Then back to Ruby as a smaller swing...

TIMTOWTDI vs. OOWTDI I suppose.

[ext_90136]

This is very similar to the way I feel about PHP. People curse it all the time because it's possible to make such a big mess in it but then they miss the sheer brilliance of the platform in so many ways. It is really good for developing web applications fast (tried and tested), has a lot of cool features and can be really clean if used correctly.

[jerith]

PHP has many similar issues, only far worse. The PHP standard library is a mishmash of different styles, different functions doing the same thing, broken stuff, semi-broken stuff and misleading stuff. The one thing the Ruby community does have that makes up for a lot of what is missing or broken is a strong culture of unit testing and tools to support it. Last time I wanted a unit test library in PHP I spent about a day looking for one, found three different broken ones and eventually gave up and wrote my own.

It's possible to write good, maintainable code in PHP (Drupal, for example), but it's difficult. Ruby (the language and the community) is maturing and cleaning up its act. PHP isn't.

(If you want a long litany of things I consider broken in PHP, buy me a beer at the next GeekDinner and I'll keep you busy.) ;-)