Live data from Hacker News

Ruby adds experimental support for Rightward assignments

blog.saeloun.com

31–39 of 39 posts

Re: Ruby adds experimental support for Rightward assignments

#31
post #23

Is there a place we can voice our concerns over this move. I was just teaching Ruby to someone learning to code. I have to admit because all popular languages use leftward assignment it was one less thing to teach. => is pretty loaded as it is

Agreed. And it doesn't really improve anything. The argument that it makes code easier to read is bogus. Perhaps for people who only work in ruby. I suspect rubo-cop would have a rule against this a week after it was added.

Re: Ruby adds experimental support for Rightward assignments

#32
post #22

Doesn't this introduce an ambiguity? def foo(*arg, **kwarg) puts "#{arg}/#{kwarg}" end b = 'meh' foo(:a => b) Now this produces []/{:a=>"meh"} But with right-assign [:a]/{} ?

Oh. The bugs that this would produce. And spotting it visually would be killer

Re: Ruby adds experimental support for Rightward assignments

#33

To me this seems like a clear loss. The syntax is (as far as I can tell) strictly more verbose than the existing assignment syntax. Ruby is already plagued by a million-and-one ways to do everything, but at least in other cases simplicity (à la zen of Python) trades off for brevity.

+ 100

Re: Ruby adds experimental support for Rightward assignments

#34
post #8

Earlier quoted context omitted.

At the expense of increasing the complexity to read code.

How is the complexity increased?

It's actually very simple to illustrate. Say this 5 => x in english. (three words or less)

Or this one

cat => person.pet

Re: Ruby adds experimental support for Rightward assignments

#36
post #8

Earlier quoted context omitted.

How is the complexity increased?

As you read through code you can come across a huge switch and not know why until you look to the end. Now you’re reading bottom-up, which is just as unnatural as right-to-left for english speakers. Not necessarily more complex, but not less complex either IMO. I often say complexity can’t be eliminated, only spread around differently; I think we’re seeing that here.

I think it would be possible to think of this in terms of complexity theory, for N case statements to you would possibly have to check 2N locations for assignment. I wonder if you could do parallel assignment: var1 = case = var2

Re: Ruby adds experimental support for Rightward assignments

#37
post #24

Why do most languages use right-to-left assignments? Is it purely a matter of path dependence? I guess also that binding a value to a name usually indicates that you'll use the name later on, and having the name on the LHS makes for a better UI for looking up the value the name is bound to. On an unrelated side note, I've always thought "=" was a huge mistake in language design, confusing countless people who are com…

"=" is still equality. It's not an operator that compares two values. It's an operator that defines the left hand to be equal to the right hand. I feel like "=" for assignment is fine. For boolean comparison something like "=?" seems most clear, like asking a question whether the left and right hand side are equal.

Re: Ruby adds experimental support for Rightward assignments

#39
post #24

Why do most languages use right-to-left assignments? Is it purely a matter of path dependence? I guess also that binding a value to a name usually indicates that you'll use the name later on, and having the name on the LHS makes for a better UI for looking up the value the name is bound to. On an unrelated side note, I've always thought "=" was a huge mistake in language design, confusing countless people who are com…

"=" is still equality. It's not an operator that compares two values. It's an operator that defines the left hand to be equal to the right hand. I feel like "=" for assignment is fine. For boolean comparison something like "=?" seems most clear, like asking a question whether the left and right hand side are equal.

In imperative languages, assignment has a side effect of making the LHS equal to the RHS. But it's still different from equality, since variables can be reassigned

E.g.

    a = 2
    a = 3
    2 = 3 //what???
Assignment is fundamentally part of the language execution model, which is entirely apart from anything related to mathematical equality. Even in languages where you can't rebind a variable name, it's still weird to use = as assignment, since it would have such different behavior than seemingly analogous operators like > and <.
Post reply on HN