I read it as "42 is stored in age". The works particularly well for a long chain of methods that should end in storing the resulting value in a variable. I know this might seem to be the most conventional way that Ruby is written; it makes a single statement take 8 lines instead of 1, it transforms a value over the course of the statement instead of sending messages to tell an object to transform itself, and it ignores the concept of encapsulation by moving the interesting actions into the foreground rather than being hidden within an object.

Below is an _incredibly_ contrived example. Take note how the `=> final_value` syntax is useful. The alternative is to place a `final_value = ` at the _top_ of the statement. I'll admit: placing the assignment at the top of the method chain helps point out to the reader of the code that an assignment is happening. However, more useful I think is quickly recognizing the flow of data.

  "hello"
    .chars
    .size
    .*(10980643.4)
    .to_i
    .to_s(36)
    .upcase
    => final_value
  
  puts(final_value)
  # => WORLD

wait i feel like that's actually kind of gorgeous. syntax highlighting as it exists today might not be good enough to really make that form stand out, though...

... and it's useful how? It obscures the assignment at the end of an arbitrarily long statement instead of giving the value a name right up front.

It feels a bit like a new method definition syntax that allows you to put the name after the `end` for... reasons.

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 ;)

He’d probably like a := 42 which is in a lot of languages actually! Also Erlang and other fp’s do consider = equivalence.

I noticed a year or two ago when I'm pseudocoding I seem to default to "age <- 42" which I kinda like more...

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

> math tutor ... angry

It's not the same language, so why should he expect the semantics to be the same?

> It's not the same language, so why should he expect the semantics to be the same?

It's a bit like discovering that inline C in your favourite non-C language isn't actually semantically correct C. If you're a mathematician, then you know, intimately and fluently, how math is spoken and written, so seeing something that looks exactly like "inline math", but isn't, is jarring.

(I don't get angry over it, but it is exactly counter to the extremely delicate and precise way mathematicians train ourselves to think about '='.)

I'm a big fan of immutability and using constantly so I agree with your tutor.

If you visualize variables as "boxes" with values in them, "put 42 in age" makes sense.

But “age is 42” is a statement/Boolean, not a mutation. “Let age be 42” is more natural, but doesn’t sound well on reassignments (“let age now be 42”?)

I would say this as "set age to 42".

"age is 42" may be a statement while "is age 42" may produce a boolean.

And I don't see why a statement can't describe a mutation.

I read assignment like "age gets 42".

`42 => age` would probably be "42 is age", or if it was `42 => person.age` you'd read it "42 is person's age".

That's why tcl uses:

set age 42

Exactly how I feel. This is one of the reasons I'm not a huge fan of R, either

Agreed, when I read that line I found myself saying it out loud wondering if it was a typo.

`favorite_color = red' == "Favorite Color is Red"

Which feels more natural than: "Red is Favorite Color"

"42 gets crammed into age"

42 is the age