I agree that it may be _annoying_ for a programmer to invoke a Proc object using #call but I cannot see how it is _inconsistent_. In fact it is Ruby's insistence _on_ consistency that results in the slightly inconvenient #call syntax in the first place.

As you acknowledge yourself, a Proc is an object and so is 'invoked' by sending it a msg. In Ruby the `()` operator cannot be overloaded and so the #call message is used instead.

What you are asking for, essentially, is that Ruby allow the '()' operator to be overloaded but _this_ would result in inconsistency as the '()' would then be mandatory when invoking Procs (and other user-defined functors) but not when invoking methods.

It just doesn't make sense to allow overloading of the '()' operator in a language where parentheses are optional.

Further, Common Lisp, a language you mention a few times in your talk, works in a similar way. Anonymous functions in Common Lisp cannot be invoked like 'normal' functions and must be invoked through a similar 'call' mechanism: (funcall my-lambda args ...).

I'll grant you your point on &:symbol (I use it sometimes, but it does still feel like a clever hack)

;)

No no no, you're confusing 'Method Objects' with 'methods'.

A Method Object is a method wrapped up into an object so it can be passed around.

Method Objects _cannot_ be invoked without using #call, they have an almost identical API to Procs, see:

class HelloClass
def hello; puts "hello"; end
end

m = HelloClass.new.method(:hello)
m() #=> error, no method 'm'
m.call #=> "hello", this actually invokes the Method Object

A 'method' itself is not an object, rather it implements the behaviour OF an object.

A 'method' _cannot_ be said to be an instance of the Method class. It is only when you call the #method(method_name) that the 'method' is wrapped up into a Method Object.

Ruby is entirely consistent here - NO objects support the '()' operator, and methods are _not_ objects. The only way to invoke functors (Procs, Method Objects, and so on) in Ruby therefore is to explicitly send a message. In Ruby 1.8.6 the messages are #call and #[] and in Ruby 1.9 you can use #.().

Also this duality of 'methods' and object-wrappers for methods (when the method needs to be passed around) is not at all unique to Ruby. Ruby inherited this from Smalltalk, and IIRC, Scala works in the same way.

The only point of difference being that in some languages the '()' operator can be overloaded and so the distinction between 'method' and 'wrapped method object' is harder to perceive.

But the point is that 'methods', in Ruby, are _fundamentally_ different to Procs and so conflating them together as 'callable objects' is misgsuided (This is a result of the object oriented model Ruby uses, one shared with Smalltalk and Scala among others)

This is different to the case in Python where AFAIK methods, functions, and lambdas really are just different kinds of 'functions' and so thinking of them together in this way as 'callable objects' makes more sense.

In Ruby though, there is no unifying idea of a 'function' there are instead 'methods' and Procs (et al).

The distinction between the two is that 'methods' are executable code bound to the state of an object but Procs are _objects_ that wrap 'free' code. These differences (esp. the fact that one is a full-blown Object and one is _not_) are so fundamental IMO that convolving the two ideas into a single notion of 'callable object' and then complaining about lack of 'consistency' is wrongheaded.

Another issue altogether is whether, despite these fundamental differences, you can nonetheless provide them with the same interface. Scala (which also makes a similar distinction between methods and 'function objects') _does_ allow overloading of the '()' operator and so the interfaces are the same. Ruby, on the other hand, does not allow overloading of '()' and so the interfaces are different. This does _not_ mean that Scala is more 'consistent' than Ruby, it just means, on this particular point, that Scala is arguably more aesthetically pleasing.

As I've stated before, it is because parentheses are optional in Ruby that the '()' operator cannot be overloaded. I agree that this results in slightly annoying #call syntax when invoking Procs but I think overall it is a win for Ruby's elegance. Personally I do not mind having to type #call to invoke a functor if what i'm gaining in return is an API with the beauty and elegance of Rake or Sinatra.

Also, as I said before, having to use a call mechanism to invoke an anonymous function is not unique to Ruby, Common Lisp also works like this and I do not recall anyone calling CL 'inconsistent' on this point.

All I really took issue with was your use of the word 'inconsistent' in describing the Proc#call syntax. There is no inconsistency (as I've been at pains to demonstrate).

However it seems you now hold the more innocuous view of "The two languages have different design aesthetics; that's all. Nothing is wrong here.".

If this is the view you now hold, then we are in complete agreement. :)

@Richard, Gary and I were not arguing about the 'consistency' of Ruby in general but specifically about the Proc#call syntax.

Nonetheless though that article makes some interesting points (esp. regarding the lack of multiple blocks) I really think the author is a bit hysterical. It is true there are some subtle differences between Procs, lambdas and blocks, but the situation is not nearly as byzantine as the author makes out. In my opinion most of the content in that article could be compressed to about 6 lines of code.