10 ms·
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
by mantrax4 12y ago
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 12y agoYou 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 12y agoI 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 12y agoThe 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.