Hacker News Reader

Comment by kevin_thibedeau | Hacker News Reader

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.

View on HN

Is this like 'unless'?

Unless is great if it's the first or second clause on the line. If it's the tenth, then it feels more like slapstick and I am the butt of the joke. Haha, just kidding, we aren't really going to call that function.

Similarly, rightward:

   someBigFunction(thatNeedsAnswersFrom(), otherFunctions(), true) => variableIAmDebugging

Three unnamed Laws of Computing that everyone ignores and at their peril:

- Nobody reads your unit tests in a PR

- People glaze over at the end of long lines of code

- Merges are hard

#2 and #3 combine to cause over half of the bad merges I have had to diagnose. Don't save the important bits for the end of a line. If I were still writing Ruby code, I'd be prepping to see more of them.

If your 10th clause is an unless then you're using it wrong. I agree that unless and the right hand assignment can be used incorrectly but that's not a reason to omit the feature :)

Where these conversations tend to break down is "you are using it wrong", which is technically correct but practically is a non sequitur.

I can't control other people. Neither can you. Unfortunately saying that and acting like it's true are two separate things, and so we are chronically making decisions based on an illusion of control that is unhealthy to the point of self-harm. It just sets you up for disappointment and/or antisocial behavior (eg delusions of grandeur)

We put safeties on missiles. We color code and cover emergency power cutoffs in server rooms. We've started putting finger preservation devices on table saws. But code? Well it's your fault for backing into the shutoff button.

"You're using it wrong" = "People will use it wrong." = "You're going to have to work with people who use it wrong" = "You are going to run out of places to hide their bodies and just have to accept it being used wrong."

The question isn't "can it be used right?". Every bad library ever written has been "used right" by at least the author, even if not all the time. The question is "can we live with how often it is going to be used wrong?"

> We put safeties on missiles

And we put linters on code.

Sometimes. Often we don't. Putting linters on code is doing it right. But unless the language is opinionated and requires the linter there will be people who don't use it.

There are no language features that can't "be used wrong". This argument proves too much!

Status Quo Bias is probably why we don't think of existing language features this way.

It's of course true that we're all likely to work with (or even be) incompetent people, but I really doubt individual language features has substantial impact on the damage they cause.

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.

The fat rocket seems like an odd choice for an operator. It's already used for hashes - and you don't have to put set braces around hashes.

Until youre working on a team and your thoughts aren't the same as everyone else's thoughts.

Sure. Peer review, making sure that the code one person has written makes sense to the rest of the team, is a fundamental and incredibly important part of pretty much all team-based development projects.

that's why having a coding style guide is important and to lint it every commit.

That’s rubocop’s raison d’etre. I like that you can be completely free exploring with code in the style you like, and “button up” when it needs to become shipping/shared code.

That doesn't sound any more difficult to resolve than the fact that you are probably working on a team where different individuals prefer different programming languages.

If everyone thought like this there would only be one language that everyone used. Writing software is creative.

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.

I find it really valuable to have different patterns of similar tokens to express different intent. My canonical example is early returns in JavaScript.

Function f () {

  if(errorCindition) return

  if(normalBehavior) {
    return 1
  }
  else {
    return 2
  }

}

(I know, my use of braces and lack of semi-colons will cause flame wars!)

The error condition looks different from the rest, so when I’m scanning quickly, I know where I am. My eyesight’s rubbish, so the shape of the code has a marked impact on me. I don’t have to read the whole thing to orient myself.

I thought it was nuts when I read the title, but reading the examples had a noticeable “easing” effect on my reading. So I’m very excited by this addition to Ruby. It could lead to some neat, expressive patterns.

shape of the code

This is an undervalued aspect of development. The tactile shape of a block of code conveys some aspects of intent, and overly aggressive linting tools destroy that intent.

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.

> 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?

Reply on news.ycombinator.com