JavaScript is crying out for a way to write functions more tersely. I’ve added my suggestion to the debate, and was vaguely aware that Mozilla had implemented “function expressions”. It wasn’t until I saw their use in the (excellent) ProtoVis examples that I realized how stomach-churningly bad the syntax for them is. Instead of dropping the word function from the declaration of lambdas, they kill the { } charachters, leaving the big visual turd at the front of the lambda while simultaneously omitting the symmetrical visual aid that allows programmers to more easily spot missing terminators.
Oof.
It’d be one thing of the feature saved enough effort (typing) to justify the confusion, but it doesn’t. Bitter syntactic sugar in a language that’s already complicated by whitespace issues should be avoided.
10 Comments
I hope you didn’t overlook the fact that it makes the return statement implicit as well.
This discussion may be relevant:
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/eb969b7d402b3078/74565b955d56b182
Nope! I didn’t overlook it. Implicit returns are a good feature for any lambda syntax, but I was just sort of assuming that *every* lambda proposal would come complete with implicit return. Under that assumption, I think the critique holds.
According to the language designers, function !== lambda. If you haven’t seen this yet, here is potentially what you’re looking for I assume:
http://wiki.ecmascript.org/doku.php?id=strawman:lambdas
I understand the function != lambda argument, it’s just wrong = )
Unclear what is being proposed, other than just another name for `function`. If that is all, I wonder how that would be implemented in reality. Certainly you couldn’t get rid of `function` completely … backwards compatibility with the interwebs, books, editors… It should be clear that the mixing that would occur, within single “scripts” and in general would be quite confusing, esp. to the new programmer. And if you write non-trivial code, there’s something to be said for being able to scan this fat code and easily pick out the functions — big, unmistakable words that clearly state what is going on (notwithstanding following sentence). Something (less wordy) but equivalent to ThisIsAConstructor() might be useful, as that is a real issue with the language.
I think that “function” should be the first one to go. “return” is probably the next. That’s why I campaigned for different styles for lambdas, or function expressions, or whatever the name du jour is.
The really big WTF is when you find yourself accepting the “terse” syntax because, well, it is a bit more terse, and then run into this scenario:
function () { }
Of course, what can clearly be inferred is that I am defining an anonymous function that returns an empty object literal. Oh wait, that’s just a function with no body, returning nothing.
Now of course, since the parser does not read the {} as an object literal here, this is invalid syntax altogether:
function () { a: 0 }
So in the end, you have to fall back to:
function () { return { a: 0 } }
So yeah, I would pick a different preamble syntax for anonymous functions to eliminate the parser ambiguity.
“function” is unwanted, and so is “return”. Both just add noise.
In some cases, the word “return” doubles the length of the function body. e.g. in ruby, compare:
a.select {|i| i>3 }.map{|i| 2*i}
with
a.select {|i| return i>3 }.map{|i| return 2*i}
I agree with you 100% on this one. They should just get rid of function expressions and implement what you suggested.
If the next version of ES allows backward incompatibility:
fun – as a stripped down lambda-esque function.
\(x) x + 2 – as shorthand for fun(x){ return x + 2; }
One Trackback
[...] This post was Twitted by nathansmith [...]