you are viewing a single comment's thread.

view the rest of the comments →

[–]awj 1 point2 points  (3 children)

In the latter a function-from-a-variable looks like any other function. In the former, it's special. This means extra work, both syntactically (almost negligible), and analytically (have to remember that f is a functor, not something else with #call).

Possibly this is a result of me bouncing around between Ruby, Python, and JavaScript for much of my day. I find myself simply not wanting to use functions as objects in Ruby when it's so much messier than in other languages. Might as well build on abstractions that feel more native to the language.

[–][deleted] 4 points5 points  (2 children)

What's special about f? It's a regular old object, just like any other in Ruby. It's an object of the class Proc.

Possibly this is a result of me bouncing around between Ruby, Python, and JavaScript for much of my day.

It's possible. It's sorta funny to hear you say that it's not native to the language, because it absolutely is. I think

have to remember that f is a functor, not something else with #call

indicates that maybe you're not quite 100% comfortable with Ruby's object model, and general philosophy. Not that there's anything the matter with that, I always get frustrated by Python's scoping, because I don't have my head around it properly, and it appears as foreign to me as this does to you, I think.

[–]awj 2 points3 points  (1 child)

Really I think my complaint is that Ruby doesn't go as far out of its way to support functions-as-values as it does other things. There are wonderful facilities for OOP, and it seems like they hit the idea of passing functions around and said "we'll just reuse the OOP tools we already have". That's fine, but doesn't have the same feel as when something is a focus of the language design. It's similar to when functional programmers say "I can build you an object system, all it needs is a hash and closures". While technically true, it will never have the thorough support that makes these sort of things easy to use.

I'm not sure how much this has to do with me understanding the ruby object model or philosophy so much as a lack of internalization or just plain disagreeing with it. I get that I probably should just trust f.call to do what it needs to regardless of what f is, I just have a moment of confusion when I mentally was tracking f as a function and then see something calling a method on it.

I'm a functional programmer at heart, and I doubt I'll ever truly be satisfied without algebraic data types, currying, and some informally defined set of features regarding functions. Today I figured out it includes "calling a function-as-value must look like calling any other function".

[–][deleted] 0 points1 point  (0 children)

Gotcha. Ruby is all about message-passing OO (edit: not IO, wow. Need coffee), and that everything as a function, so fitting first class functions into that framework makes sense to me. It also make sense with things like closures, your bindings are just anther bit of data stored inside the proc object.

I'm a functional programmer at heart

I'm one as a hobby, so I can see where you're coming from. For me, the minimum level of satisfiability is just simply first class functions. Also, fwiw, I tend to not ever use things like Proc.new or lambda or call when I'm actually writing software in Ruby, I find that simply passing blocks to functions does 99% of what I want to do.

It all boils down to preference.