Discussion on: Ruby as elegant as ballet

View post

As a die-hard JavaScript fanboy, I have to admit that Ruby holds a very special place in my heart as the most strictly beautiful language I have ever written. It's a perfect balance between the magic and brevity of Perl (an old school scripting language that many command line hackers swear by, known for being magic to a fault for anyone not super familiar with it) and the structure of object orientation. I agree with a lot of your points!

Just one really minor note I wanted to drop, since you said you're new to JS: you can in fact write that addition function without areturn! If you leave off the curly braces, you don't need it:

const addition = (a, b) => a + b

The main limitation is that you only get one expression in this form, a limitation that Ruby does not have. I am on the fence about the always-return-the-last-expression method that Ruby uses; on one hand, it's super expressive and saves some characters, but on the other hand, it's a little less clear in some cases, and you don't always want a function to return a value. Idk, I honestly sort of like the explicitness of "hey reader, here's the thing I'm returning, right here!". What do you think?

Tyler • Nov 17 '20

Hi Ken,

Thank you for your time and reply. I agree that it's a bit less clear when there isn't a return keyword but in Ruby you can add return in your function and it would function same way as not having it:

def addition(a, b)
   return a + b
end

But if you already know that return keyword isn't necessary, why erode your fingers on the keyboard and read an extra word on your code ? :)

Ken Bellows • Dec 1 '20

Sure, I know it's possible, but it's not the common idiom in the Ruby community. And like I said above, my main worry with the always-return-the-last-expression idiom is that it can sometime be a bit less clear what's going on. In particular, I have seen (and occasionally been confused by) code like this:

def complex_business_logic(some_arg)
  if (first_condition(some_arg))
    some_arg.some_method()
  else
    x1 = do_something_else(some_arg)
    do_another_thing(x2)
    and_another_thing(some_arg, x2)
    #
    # many more lines of complex business logic here
    #
    # lots of indentation an loops and conditional branches
    #
    # so logic wow very enterprise many code
    #
    # ...
    #
    # ...........
    #
    final_result
  end
end

I have seen code like this, the point being that the vast majority of the code happens after the first possible return value, only utilized if the first conditional passes. In these cases, I have sometimes had a hard time tracking down where exactly the returned value is coming from, just because the structure of the function obscures it. It seems to me that there's no easy way to visually scan a function and see quickly all of the possible return points. Conversely, in a language that enforces the return keyword or something similar, I can always just Ctrl+F for the word "return" ad find them all (or just look for that word.

Now obviously, there are two clear objections here. First, this is probably not the best way to write code, and it should probably be refactored into some smaller, eaasier to digest helper functions. However, this sort of code does in fact exist all over the place in the wild, so it's still a problem. And second, probably the bigger one, I am by no means a pro Ruby developer. I'm sure that very experience Ruby devs have a much easier time picking out the return points in complex functions. And, fine, I get that, there's stuff like that in any language. I still see it as a barrier to new community members, but again, every language has those.

Idk, it's not a huge problem or anything, and I actually did like working with it when I wrote Ruby years ago; just something I wonder about at times