Comment by dasyatidprime | Hacker News Reader

Comment by dasyatidprime | Hacker News Reader

Regarding the @ positional-argument syntax: I mean, my use of Ruby dropped considerably years ago, but from a Ruby-philosophy standpoint it looks fantastic to me. Having to constantly make up (usually single-character anyway) names for those parameters in map/filter chains was one of the ugliest parts of the language, especially when there was no actually-good name for things like temporary tuples, and the Smalltalk-derived (I think) syntax for block parameters is so visually heavyweight: { |…| … } { |…| … } { |…| … } where all the stuff in the || is close to useless, as opposed to just { … } { … } { … }. Method references passed with &, while separately useful, are not a good substitute; they're often less readable (to me) because the form of the expression is obscured, and they break down much faster, for instance as soon as you need any single other argument, rather than just when the block gets complex enough that the parameter names become important for readability.

I can appreciate that it moves farther away from “requiring things to be explicit means you get fewer accidental barriers to moving code around or increasing/decreasing complexity”, though, as some of my recent work has been in Java and I've had an eye for that aspect of it. But the next time I do anything in Ruby I'll be remembering that this is there.

I like Kotlins solution for this. If there is only one argument in the lambda/block and the type is clear from the context you don’t have to declare it and you can use the ‘it’ keyword instead.

And one parameter is 99% of the cases. If you have more than one, you should probably name them anyway.

> And one parameter is 99% of the cases.

In Ruby, the two-parameter hash-iteration case alone is common enough that that's not true.

> If you have more than one, you should probably name them anyway.

In a single line block, I think that often impairs rather than enhances readability.

k, v impairs readability?

For clarification, it looks like this

  people.filter { it.age > 42 }

Needs more aliases:

  things.filter { its.age > 42 }
  people.filter { their.age > 42 }

;)

Wow, that's splendid! In a sense, it's a very nice dual to "this", which is also a keyword everywhere and not something like $0 or something. I wish more languages had this. Or, it.

If you go back and read the post and linked ticket, that is indeed the original proposal for Ruby, which somehow morphed into positional arguments.

Kotlin is great, but I think the "it" syntax was derived from Groovy.

I'm not positive, but Groovy may in turn have been inspired by Perl's $_, as in 'map { $_ + 1 } (1..10);'.

If I recall correctly, the canonical name for that parameter is 'it' as well (though I've never met a Perl programmer that calls it that . . . er, calls it 'it' . . . er, you get the idea).

The first time I saw `it` in a similar construction was in Arc language's aif macro:

        (mac aif (expr . body)
           `(let it ,expr
              (if it
                  ,@(if (cddr body)
                        `(,(car body) (aif ,@(cdr body)))
                        body))))

HN uses it quite a lot, e.g.:

        (defop logout req
           (aif (get-user req)
                (do (logout-user it)
                    (pr "Logged out."))
                (pr "You were not logged in.")))

Anaphoric macros have been used in common lisp since forever.

Thanks for the name! Here's a wikipedia article about them: https://en.wikipedia.org/wiki/Anaphoric_macro

PGs On Lisp details these macros from common lisp. I'm unsure how old they are.

Is it a language feature in that example, or a user defined function/macro? It looks like the latter, but I don't speak Lisp, so I may be wrong.

The latter.

Actually, it can be called a language feature, since it's the macro is defined in arc.arc, the arc lib.

Sounds a lot like Scala's underscore (or at least one usage underscore can mean a few things depending on context). Haven't used Kotlin myself, but I'd agree that sounds like a good thing

Ruby already has perl-like magic variables. Too bad $1 $2.. are already used to hold regexp matches if I remember correctly.

I suspect they could have introduced $it for single-variable blocks and not break the existing parsers.

$ signifies a global variable, so changes are $it would break some existing codebase somewhere.

Thankfully, it's heavily frowned-upon to use global variables.

Reply on news.ycombinator.com