[RadioactiveMan]

The praise for arrow functions is surprising. They don't enable anything new and their feature - saving a half dozen characters - comes with the cognitive cost of tracking how both types of anonymous functions work and their subtle differences in behavior. It's not worth that price.

[johnchristopher]

I am diving back into node lately and it's really annoying to decipher the async and promises styles that are peppered with different anonymous function styles.

I too stick to the most explicit version (function($foo)).

It's the same for command line arguments, I have an easier time remembering words (--preserve-permissions for instancem --volume, etc.) than letters if I don't use the interface enough.

[Cthulhu_]

This is a problem in a lot of programming languages nowadays; they borrow features and syntax from other languages without those new features superseding others, and without providing a mechanism to force one syntax over the other.

So that's why we now have half-assed OOP in Javascript, we have Scala which is basically all programming languages ever, etc. Meanwhile, Go is still fighting a lot of requests to add language features, knowing full well the complexity added to the compiler (and more importantly the cognitive overhead for developers).

[oaiey]

The art of language design is staying true with its own established patterns. C# fights this battle with primary constructors or combined patterns.

[earthboundkid]

That’s a weird choice. Arrow functions in JS don’t redefine ‘this’ like regular functions, so if you don’t use them, you waste time working around the redefinition.

[hombre_fatal]

Also, if you default to `() => ...` for anonymous functions, then you can reserve anonymous `function() { ... }` for the rare times you actually want peculiar `this`. Same reason it's nice to default to `const` so that `let` becomes a signal for the bonus feature of reassignment.

[johnchristopher]

> Same reason it's nice to default to `const` so that `let` becomes a signal for the bonus feature of reassignment.

Code documentation should be clear and concise, not to be deciphered through the code author's take on the meta meaning of reserved words.

[earthboundkid]

No, const inside of a function is a complete waste of time. There has never been a bug that would be prevented by const inside a function.

[dpcx]

The big thing enabled by them is not needing to `use ($variable)` to pull a variable in to the scope; however, IMHO, that actually then adds cognitive overhead to the system - I personally will stick to "fully" generated closures.

[johannes1234321]

This is a matter of the situation. For a single statement this can be extremely clear, if the function becomes longer being explicit is nice. And at some length the thing should have a name.

    usort($data, fn($l, $r) => $this->foo($l, $r));

vs.

    usort($data, function($l, $r) use ($this) { return $this->foo($l, $r); });

vs.

    usort($data, [$this, 'foo']);

[deergomoo]

> For a single statement this can be extremely clear

PHP arrow functions can only contain a single statement and always implicitly return, so that sort of thing is exactly what they're designed for.

Although worth noting with your second example that you haven't needed to capture $this in closures since 5.4, and in fact it is an error to do so now (though I'm not sure when that was introduced).

[johannes1234321]

Using $this was just a simple example where all three cases could easily do the same. Make it $bar :)

Anyways: People are capable of writing loooooong expressions (chaining with && can be good to handle errors from multiple operations in one place (till you have to figure out which specific condition broke)) Thus "single expression" isn't neccisarily short ;)

Anyways: Point is "it can be useful, but developers should think, what they are doing" Perl's "there's more than one way to do it" probably goes too far, but being able to focus on the relevant parts and being able to providing the amount of context needed are good things.

[leetbulb]

This is the correct answer. Having the option of implicit by-value scope binding is nice. However, I do agree that having the two does add to the overall cognitive cost, albeit not significantly.

[donatj]

I’m with you here. I’d rather have a single uniform syntax for anonymous function.