• marcos@lemmy.world
      link
      fedilink
      arrow-up
      9
      arrow-down
      1
      ·
      1 year ago

      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.

      • AnUnusualRelic@lemmy.world
        link
        fedilink
        English
        arrow-up
        3
        ·
        1 year ago

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

    • V H@lemmy.stad.social
      link
      fedilink
      arrow-up
      1
      ·
      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.

  • Eager Eagle@lemmy.world
    link
    fedilink
    English
    arrow-up
    5
    arrow-down
    2
    ·
    edit-2
    1 year ago

    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.

  • Knusper@feddit.de
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    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.

    • Eager Eagle@lemmy.world
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 year ago

      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

    • colonial@lemmy.world
      link
      fedilink
      arrow-up
      12
      arrow-down
      1
      ·
      1 year ago

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

        • colonial@lemmy.world
          link
          fedilink
          arrow-up
          0
          arrow-down
          1
          ·
          edit-2
          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.

      • V H@lemmy.stad.social
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        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)

      • morrowind@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        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