this post was submitted on 11 Oct 2023
61 points (94.2% liked)

Programming

17706 readers
270 users here now

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

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago
MODERATORS
snowe
Ategon
[email protected]
61
"Useless syntax sugar": Numbered block parameters in Ruby (zverok.space)
submitted 1 year ago by PythOnRails to c/programming
35 comments fedilink hide all child comments
all 36 comments
sorted by: hot top controversial new old
[–] [email protected] 20 points 1 year ago* (last edited 1 year ago) (1 children)

The liberty to not name things that are obvious.

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.

edit: someone just wrote an article along these lines. The only thing I'd change is the cause-effect relationship between bad names and bad code. IME bad names lead to bad code, not usually the other way around. The reason is that by starting from good name choices, it's much easier to have a well structured code. And not rarely, bad names lead to mangled up code that screams for a refactoring.

[–] [email protected] 0 points 1 year ago (3 children)

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.

[–] [email protected] 5 points 1 year ago (1 children)

if "left" and "right" were relevant for addition, they would indeed be better names

[–] [email protected] 1 points 1 year ago (2 children)

Are you against using a single letter variable like e for element in iterating over things?

[–] [email protected] 3 points 1 year ago (1 children)

yes

[–] [email protected] 1 points 1 year ago (2 children)

To each their own. But man imagine if you have a collection of stuff that has a large name, and then having to figure out a short name other than e when iterating. I hope you're not iterating over chemical names 😬

[–] [email protected] 4 points 1 year ago

No need to be over-descriptive. Anything at all more specific than e will probably be a better name

[–] Kalabasa 1 points 1 year ago

It's not black and white. I mean, even el is a lot better than e.

[–] noli 1 points 1 year ago* (last edited 1 year ago)

Depends. If you're using a good ol' C-style for loop then nothing's wrong with for(int i = 0; i < something;i++), but if you're doing something like iterating over some collection it's way clearer to do something like for animal in animals: than it is to do for e in animals:. Especially if you're doing something non-trivial for each element

[–] [email protected] 1 points 1 year ago

Implementing add (and other math operations) in rust for your types has the type signature self and rhs (right hand side).

[–] [email protected] 0 points 1 year ago (1 children)

Lhs and rhs are much better than x and y

[–] [email protected] 2 points 1 year ago (1 children)

In what way? If you encountered a function that had x and y which just added them together, that's not readable enough?

[–] [email protected] 1 points 1 year ago

Well in a vacuum yes sure, you're right, but in practice there's always some context. x and y could be referring to axes, where an addition makes little sense. However lhs and rhs make more sense if you're overloading an operator

[–] [email protected] 13 points 1 year ago (2 children)

Is ruby the new Perl?

[–] [email protected] 15 points 1 year ago (2 children)

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.

[–] [email protected] 4 points 1 year ago (2 children)

I never looked at Ruby, but that doesn't seem like it would be great for readability (although maybe productivity).

[–] [email protected] 4 points 1 year ago

People mostly refrain from using it.

Much like people used to create an idiom in Perl and stick to it.

[–] [email protected] 1 points 1 year ago

It's designed to be as readable as english.

Take that as you will

[–] [email protected] 2 points 1 year ago

And lets you easily write metal languages due to the way you can pass around blocks. Think configuration as code type stuff.

[–] [email protected] 1 points 1 year ago

Ruby cribbed a whole lot of syntax from Perl from the very beginning. Most of the rest comes from Smalltalk, but Ruby got it's multitude of two character "$" variables from Perl, it's autosplit mode (-a -n -p switches, letting Ruby, like Perl "emulate Awk"), it's regexp match captures going into $1, $2 etc. from Perl.

[–] [email protected] 9 points 1 year ago (2 children)

Is it just me or does it feel kinda unclean for it to just support 1 through 9?

[–] [email protected] 10 points 1 year ago (1 children)

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

[–] [email protected] 2 points 1 year ago* (last edited 1 year ago) (1 children)

I mean 4 is probably too many, 8 definitely is, but also what about splat-args like zip or min. Why not stop at 4? Why not stop at 8 since its a power of two? Any hand-picked limit just feels pretty bleh to me. Either support everything or dont support it at all IMO

[–] [email protected] 2 points 1 year ago* (last edited 1 year ago)

Why overthink it. Stopping at the highest single digit decimal number is a fine choice. I'm more unsettled by the sequence starting at _1 instead of _0 if anything.

[–] [email protected] 2 points 1 year ago

If you need a lambda with 10 parameters you might consider aggregating those parameters into a struct or a hash instead. lambda are meant to be short functions

[–] [email protected] 5 points 1 year ago

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.

[–] bnjmn 2 points 1 year ago

OMG looks like Raku

[–] [email protected] -1 points 1 year ago (4 children)

Damn, I wish rust had that

[–] [email protected] 16 points 1 year ago (3 children)

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

[–] [email protected] 6 points 1 year ago (1 children)

Except when Type::Method takes a reference, then it doesn't just work

[–] [email protected] 0 points 1 year ago* (last edited 1 year ago)

Well, that's to be expected - the implementation of map expects a function that takes ownership of its inputs, so you get a type mismatch.

If you really want to golf things, you can tack your own map_ref (and friends) onto the Iterator trait. It's not very useful - the output can't reference the input - but it's possible!

I imagine you could possibly extend this to a combinator that returns a tuple of (Input, ref_map'd output) to get around that limitation, although I can't think of any cases where that would actually be useful.

[–] [email protected] 2 points 1 year ago* (last edited 1 year ago)

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)

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

Ruby lets you do .map(&:unwrap) no need for results

edit: lemmy keeps adding in the &, not sure how to avoid that

[–] [email protected] 3 points 1 year ago

Swift does, though using the dollar sign rather than underscores

[–] Anders429 2 points 1 year ago

I sincerely doubt Rust would ever add something like this.