tbf positional arguments are already bad enough. Now if you’re using over 9 positional args… just take a break, go for a short walk, and maybe you’ll come back with a better plan
It wouldn’t be as relevant, since passing a function or method instead of a closure is much easier in Rust - you can just name it, while Ruby requires you to use the method method.
So instead of .map(|res| res.unwrap()) you can do .map(Result::unwrap) and it’ll Just Work™.
In the case of your example we’d do .map(&:unwrap) in Ruby (if unwrap was a method we’d actually want to call)
Notably, these are not the cases _1 and _2 etc are for. They are there for the cases that are not structurally “call this method on the single argument to the block” e.g. .map{ _1 + _2 } or .map { x.foo(_1) }
(_1 is reasonable, because iterating over an enumerable sequence makes it obvious what it is; _1 and _2 combined is often reasonable, because e.g. if we iterate over a key, value enumerable, such as what you get from enumerating a Hash, it’s obvious what you get; if you find yourself using _3 or above, you’re turning to the dark side and should rethink your entire life)
That deserves an “always has been” meme… But IMO, Ruby outperled Perl since the beginning.
Perl doesn’t let you redefine the syntax so that you can write the same program multiple ways. All it does is to encourage multiple programs to have the same meaning.
I do think the unnumbered variant of such anonymous parameters is useful, if you’ve got a team of devs that knows not to misuse them.
In particular, folks who are unexperienced will gladly make massive multi-line transformations, all in one step, and then continue blathering on about it or similar, as if everyone knew what they were talking about and there was no potential for ambiguity.
This is also particularly annoying, because you rarely read code top-to-bottom. Ideally, you should be able to jump into the middle of any code and start reading, without having to figure out what the regional abbreviations or it mean.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
Is it just me or does it feel kinda unclean for it to just support 1 through 9?
tbf positional arguments are already bad enough. Now if you’re using over 9 positional args… just take a break, go for a short walk, and maybe you’ll come back with a better plan
Damn, I wish rust had that
Swift does, though using the dollar sign rather than underscores
I’m glad it doesnt.
I sincerely doubt Rust would ever add something like this.
It wouldn’t be as relevant, since passing a function or method instead of a closure is much easier in Rust - you can just name it, while Ruby requires you to use the
methodmethod.So instead of
.map(|res| res.unwrap())you can do.map(Result::unwrap)and it’ll Just Work™.In the case of your example we’d do
.map(&:unwrap)in Ruby (if unwrap was a method we’d actually want to call)Notably, these are not the cases
_1and_2etc are for. They are there for the cases that are not structurally “call this method on the single argument to the block” e.g..map{ _1 + _2 }or.map { x.foo(_1) }(
_1is reasonable, because iterating over an enumerable sequence makes it obvious what it is;_1and_2combined is often reasonable, because e.g. if we iterate over a key, value enumerable, such as what you get from enumerating aHash, it’s obvious what you get; if you find yourself using_3or above, you’re turning to the dark side and should rethink your entire life)Except when Type::Method takes a reference, then it doesn’t just work
Is ruby the new Perl?
That deserves an “always has been” meme… But IMO, Ruby outperled Perl since the beginning.
Perl doesn’t let you redefine the syntax so that you can write the same program multiple ways. All it does is to encourage multiple programs to have the same meaning.
I never looked at Ruby, but that doesn’t seem like it would be great for readability (although maybe productivity).
People mostly refrain from using it.
Much like people used to create an idiom in Perl and stick to it.
And lets you easily write metal languages due to the way you can pass around blocks. Think configuration as code type stuff.
and that’s yet another way to end up with hard to read code.
Variables hold values that have meaning. Learn how to name things and you’ll write good code.
This makes me want to write a function for you to add to numbers where the variables are leftumber and rightnumber, instead of x and y.
if “left” and “right” were relevant for addition, they would indeed be better names
Are you against using a single letter variable like e for element in iterating over things?
I do think the unnumbered variant of such anonymous parameters is useful, if you’ve got a team of devs that knows not to misuse them.
In particular, folks who are unexperienced will gladly make massive multi-line transformations, all in one step, and then continue blathering on about
itor similar, as if everyone knew what they were talking about and there was no potential for ambiguity.This is also particularly annoying, because you rarely read code top-to-bottom. Ideally, you should be able to jump into the middle of any code and start reading, without having to figure out what the regional abbreviations or
itmean.OMG looks like Raku