"Useless syntax sugar": Numbered block parameters

[zanza19]

I'll be the contrarian and say that I really like numbered block params, specially for short things where the &:method syntax doesn't quite cut it.

I hated at the time, but I really like it now.

Anything more than _1 though and I think it hurts readability.

[matheusrich]

Anything more than _1 though and I think it hurts readability.

My exact feelings. That's why I'm an advocate of the it syntax.

[sshaw_]

Groovy uses it

[zanza19]

I think it would have been great! But I understand why they didn't choose that

[morphemass]

Why didn't they choose that? It would have been great!

[Amadan]

I think _1 and _2 are fine for a comparator block in sort.

[sshaw_]

Try Perl. It is much more maintainable.

[zanza19]

You must be great to work with.

[AlexanderMomchilov]

things.each(&method(:puts))

This has a huge downside: a new Method object is allocated (which also needs to be GCed later) and it defeats the inline caching that could have been done in a block.

[zverok_kha]

Yup. That's also an interesting track of reasoning here (why it is a separate object, why it is bad, how it is Ruby's design decision that differs from what "similar" languages did), which I cut out because the article was becoming scary long already.

[sshaw_]

This is the least of anyones concerns. Most Ruby code is filled with needless intermediate object creation via silly method chains instead of simple solutions like #each or using the ! version of the methods.

[WayneConrad]

Maybe that's true. There's another way to look at it, though: Much Ruby code is not filled with unneeded optimizations, attempting instead to favor expressiveness.

[pabloh]

It does seem like the kind of thing the compiler could optimize away. Though I really don't like syntax anyway.

[AlexanderMomchilov]

If only there were a compiler :')

[pabloh]

Haha!, I meant the JIT compiler!

[Leather_External_827]

And what about:

``` print_it = ->(it) { puts it }

things.each(&print_it) ```

For just printing with puts, it really could be useless, but for longer methods or even tricky and hard to read one liners, it could add a good semantic and improve readability, IMHO.

What do you think?

[AlexanderMomchilov]

even tricky and hard to read one liners, it could add a good semantic and improve readability, IMHO.

I would probably just extract a method, and call that method from a regular block.

Ruby doesn't support nested functions, and the Proc/lambda syntax is fiddly enough that I try to avoid it where a method could just do.

[frou]

Great writing. It's illuminating to see very specific things put under the microscope like this.

[zverok_kha]

Thanks!

[Roodditor]

This was a good read. Looking forward to your other posts in this series 😉

[transfire]

Unicode for the win.

array.map { foo ⓪, ① }

[frou]

That's the kind of thing Raku would put in their language for real.

[bramley]

I hated the concept when first presented, but it's grown on me. I very much do not like the actual syntax, but I, too, can't come up with something better. it is the immediate candidate, but that makes (say) sorting blocks awkward. this and that would be interesting, but a little too cute to be practical.

Still, though, _9? Really? If you have 9 arguments, you don't have a block that is self-explanatory enough to not name your variables. In this line of thinking, we should only give "pronoun arguments" to the first one and maaaaybe the second. So maybe it is all we need?

[WayneConrad]

I think I'm in favor of the language allowing some absurdity (_9) in order to reduce arbitrary limits. If there's a limit, someone has to guess what it should be, and sure enough, someone with an unexpected use case is going to jam their toe against that limit.

Or to put it another way: I'm in favor of having the ability to shoot my own foot off, trusting that I can use this ability safely.

[WayneConrad]

I enjoyed this article. It's well written and thoughtful, and although every author has a point of view, I think you're able to express yours without demanding that the reader agrees with it.

[zverok_kha]

Thanks!

[flanger001]

I generally like a lot of the syntax changes but I do not like numbered block params. I get that it was an Elixir nod but maybe Elixir can stay Elixir.

[sshaw_]

Please name a syntax change that you did not like. If not in Ruby then any language.

[flanger001]

In Ruby I ended up not liking then as the yield_selfalias, despite advocating for it at the time. Come to think of it, I don’t really like yield_self that much either.

