Hacker News Reader

Comment by stevekl | Hacker News Reader

I always have a mixed feeling about ruby. The "magic-ism" of ruby is something that I just cannot deal with.

"require" gives you methods that appear out of nowhere (unlike other language where they are name spaced), method call without perens (so what is an attribute, what is a method call)

All of these look nice at first but kills maintainability later

View on HN

> method call without perens (so what is an attribute, what is a method call)

That's known as Uniform Access Principle[0] and is a wonderful feature to have.

Ruby is far less magical today than it was 5-10 years ago. Magic is a clever word for "I don't understand this thing yet."

0 - http://martinfowler.com/bliki/UniformAccessPrinciple.html

Disregarding the UAP thing you mentioned, I believe you might be dismissing the complaints of "magic" in Ruby too quickly if you think all it is meant by it is what you said.

In the contexts I usually see, the complaints of magic are regarding Ruby's fondness of Spooky Action at a Distance. I would then argue that Ruby or its frameworks do seem to rely too much on this "magic" that otherwise is condemned by recent literature (and Code Complete).

I think the discussion is really about Rails, not Ruby. Ruby itself is fairly minimalist and easy to follow. Probably the biggest legitimate complaint about the language design itself is that it mixes functional, procedural, and object-oriented paradigms in a way that makes it hard to fully capture the benefits of any of them unless you really know what you're doing.

Now Rails on the other hand relies on a good deal more magic than say Django, but it's recognized in the community as a tradeoff and it is done carefully. Some of the things that rubyists accept in Rails they would never put in an application or library because it is deemed okay only by massively adopted convention at the framework level, but not generally a good practice.

Then you have libraries like rspec which started out being full of magic but which gradually got refined and cleaned up so that in rspec 3.0 you have zero monkey patches; it's just pure ruby, providing a totally modular set of DSLs that work together nicely and allow for amazingly readable test output.

> so what is an attribute, what is a method call

It's all method calls. Attributes don't really exist.

Well, they sort of do, in the form of instance variables.

Ish. In the context of the GP's point, they aren't a problem because the syntax to access them is distinct.

> It's all method calls.

Probably nitpicking, but it's actually all messages. An object might not have a method "foo", but happily respond to the "foo" message.

And the object responds to the "foo" message by calling a method.

The difference is whether we're discussing the invocation or the response. OP's usage of method isn't incorrect in this case if it's discussing the response. It is true that all message responses (including accessors) are implemented using methods.

> It is true that all message responses (including accessors) are implemented using methods.

An object can respond to a message even though it doesn't have a method with that name. A classic example are Rails' dynamic finders:

  User.methods.include?(:find_by_name)
   => false
  User.respond_to?(:find_by_name)
   => true

> An object can respond to a message even though it doesn't have a method with that name.

Sure, by using a different method (method_missing); its still all method calls.

Yes and the responses are implemented with methods. Always.

Its all method calls. Specifically, its all calls to #send, most of which get relayed to another method (either based on the message name or, if no such method exists, #method_missing.)

I believe he meant local variables (or if he didn't he should have).

> "require" gives you methods that appear out of nowhere (unlike other language where they are name spaced)

I always worry about this too, but in practice I've rarely run into a namespace collision (I can't even remember the last time it happened.)

Reply on news.ycombinator.com