[mantrax4]

So what's if it's shorter. You'll run out of screen? You'll wear down your keyboard?

If you don't like typing it, have a macro. Otherwise, as Objective C shows, the verbosity of code is not relevant at all. It's what it says and what it does, which is.

[ajanuary]

You realise the equivilent Objective-C syntax is ^{} right?

And access modifiers are + and - rather than static and nonstatic.

Objective-C definitely isn't above using lightweight syntax. Where it favours verbosity is APIs.

[mantrax4]

I realize it, right.

But I hoped you'd see beyond the direct comparison of lambdas with Objective C's blocks.

I'm saying that short code doesn't automatically translate to more readable or better code, Objective C's message syntax is the proof (if I have to be painfully specific about it).

I write a lot of JS and typing out "function" or "return" was never on the list of things I found a problem, despite I also work in C#, which uses the short => variation.

[ajanuary]

The parent wasn't saying code should be short, they were saying the syntax for lambdas should be short.

Yes, short code doesn't automatically translate to readible code. But neither does long code.

You can't wheel out objective-c's fondness for long self-documenting message names as self-evident proof that the syntax for lambdas must be verbose.

Long message names are good because they let you clearly describe what is otherwise a big black box of unknown behaviour.

The syntax for a lambda will always be a lambda, so it doesn't need to be spelt out explicitly each time. Shorter syntaxes such as used by Haskell are easier to visually pattern match on and so can actually aid comprehension.

It's not as simple as longer is always better and anyone who disagrees is obviously foolish and lazy.