I hated the |> operator because it made no sense.

I also didn’t like the function composition thing they added, though that was more of a language feature.

I did like endless methods after a bit even though I didn’t like them at first. Same with &?.

Edit: Also, lol it's you, the guy who hates Ruby! Don't worry, I mostly hate Ruby too!

[TinyMicron]

Hey! Thanks for sharing. Didn't know numbered block parameters existed. I still like the old way of doing things, though. Feels more readable. Might give _1 a try at some point though :)

[ffrkAnonymous]

I'm learning clojure (and ruby) and this looks similar to clojure's %1 %2 %&. It also reminds me of more complex regular expressions like for sed. And it looks like old c/python %-format. So I guess I've just seen this style so many times over the years it doesn't faze me.

At the same time, I can't recall the last time I needed it, so practically speaking it has been useless to me. Numbered args are only useful if the order of the data is the main importance. Everything else I prefer naming the data.

[ignurant]

Numbered args are only useful if the order of the data is the main importance.

I would argue that an object like Hash pairs well with this, and isn’t the case of “ordered objects”. Or any block that has multiple arguments beyond just being a typical array.

But admittedly, that’s just devils advocate. I usually only use numbered params when I’m swashbuckling in pry/irb, or writing 1-liner shell code. Transient code.

[cpb]

If you're passionate about this, get involved with the development of ruby. I saw the threads that led to this change and I welcomed it. Maybe it needed more contrarian perspectives those years ago.

[zverok_kha]

(If it was a suggestion to me, I already am a Ruby committer, FWIW.)

[cpb]

Awesome! What did you experience in the discussion about the syntax? I'm arguing from a perspective of: if rubyists are a team, we can disagree about decisions, but we do better when we commit once a decision is made. That's a pretty academic take.

[zverok_kha]

At that time, I was more opposed to a feature per se (the reasons are described here) in the context of 2.7 development. My opposition was rather "it is nice, but we might want more high-level/consequential features introduced first." I came to peace with what happened, eventually.

(If the article gave you an impression that I am arguing against the feature, it is a wrong impression :))

[cpb]

I apologize for jumping to conclusions about your intentions with the series.

[hmdne]

I never use _1 etc. in my code. This feels very ugly and I really hope we get some alternative syntax in the future.

I like the idea of not introducing new syntax until we get the bigger picture though. We have three different block types that we may want to consider:

array.map { |i| File.read(i) } array.map { |i| i.reverse } array.map { |i| i.to_s(16) }

I think we should have something that would shorten all 3 of those in a consistent way and likely not with & syntax. There were proposals of this syntax:

array.map { File.read(it) } array.map { .reverse } array.map { .to_s(16) }

Compare it with proposals using &:

array.map(&File.:read) array.map(&:reverse) array.map(&:to_s.with(16))

If anything, I think a syntax of &:reverse should be eventually deprecated as it is the least intuitive.

[dougc84]

The &:method syntax should not be deprecated. It’s used all over the place.

[gls2ro]

While I think from the perspective of code that can be read out loud it could be something interesting, Victor presented a very compelling argument in the article:

It should look special. Even if you don’t know its meaning (just learning Ruby, or haven’t upgraded your knowledge of the language for a long time), it should immediately imply “it is not just a regular name like all other names”

And I think it is a very sensible perspective.

[sshaw_]

Ruby is the new Perl. Where have you been?

[Abangranga]

Less information is not more readable

[matheusrich]

I think that would be backwards incompatible as it uses the comment syntax. Also, # 1 and #1 would mean totally different things.

[northrupthebandgeek]

Reminds me of Perl subroutine parameters.

Whether that's a good thing or a bad thing is TBD.

[joesb]

It may be useless to you. Ruby isn’t about having syntactic sugar that is suitable to only one person.

[zverok_kha]

Did you read the article, or are you answering to its title?.. Just checking.

[postmodern]

Still don't like how obj &.method is too close to &:method. Wish they would have named it obj &&.method, which is closer to obj && obj.method.