Hacker News Reader

Everything is a tradeoff.

You say:

> sometimes you don't have a name ready and it's actually better to defer naming the thing until you know what it is

You can do that without this feature; you can use throwaway variable names like "x" and "y".

Taking an example from the post:

> (1..9).each_slice(3).map { |x, y, z| x + y + z }

vs

> (1..9).each_slice(3).map { @1 + @2 + @3 }

The shorthand saves you 7 characters in the rare case when you truly have no idea what to call your block parameters (even a single-character name can be descriptive, eg if x and y are coordinates). That seems minimally useful.

Meanwhile, you've made your block parameters look like instance variables, and everyone else (including all tools that work with Ruby code) has to learn why they aren't.

Seems like a poor tradeoff to me.

> it's not reasonable to argue that your code should always be in the optimal state.

This is a strawman and not what I believe. I never said your codebase should always be optimal in every way. I believe @1 instead of even the most basic of variable names is actively an anti-pattern.

> That's the kind of thing that I'd search for in my codebase before I closed the project, and assign a name before it's too late for me to remember what that bit of code was for.

Maybe you might, but plenty of other people will not. I have also lied to myself and added "TODO" comments in some small projects I've worked on. Months and years later I sometimes see "TODO" comments because I ended up working on something else or forgot. It's simply way too easy to not go back and refactor or fix things.

There is nothing more permanent than temporary code.

Sometimes you have to go back and rename things multiple times. This is vastly better than what you know full well will happen: People will immediately gravitate towards the easiest option of @1, and then never change it because they've moved onto other parts of the code or different projects, etc.

We should not be adding ugly, terse syntax to programming languages because it's "just more convenient" to not name things. That is not a tenable argument for a permanent change to a mature language. Being lazy is not an argument.

> Maybe you might, but plenty of other people will not. I have also lied to myself and added "TODO" comments in some small projects I've worked on.

So it was cheaper to leave the TODOs in the perfectly OK code, sounds like you dodged a bullet there.

This strikes me as a slippery slope. Start with "@1 is not an appropriate way to represent this variable" then move onto "I actually don't like the name you've chosen" and finally arrive at "this code isn't important enough for me to take care of those TODOs I placed before I'm old and gray, remind me why are we even worried about how this variable is called, now renaming it for the _third time_?"

I'll usually take a collection of "xs" and iterate over each "x" without any pretense that I'm coming back to make it better. We can agree to disagree, but I'm arguing that it's not any better to do that, and it's actually harder to grep for which makes it actively worse. This is a better option.

> sounds like you dodged a bullet there.

My point is that I never went back and fixed it, because often people do not do that.

I, however, can still read that code perfectly fine and well because it has variable names. Not @1 and @2 for hashes, etc.

> now renaming it for the _third time_?"

