Ruby's parser is notoriously complex; if I remember correctly, only a few members of the core team even know how to maintain it without introducing regressions.<p>The craziest part of this is that Ruby does not provide a full featured Ruby parser, so its entire static and dynamic analysis ecosystem depends on a (actually very high quality) 3rd party parser, begrudgingly maintained by someone who (AFAIK) doesn't even write Ruby anymore: <a href="https://github.com/whitequark/parser" rel="nofollow">https://github.com/whitequark/parser</a><p>When I see new language features like this, I think of how Ruby's entire tooling ecosystem depends on the dramatically underfunded (and therefore primarily goodwill) efforts of high output maintainers like whitequark and a few others. Ruby's highly dynamic and untyped nature means these tools are all the non-runtime guarantees you can get, basically. Epitome of digital infrastructure.<p>Consider asking your company to fund some of these people:<p>* <a href="https://github.com/whitequark" rel="nofollow">https://github.com/whitequark</a> (maintains parser)<p>* <a href="https://github.com/sponsors/bbatsov" rel="nofollow">https://github.com/sponsors/bbatsov</a> (maintains RuboCop)<p>* <a href="https://github.com/sponsors/mbj" rel="nofollow">https://github.com/sponsors/mbj</a> (maintains unparser and mutant)<p>---<p>As context, I know this stuff intimately because I used to contribute heavily to most static and dynamic analysis tools in the Ruby ecosystem (<a href="https://github.com/backus?tab=overview&from=2017-12-01&to=2017-12-31" rel="nofollow">https://github.com/backus?tab=overview&from=2017-12-01&to=20...</a>) and used to track new ruby changes really closely: <a href="https://cognitohq.com/new-features-in-ruby-2-4/" rel="nofollow">https://cognitohq.com/new-features-in-ruby-2-4/</a>
This hurts readability of code with lengthy expressions. Knowing the target of the assignment is usually more important than the particulars of the expression when you're skimming unfamiliar code. Having the variable pushed out to random locations on a ragged right side isn't helpful.
To counter some of the complaints regarding readability, a major use case for this is simply hacking stuff together in the REPL. Sometimes you notice you want to have your result as a variable when you've just typed a line, and other solutions for this problem (Ctrl+A or ENTER plus foo = _) are not universal.<p>Disclaimer: I'm not a core dev but saw a discussion amongst them about such use cases.
> While the above pattern has become standardized, it feels somewhat unnatural as we read most of the spoken languages from left to right.<p>Is this true (the 'unnatural' part)? Reading left to right, `age = 42` can be read as "age is 42" which feels perfectly natural in English. `42 => age` would be read as "assign 42 to age"? This feels more awkward to me. I'm not sure I understand why anyone would want Rightward assignment.
I love Ruby. I've been working with it as my primary language for 15+ years.<p>Its sad to see how they keep adding new, arcane syntax for fairly obscure use cases, seemingly without any real clear justification. I wish Matz would raise the bar on these changes - Ruby is mature and already has a very powerful, complicated syntax that gets tricky for corner cases. I appreciate "more than one way to do it", but not everything needs to have ten ways to do it when the first three ways work fine.
Well, this is a nice coincidence, Nim also added support for rightward assignments today!<p><a href="https://play.nim-lang.org/#ix=2x7r" rel="nofollow">https://play.nim-lang.org/#ix=2x7r</a>
Here is a feature ticket. The usage in a data transformation pipeline feels right and appropriate as in comment #20 <a href="https://bugs.ruby-lang.org/issues/15921" rel="nofollow">https://bugs.ruby-lang.org/issues/15921</a>
The right way to do this is the way Prolog does it.
It doesn't matter if you say VAR = 12
or 12 = VAR or 1,2,10 = A, B, C
It does whatever it takes to make the left and the right sides equivalent to each other.
Rightward assignment is pretty strongly discouraged in the R community, due to the effect it has of burying the lede. That said, I always felt the same about Ruby’s inline if/unless (`puts "still working" unless done`) so maybe it will have a better reception in this community.
I'm also not a fan of spending this syntax card on this feature. The ... => ... syntax might be needed for something more useful in the future.
More HN discussion on this topic from 6 days ago: <a href="https://news.ycombinator.com/item?id=24369892" rel="nofollow">https://news.ycombinator.com/item?id=24369892</a>
Uh.. I'm not sure I like this, in a language that already has a similar boolean operator (although I suppose that goes for all uses of such "arrow" operators). But still:<p><pre><code> a = 2
b = 1
b >= a # false
b >= a => a # assign false to a?
b => a # assign 1 to a?</code></pre>
Is this really just syntactic sugar? None of the examples in the article seemed to show why code would be more readable (array assignment maybe, but the leftward seems just as readable).
I'm sorry but this "feature" is yet another design a hacker living in a bubble came up with. Most people think and program in English, or languages very close to English. In English I can read let x be 4ys and some change. I don't know how to read the arrow. 4ys and some change implies x? If this is a feature designed purely for speakers of SOV or OSV order languages like Japanese, that's fine, but the dominant language in technical discourse isn't one of those.
So, a = b becomes equivalent to b => a.<p>However, you already construct hashes like hash = {:a => b}.<p>Perhaps we can also add reverse hash construction like hash = {b = a} for consistency (and additional madness)
This is true to Ruby's Perl heritage. There is more than one way to do everything, even the most basic of operations.<p>Quiz: what does the following Ruby code do?<p><pre><code> a = b => c = d</code></pre>
This would be nice for situations where you have a lot of method calls daisy chained together. Like builders or Java Streams.<p><pre><code> DoThing()
.withSomeOtherThing()
.onSundays()
.withCharset(Blah.BLAH)
.betterAddThis(x -> { ret stuff() })
.build()
=> turducken
</code></pre>
The whole assembly of the variable 'turducken' is drifting rightward. By the end we want to get to the point rather than backtrack.
I expected this new feature to use the -> token but they went with => instead.<p>Is there any reason why they overloaded the hash rocket? Even the simple examples in the article look like somewhat malformed hashes to me!<p><pre><code> 3 => box_height
[170, 65] => height, weight
traits => height, weight
</code></pre>
How does the parser tell them apart?
Ugh! I love that Ruby is expressive but this will just add confusion when a developer moves to Ruby for the first time. It adds a mental burden to be aware about all these rules.
i was kinda shocked to see all the negativity in this thread. i looked at this post and thought 'beautiful' and kinda mind-blown at the simple elegance of it. ruby is one of those languages that was cutting edge in 1995 and is apparently cutting edge today. it writes and reads like nothing else. it can be made very, very, or too terse, but it can be made to read simply and concisely and clearly with an economy of characters spent. i also am not a huge fan of the metaprogramming madness. but ruby is a beautiful language and i definitely<p><pre><code> 'think highly' => sentiment
</code></pre>
this post.
I wish they pay more attention to real issues and potentials. e.g. The Refinement design is half-baked -- Can't refine module methods, can't DRYly reuse monkey patch code as refinements...
>R language also has a similar way of doing this 42 -> age.<p>Ah yes, the R language, a model of clarity, beauty and lightness in the world of programming languages. Truly an example to follow.<p>(And it's not like anyone ever uses that "feature" in the R world either.)