6 ms·

Naming things is not hard. It's probably the easiest part of programming. @1, @2 are names, and they're no better than fst, snd.

by Retra 8y ago

yebyen 8y ago
I'm sorry, but there's a great deal of literature in support of this idea that naming things /well/ is one of the harder problems of programming. If you're arguing that "fst" and "snd" are better names than "@1" and "@2" then I think we have a disagreement. None of those are good names. (All of those might be perfectly "sufficient" names, though. For a local variable, I would argue that spending any time at all on naming is a mistake. Spend that time writing a descriptive method name instead.) https://martinfowler.com/bliki/TwoHardThings.html https://martinfowler.com/bliki/TwoHardThings.html https://hilton.org.uk/blog/why-naming-things-is-hard https://hilton.org.uk/blog/why-naming-things-is-hard https://www.quora.com/Why-is-naming-things-hard-in-computer-science-and-how-can-it-can-be-made-easier https://www.quora.com/Why-is-naming-things-hard-in-computer-... This is foundations of computer science stuff. If you choose a solidly descriptive but wrong name before the design is fully solidified, you may be stuck with it because it will work its way through dependencies. Even if you can rename it later during refactoring, the name will shape the formulation of those refactors. I think all of this is overblown when it comes to talking about local variables in a block scope. This is absolutely a case study in the "bikeshed problem" at this point in the thread. There are other features planned in Ruby 2.7 (like the :. operator) that actually make the operation of some code less discoverable and will hurt to see in your codebase for the first time, but we're not talking about them at all, because they're simply not as easy for us to hate on.
- Retra 8y ago
  A regularly repeated meme is not "a great deal of literature." To say naming things is hard is like saying that getting a golf ball into a hole is hard; It is not. Sure it is if you're using some artificial restriction that you have to whack it with a stick from 400 yards away. Naming your children might be hard if you're trying to solve world poverty via the child-naming process. And naming things might be hard for programmers if they are not allowed to rename things or document the meaning and history of their names. But that really doesn't have much to do with language design. >If you're arguing that "fst" and "snd" are better names than "@1" and "@2" then I think we have a disagreement. I'm not arguing that. I'm arguing that they are not worse names. And as you probably recognized, if names like (@1, @2) are a good enough solution, then certainly (a, b), or (fst, snd) have an equivalently high bar for rejection.
  - yebyen 8y ago
    > artificial restriction One man's artificial restriction is another man's invariant. "We can't rename this thing without renaming it everywhere" is a thing, but honestly not in this case, because we're talking about a feature that is used to decide the name of local block variables. The only place that local block parameter variable names will get used, except directly inside of the local block, is in blocks that are nested even deeper. We're not designing an interface inside of local blocks. If you've read the thread and Matz opinion on the matter, the issue is that it's a requested feature and someone has taken the time to write it into the language. You need a good reason now, if you want to tell that person they can't have what they said they need. It was designed carefully so that it would not break existing valid uses of the language. Maybe the block was meant to take 99 parameters, should the author be forced to come up with 99 one-letter variable names and type them all correctly, twice? The point is to provide another option, you won't be forced to use it. (I'm sure that Rubocop will even provide an option to enforce that your style guide specifies your devs must not use it.) At any rate it sounds like this feature will land in Ruby 2.7 whether we like it or not.
dragonwriter 8y ago
> @1, @2 are names, and they're no better than fst, snd. They are better than fst and snd in a new iteration of Ruby, because giving a special meaning to existing legal identifiers in certain contexts risks breaking existing code; @1 and @2 (despite the similarity to instance variable notation) are not legal identifiers in existing Ruby so their special role has no effect on existing code.
- Retra 8y ago
  >giving a special meaning to existing legal identifiers in certain contexts risks breaking existing code That's just what scoped variables are. I've never seen it be a hazard other than shadowing names, and you'll have the same problem with @1, @2, etc. A closure returning a closure for instance. Unless you're just completely misunderstanding me, thinking I'd be a proponent of fst, snd as direct substitutions for @1, @2? That would be absurd. I'm comparing |fst,snd| fst+snd to @1+@2. Code isn't going to break with either.

Naming things is not hard. It's probably the easiest part of programming. @1, @2 are names, and they're no better than fst, snd.

by Retra 8y ago

Naming things is not hard. It's probably the easiest part of programming. @1, @2 are names, and they're no better than fst, snd.

yebyen 8y ago

I'm sorry, but there's a great deal of literature in support of this idea that naming things /well/ is one of the harder problems of programming. If you're arguing that "fst" and "snd" are better names than "@1" and "@2" then I think we have a disagreement. None of those are good names. (All of those might be perfectly "sufficient" names, though. For a local variable, I would argue that spending any time at all on naming is a mistake. Spend that time writing a descriptive method name instead.) https://martinfowler.com/bliki/TwoHardThings.html https://martinfowler.com/bliki/TwoHardThings.html https://hilton.org.uk/blog/why-naming-things-is-hard https://hilton.org.uk/blog/why-naming-things-is-hard https://www.quora.com/Why-is-naming-things-hard-in-computer-science-and-how-can-it-can-be-made-easier https://www.quora.com/Why-is-naming-things-hard-in-computer-... This is foundations of computer science stuff. If you choose a solidly descriptive but wrong name before the design is fully solidified, you may be stuck with it because it will work its way through dependencies. Even if you can rename it later during refactoring, the name will shape the formulation of those refactors. I think all of this is overblown when it comes to talking about local variables in a block scope. This is absolutely a case study in the "bikeshed problem" at this point in the thread. There are other features planned in Ruby 2.7 (like the :. operator) that actually make the operation of some code less discoverable and will hurt to see in your codebase for the first time, but we're not talking about them at all, because they're simply not as easy for us to hate on.

Retra 8y ago
A regularly repeated meme is not "a great deal of literature." To say naming things is hard is like saying that getting a golf ball into a hole is hard; It is not. Sure it is if you're using some artificial restriction that you have to whack it with a stick from 400 yards away. Naming your children might be hard if you're trying to solve world poverty via the child-naming process. And naming things might be hard for programmers if they are not allowed to rename things or document the meaning and history of their names. But that really doesn't have much to do with language design. >If you're arguing that "fst" and "snd" are better names than "@1" and "@2" then I think we have a disagreement. I'm not arguing that. I'm arguing that they are not worse names. And as you probably recognized, if names like (@1, @2) are a good enough solution, then certainly (a, b), or (fst, snd) have an equivalently high bar for rejection.
- yebyen 8y ago
  > artificial restriction One man's artificial restriction is another man's invariant. "We can't rename this thing without renaming it everywhere" is a thing, but honestly not in this case, because we're talking about a feature that is used to decide the name of local block variables. The only place that local block parameter variable names will get used, except directly inside of the local block, is in blocks that are nested even deeper. We're not designing an interface inside of local blocks. If you've read the thread and Matz opinion on the matter, the issue is that it's a requested feature and someone has taken the time to write it into the language. You need a good reason now, if you want to tell that person they can't have what they said they need. It was designed carefully so that it would not break existing valid uses of the language. Maybe the block was meant to take 99 parameters, should the author be forced to come up with 99 one-letter variable names and type them all correctly, twice? The point is to provide another option, you won't be forced to use it. (I'm sure that Rubocop will even provide an option to enforce that your style guide specifies your devs must not use it.) At any rate it sounds like this feature will land in Ruby 2.7 whether we like it or not.

dragonwriter 8y ago

> @1, @2 are names, and they're no better than fst, snd. They are better than fst and snd in a new iteration of Ruby, because giving a special meaning to existing legal identifiers in certain contexts risks breaking existing code; @1 and @2 (despite the similarity to instance variable notation) are not legal identifiers in existing Ruby so their special role has no effect on existing code.

Retra 8y ago
>giving a special meaning to existing legal identifiers in certain contexts risks breaking existing code That's just what scoped variables are. I've never seen it be a hazard other than shadowing names, and you'll have the same problem with @1, @2, etc. A closure returning a closure for instance. Unless you're just completely misunderstanding me, thinking I'd be a proponent of fst, snd as direct substitutions for @1, @2? That would be absurd. I'm comparing |fst,snd| fst+snd to @1+@2. Code isn't going to break with either.