Things get renamed from time to time (and less than you're making it out to be, typically). It's part of programming. You will be fine.

It's better to be oh-so-inconvenienced than to have to read other peoples' codebases where they just use @1 and @2.

Why have any variable names at all then? Just use 0-999, if it's so annoying to have to think for a few seconds to a minute and pick an apt name.

> I, however, can still read that code perfectly fine and well because it has variable names. Not @1 and @2 for hashes, etc.

If I do {@1 + @2} exactly once is that really harder to read than {|x, y| x + y}?

If I'm doing it everywhere all over my code, sure that's a problem and it will make unreadable garbage. But then again it was already possible to make unreadable garbage code.

In real code with actual logic (not simplified examples like here) the inner variables are typically not named |x, y|. |key, value| (or |k, v|) is one common shorthand, but even those -immediately- denote more semantic meaning than |@1, @2|.

The issue here is that @1 and @2 make it much, much easier to write garbage code. At least with named vars you explicitly have to acknowledge that you're choosing a bad name. @1 makes it so you don't even have to think about it at all. This is a flagrant issue, and doesn't belong in Ruby at all.

{} is for one-liner blocks, stylistically speaking. I occasionally use it for a longer block without refactoring it into a method (and line-breaks are permitted for sure), but typically if the one-liner is above a single line's worth of complexity, it's already on its way to becoming a method.

"In real code with actual logic" this would be a "do-block" or you're violating another stylistic rule, and none of the examples I've seen use numbered parameters with a do-block. Is it allowed? I feel like this is important information that I need to know before I can make a fair judgment about whether this is a "flagrant issue" or not.

Do-blocks with numbered parameters, if it is an allowed way to write a block, would definitely be a terrible idea.

But I don't think it is, I can't find a source that says so, since all of the results for "numbered parameters" seem to be rants against the inclusion of this feature. Have you ever read bikeshed.com? Because that's exactly what we're doing right now.

Even for one liners I think it's a bad idea. It's not that tough to do .map{ |course| course.some_method + some_str } instead of .map { @1.some_method + some_str }.

The latter is extremely ugly and does not belong in Ruby whatsoever. I'm not budging on this.

You can keep your opinion, I don't need to spend any more time trying to convince you, but to be pedantic one last time, you omitted the part of that snippet that would have made it clear the named parameter is not needed and unnecessarily verbose:

courses.map{|course| course.some_method + some_str}

is unabashedly and unnecessarily verbose, I know it's a course as it's from courses. No need to repeat yourself twice.

courses.map{@1.some_method + some_str}

by comparison is perfectly clear, once you know the syntax.

Edit:

I just installed ruby-2.7-head and I made a typo, first thought it is not permitted in a do-block. It is. I think it's bad to use this in a do-block. But like I said, there are already plenty of ways to make your code into unreadable garbage, it's up to the author to make a good decision. Some programmers will choose poorly no matter how hard you try to prevent it.

In my opinion, this syntax is for one-liner blocks only. You should avoid using tools in incorrect ways, and code that has numbered parameters strewn everywhere without any attention to naming, is guaranteed to have more than just one bad code smell in it.

But I disagree that it's the responsibility of the language to keep potentially dangerous tools out of the hands of developers.

In that example, fair enough. However often one unpacks a tuple or operates on a hash, where it's not immediately obvious what the inner values are. So we can bikeshed if you want, but I still think it's a bad idea (and looks very ugly).

"But I disagree that it's the responsibility of the language to keep potentially dangerous tools out of the hands of developers."

That is pretty much entirely the point of higher level programming languages.

Like preventing you from allocating and freeing memory on your own, because you might screw it up.

Or removing pointer arithmetic.

Or reducing the scope of mutability.

Or preventing access to "private" object variables.

Many programming language features are basically guards to make it less likely you cut your hand off.

Those are all scary indeed. Ways you can cut your hand off. Has a nice ring to it, sounds like something to worry about more than "ways you can write unreadable garbage code that not even the author can still parse for themselves in their head."

Nobody is arguing that there aren't ways to misuse this new feature. There obviously are! But I can tell you we have plenty of time to call the ways out and warn everyone not to do those things, before ruby-2.7 will be affecting any legacy codebases.

If you feel strongly about this, the time to argue about it is definitely now, not after the first 2.7 release is already cut.

It makes the list of un-googlable idiomatic syntaxes that you must learn and keep in a list, in order to guarantee you won't ever find a bit of Ruby code that you can't understand, marginally longer. There are several such features planned in the ruby-2.7-head now. Is this really the worst of them?

"If I do {@1 + @2} exactly once is that really harder to read than {|x, y| x + y}?"

It's certainly no easier. "{|x, y| x + y}" immediately clearly conveys "this is a block taking exactly two arguments and returns their sum". Adding syntax for "@1 + @2" adds an entirely new construct for every Ruby programmer to learn and recognize as a pattern, in addition to the full block syntax form, and their brains to be able to switch between pattern matching for either pattern to quickly parse what the code is doing.

All for zero benefits.

String enough of these arbitrarily different syntactic variants for the exact same thing, and you end up with C++.

You also lose information, because @1 and @2 magically appear. With || notation you have to explicitly spell out, beforehand, exactly how many variables will be in the block.

tuple.collect{ |x,y,z| [x * 3, y * 3, z * 3] }

is better than

tuple.collect{ [@1 * 3, @2 * 3, @3 * 3] }

because with the latter, I need to know in my head that there will be three parameters.

The more I read about this syntax the worse I feel about it.

I don't buy this argument.

This is syntactically valid ruby, current state:

tuple.collect{ |x,y,z| [x * 3, y * 3] }

and so is this:

tuple.collect{ |y,z| [x * 3, y * 3, z * 3] }

The last one will generate a runtime error (unless "x" is already defined in the closed-over scope the block exists inside of, in that case it might be valid and correct.)

But both are valid Ruby expressions.

Neither are less inscrutable than:

tuple.collect{ [@1 * 3, @2 * 3, @3 * 3] }

This expression will return nil for @3 if only two arguments are passed in, again it's a perfectly valid Ruby expression, and you'll get a runtime error from inside of the block in this case, just like the pre-existing standard block syntaxes.

It's up to the author of the code to create readable constructions that aren't misleading or confusing. There's no reason why this tool is innately bad, more tools can only make it more likely that the author will find an expressive and clear way to say exactly what they're doing without writing something confusing or redundant.

From a language purist perspective, these are all very good reasons not to use Ruby at all. I don't think that adding numbered positional params makes it worse in any objective sense.

Except you don't. [1,2,3].collect{|x,y,z| ... } is perfectly valid ruby if "..." is an expression that does not blow up when y and z are nil.

Likewise

[[1,2,3]].collect{|x,y| [x,y]}

is perfectly valid even though 3 will not get assigned to anything.

So you're being forced to spell out which arguments you want to be able to reference, which is probably related to what it will get passed, but not required to be.

So if you don't know how many parameters there will be, you're in trouble either way.

"I'll usually take a collection of "xs" and iterate over each "x" without any pretense that I'm coming back to make it better."

Those can be perfectly fine names!

xs indicates you are writing a generic method or function applicable to just about any kind of collection, and x is an item in xs. So for functions like map and reduce or anything else that deals with arbitrary collections, these names are very clear in expressing the intent and far better than @1, etc.

This is similar to using "i" as the index variable in a for loop, an almost universally recognized convention.

You can see all the TODO comments if you choose to; they are a grep away.

Of course I can. That doesn't mean I actually will go back and fix them.

TODO statements are little lies that programmers tell themselves. "I'll go back and fix this/refactor it, yeah, yeah...". And most of the time, that doesn't happen.

I don't program in Ruby and never really have, but there is one thing I know dealing with plenty of legacy code: Temporary code is almost always permanent.

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.

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://hilton.org.uk/blog/why-naming-things-is-hard

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.

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.

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

> @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.

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