> set(User, function() { return {name: "John"}; }, silent: true);<p>That's not even valid JavaScript, so I would not expect that. It is also somewhat standard that lambda-like operators eat as many tokens as possible.<p>But I agree with many points. The anonymous function sugar is extremely handy in callback-oriented programming. I wonder if a small syntax extension to JS, consisting of Python like indetation and Ruby like blocks would ease the biggest pains:<p><pre><code> function f(some_param, callback)
bla()
return 1
f(10) |u,t| ->
callback_code_here
</code></pre>
The call to f would receive the anonymous callback as its last argument. Callbacks in other positions, or multiple callbacks could be named:<p><pre><code> f(10, success, failure)
succss: |data| ->
console.log("Success!", data)
failure: |error| ->
console.log("Error: ", error)</code></pre>
While I love CoffeeScript, the always-implicit-return thing is my biggest pet peeve. The language really needs a non-implicit-returning arrow like -/> , if nothing else so that you can make one liners that don't return a value.<p>Unfortunately, this isn't the direction they want to take the project in. The reasoning is that in CS, all functions should ideally have a return value. I think that's silly, since you have to contend with the fact that it's supposed to interoperate with JS, and plenty of builtins and JS libraries <i>don't</i> behave as if every function has a return value, but what can you do?
<p><pre><code> isLargerThanSix = if x > 6 then yes else no
</code></pre>
You don't need CoffeeScript to do something as redundant as that, since comparison operators return a boolean:<p><pre><code> var isLargerThanSix = x > 6
</code></pre>
Of course, CoffeeScript doesn't even offer an improvement for the level of explicitness in the example, since it removed the ternary operator. This javascript is invalid CoffeeScript:<p><pre><code> var isLargerThanSix = x > 6 ? true : false</code></pre>
<p><pre><code> I certainly agree that CoffeeScript has a bad predictability - it is full of surprises.
</code></pre>
This 100% captures my experience, especially when it comes to interstitial whitespace sensitivity
I don't really understand this "bad predictability" thing. If you leave out parens, CoffeeScript always wraps to the end of the line, simple as that. Hard to visually parse at first sight in certain scenarios? Use parens, that's what they're there for. Problem solved. I'd absolutely hate it if CoffeeScript was inconsistent in how it handled these things, but it really is not.
CoffeeScript and co. ensure new developers who adopt those languages never actually be proficient in JavaScript. Its not a good thing. Perhaps its me, but I just don't get why I'd want to write in one language in order to get code in another. Why not just learn the target language?
And please don't bring up the "You write C which gets compiled to assembly or Python which ends up as C" etc. Its not the same thing. JavaScript is not Assembly and its not Machine Language. Its a very simple language and its quirks can be learned quite easily. Its not that more verbose than CoffeeScript. Don't get me wrong, I think CoffeeScript's syntax is nice, but its nice in an academic kind of way, not in as a replacement for a language that if you work and develop for the browser, you should know very well and be friends with. Its a dangerous short cut.
CoffeeScript is more readable if you follow Visual Basic paren rules. Visual Basic, at least the one I used way back when, differentiates between functions and subroutines. Functions whose return values are used in an expression must use parentheses. Subroutines and functions used as subroutines omit parentheses.<p>Example, I often see this. In this trivial example the intent is simple. In real code this style is unnecessary cleverness.<p><pre><code> a b c, d e
</code></pre>
In VB, since the return value of `b` and `d` are used, parentheses must be added<p><pre><code> a b(c, d(e))</code></pre>
You can replace<p><pre><code> function(data) { return doSomething(data); }
</code></pre>
With<p><pre><code> doSomething
</code></pre>
Named functions are just as first-class as anyonymous ones...