Live data from Hacker News

Ruby adds experimental support for rightward assignments

blog.saeloun.com

151–160 of 172 posts

Re: Ruby adds experimental support for rightward assignments

#151

I expected this new feature to use the -> token but they went with => instead. Is there any reason why they overloaded the hash rocket? Even the simple examples in the article look like somewhat malformed hashes to me! 3 => box_height [170, 65] => height, weight traits => height, weight How does the parser tell them apart?

> Is there any reason why they overloaded the hash rocket?

The fact that it's used for a kinda similar purpose in rescue clauses is a factor.

> How does the parser tell them apart?

Unbraced hashes can only occur in last-argument-of-function position, so unless it's naked (not a parenthesized subexpression) in that position, it can't be an unbraced hash.

Re: Ruby adds experimental support for rightward assignments

#152
post #31

Earlier quoted context omitted.

synonyms in ruby seem to be a mistake. Searching code for certain usage patterns ends up needing more complicated regular expressions taking into account all synonym variations. If you've seen a method one way many times while learning, then see a synonym, you end up having to search up docs to make sure there isn't some subtle difference.

There almost invariably is a subtle difference (very commonly, in precedence), and that's usually a key part of the motivation for the (near) synonym.

That makes it confusing when there isn't a difference (I think map and collect?).

Re: Ruby adds experimental support for rightward assignments

#153

Earlier quoted context omitted.

Ah, and templates are a rewrite engine on the AST! That completely slipped my mind. So the compiler itself just sees the `a = b`, the `b => a` is never visible, therefore precedence isn't germane to the template itself. Neat.

> So the compiler itself just sees the `a = b`, the `b => a` is never visible, therefore precedence isn't germane to the template itself. Not quite. Imagine you have: 3 + b => a Is that 3 + a = b, or a = 3 + b? Precedence still comes into it. (I don't know nim's solution.)

Hmm no I'm pretty sure in a template it's, ok I'm going to use different variable names for clarity:

3 + c => d

the left hand side (3 + c) is b, and the right hand side is (d) is a, and this will apply no matter what you put on those sides, so it's rewritten in its entirety before the actual compiler sees the code.

Unless you're talking about a scope violation/dirty macro situation? And yeah I don't know Nim's story around hygiene either, but: it's usually only a problem with Lisp macros, exactly because of the homoiconicity. I'd wager Nim templates have their own scope that won't shadow the rewrite.

Re: Ruby adds experimental support for rightward assignments

#154
post #6

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.

One of Ruby's philosophies is to provide multiple ways to express the same fundamental operation so that it can conform to your thoughts instead of forcing your thoughts to conform to it. You can still do it the old way where it makes sense. Whether this philosophy is helpful or harmful is another debate.

> multiple ways to express the same fundamental operation

Sounds like the timtowtdi of perl. Funny, I've always called ruby "perl++".

Remember how perl is known to be readable?

Re: Ruby adds experimental support for rightward assignments

#155
post #72

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: a = 2 b = 1 b >= a # false b >= a => a # assign false to a? b => a # assign 1 to a?

I forgot one, or two:

  b  b # assign true to b?
I'm not too thrilled about the hash-arrow - but I think it's a bit more obvious from context.

Re: Ruby adds experimental support for rightward assignments

#156

Earlier quoted context omitted.

> I don't know how to read the arrow. As a description (which is an easier translation of this idiom into English than an imperative) “is assigned to”. Imperatively, English tends to prefer verb-object with implicit subject, so we ought to be using a Lisp family language (setq “foo” 42) maps better to English imperative structure than most popular languages that do imperative assignment.

Complete English sentences in present tense are infix, with the subject and object clearly stated. Implicit subjects only follow after the first sentence in a paragraph or a phrase. Case in point is the words you've read so far. "are", "follow" and "is" are verbs. This is why most programming languages are in infix notation. Lisp syntax stayed is a historical accident. [1] Arabic is a prefix languages, and people don…

> I think we've all learned in writing classes we should avoid it as much as possible because stating the active voice is clearer.

Writing classes can be misguided.

http://www.lel.ed.ac.uk/grammar/passives.html

Re: Ruby adds experimental support for rightward assignments

#157
post #152

Earlier quoted context omitted.

There almost invariably is a subtle difference (very commonly, in precedence), and that's usually a key part of the motivation for the (near) synonym.

That makes it confusing when there isn't a difference (I think map and collect?).

Oh, I was thinking of (nearly) synonymous alternate syntax. It's true that Ruby has lots of true synonyms in method names.

Re: Ruby adds experimental support for rightward assignments

#158

Earlier quoted context omitted.

As someone else said in these comments, Ruby offers multiple ways to express things, so you have more options to "write how you think" as opposed to being pushed to "think how the language wants you to write". I'm not saying it's good or bad, I'm just saying that appears to be one of the reasons for it.

It seems the opinionated, directive "there's only one way to do it" approach is winning over the hacking around, "wrapping around your mind" approach. Lisp and Perl have had their times under the sun, now it's all about Python and Go. Perhaps these things are cyclical.

I'm using both Ruby and Go a lot (also Elixir, PHP, Bash and others).

I wouldn't even say that they solve different problems for me, it's more a matter of how I need the problem solved. If I need something that runs on other OSes than my Linux box preferably with as few dependencies as possible, Go. However, I can probably code it faster in Ruby, so if it only needs to run on my machine or if I know Ruby's available where it needs to be run, then I'll probably go with Ruby.

I think, instead of arguing which is better, the argument should be about whether they're useful. And for both Go and Ruby that's an "absolutely!" from me.

Re: Ruby adds experimental support for rightward assignments

#159

Earlier quoted context omitted.

A math tutor of mine was actually pretty angry at computer science for writing things like `a=1; a=2; //so 1=2 ?` I guess he'd rather have the "assign 42 to age"... Except he'd probably read `42 => age` as "42 implies age", which would probably cause him more sleepless nights ;)

I had the same issue. This is why I always comment my assignments. x = x + 1 // assign x to x+1

I can't tell if this is a multiple joke or not

Re: Ruby adds experimental support for rightward assignments

#160

Earlier quoted context omitted.

Makes me reject the PR for lack of clarifying parentheses.

Do you really punish everybody else because you can't remember precedence rules?

Do you allow code into your codebase that isn't obvious on a first read?
Post reply on HN