JS 1.8 Function Expressions: The Opposite of “Good”

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.


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.


  1. Posted August 6, 2009 at 6:39 pm | Permalink

    I hope you didn’t overlook the fact that it makes the return statement implicit as well.

    This discussion may be relevant:


  2. Posted August 6, 2009 at 6:43 pm | Permalink

    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.

  3. Posted August 6, 2009 at 6:58 pm | Permalink

    According to the language designers, function !== lambda. If you haven’t seen this yet, here is potentially what you’re looking for I assume:


  4. Posted August 6, 2009 at 7:12 pm | Permalink

    I understand the function != lambda argument, it’s just wrong = )

  5. nataxia
    Posted August 7, 2009 at 7:17 am | Permalink

    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.

  6. Posted August 7, 2009 at 1:35 pm | Permalink

    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.

  7. Posted August 7, 2009 at 4:56 pm | Permalink

    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.

  8. Posted August 7, 2009 at 6:51 pm | Permalink

    “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}


    a.select {|i| return i>3 }.map{|i| return 2*i}

  9. cypherpunk
    Posted August 24, 2009 at 4:02 am | Permalink

    I agree with you 100% on this one. They should just get rid of function expressions and implement what you suggested.

  10. kevin c
    Posted December 6, 2009 at 5:58 am | Permalink

    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

  1. By Twitted by nathansmith on August 6, 2009 at 4:50 pm

    [...] This post was Twitted by nathansmith [...]