Actually, you don't understand lexical scope

The goal of this diatribe appears to be to justify CoffeeScript's design, but to me it counts against it. To be fair, I have never thought CoffeeScript was worth using, but here's the crux:<p>The pitch: "CoffeeScript is a better syntax for writing JavaScript."<p>The reality: "CoffeeScript does not behave like JavaScript in subtle, non-syntactical ways."<p>It is often suggested that people use CoffeeScript instead of JavaScript. But this understanding of CoffeeScript is inaccurate. CoffeeScript has different semantics from JavaScript, and the obvious expansion of CoffeeScript back into JavaScript is a wrong expansion. A knowledgeable JavaScript developer will make mistakes when making simple changes to CoffeeScript code that they did not write. They will have difficulty fixing bugs in CoffeeScript code.<p>If you like, you can be a CoffeeScript shop. Find senior developers who use CoffeeScript and teach junior developers to use it. Code will be a little easier to write, and, like nerf guns and foosball, you might seem like a superficially cool place to work. Like any new technique, you'll be out on your own. You'll run into bugs, you'll deal with toolchain support, you'll find optimization issues.<p>There are reasons to translate other languages into JavaScript. Macros, static typing, execution in other contexts. CoffeeScript gives you ruby-like syntax... To me, that just doesn't seem worth it.

I'm afraid that this post, while well intentioned, is actually clouding the issue it's attempting to clarify.<p>It demonstrates that CoffeeScript's `do` feature provides a convenient way to create a new scope for particular variables (a thing only possible in JavaScript via an immediately-invoked-function, at least, until `let` arrives) ... which is true, but is also an orthogonal concern to whether or not CoffeeScript's normal mode of variable scoping is lexical.<p>In many of the examples in this post:<p><pre><code> do (foo = 'outer') -&#62; do (foo = 'inner') -&#62; </code></pre> ... all of the variables are local to their function, making it a moot question whether the language is dynamic or lexical. Just as in JavaScript:<p><pre><code> function() { var foo = "outer"; function() { var foo = "inner"; } } </code></pre> ... it would make no difference if the language had lexical or dynamic scope, because there are no variables present here that would need to reach outside of their enclosing function in order to perform variable lookup.<p>Lexical vs. dynamic scoping only comes into play when you refer to an external variable. Whether or not that variable is or can be shadowed is beside the point. Putting parameters aside ... In JavaScript, the variable's identity is the closest "var"-declaration of that variable. In CoffeeScript, the variable's identity is simply the name of that variable, wherever it might occur in the current lexical scope. Both ways are lexical, not dynamic.

One addendum. As of JavaScript 1.7 there is yet another way of declaring a variable. It is called let, and makes var work the way it should have worked all along.<p>Of course you can't rely on people having JavaScript 1.7 in their browser. And even if their browser supports it, if the script tag is not declared correctly, YOUR JavaScript won't be understood to be JavaScript 1.7. So people avoid JavaScript 1.7 features.<p>I now return you to your regularly scheduled flame war.

<i>But that is unnecessary in CoffeeScript, because if you want lexical scope, you already have lexical scope:</i><p>I find that unconvincing -- I like one of Walter Bright's maxims: the simple path should be safe. Unless you're scrupulous about do(), if you do an assignment without the previous definition, there is no error. I'm happy that CS supports it in some capacity though!<p>Second, CS is supposed to be better that Javascript -- and I prefer many of its features. Apparently claiming that conflating variable definition and assignment is fine, because JS complicates scoping in other ways, is missing the boat. I think everyone agrees that JS's scoping is less than ideal, to put it politely.<p>Finally, I don't think we should be posting angry articles. The ad hominems and barbs in there aren't raising the level of discourse. :(

All this comes from the fact that people think for some reason that coffeescript is a javascript variant. Obviously, it has been demonstrated that it's not: syntax is different, semantics are different.<p>Also, users of cs shouldn' t have to think about how one language "transpile" to another. Otherwise what would be the point of using cs? If coffeescript designers have provided a clear documentation of their language behaviour, users should refer to it, and not make wild guesses of how it behaves, or how it translates to js.<p>That said, I'm not an expert of either language.

Can we just implement Python (or anything else, really, hell I'll even take VB at this point) in the browser already and get rid of this monstrosity of a language? Please?

I found the tone of this piece incredibly off-putting. The author substitutes smugness for reason. (Also, his frequent grammatical errors and "swinging dick" comments do not exactly connote a sense of maturity and experience.)<p>According to the article, CoffeeScript does <i>not</i> actually have lexical scope for non-parameter local variable assignment, which is what most people are talking about when they say "lexical scope". CoffeeScript has as much lexical scope as Emacs 23 did (after all, you could use lexical-let, right?). This article is a "holding it wrong" defense of CoffeeScript.<p>If the tone of this article is typical of the CoffeeScript community, I think I'll steer clear from the whole language and stick to JavaScript when I need web scripting.

I really appreciate how Haxe (which targets js) handles this situation. If you want to write js, and stick with block level scoping, it's a great option.<p><pre><code> var k = 1; var foo = function(){ var k = 2; var foo = function(){ if (Math.random() &#62; .5){ var k = 3; } trace(k); }; } [...] </code></pre> ("transpiles" to)<p><pre><code> [...] var k = 1; var foo = function() { var k1 = 2; var foo1 = function() { if(Math.random() &#62; .5) { var k2 = 3; } console.log(k1); }; };</code></pre>

I just had an quepiphany. Is it the lambda/scheme culture of defining scope via lambda and application that made javascript having 'only' functional scope ?

tl;dr - CoffeeScript devs know that if you want lexical scoping you use do.<p><a href="http://coffeescript.org/#try:foo%20%3D%2042%0A(()%20-%3E%20foo%20%3D%2043)()%0Aalert%20(foo)%0A%0Abar%20%3D%2042%0Ado%20(bar%20%3D%2043)%20-%3E%0A%20%20bar%20%3D%2044%0Aalert%20(bar)" rel="nofollow">http://coffeescript.org/#try:foo%20%3D%2042%0A(()%20-%3E%20f...</a>

This may be the first time that I've learn any useful information (do) during one of these CoffeeScript scope battles.

The tone of that rant tells me all I need to know about the Coffeescript community and developers. And yes, that means I'll stay clear of it.

Actually, I don't understand CoffeeScript. The example from the post doesn't even compile, using CoffeeScript 1.3.3:<p><pre><code> do (methods = ['remove', 'show', 'hide', 'stop']) -&#62; for method in methods do -&#62; Frame.prototype[method] = -&#62; for element in elements do -&#62; this[element][method]() Error: In test.coffee, Parse error on line 5: Unexpected 'OUTDENT'</code></pre>

I personally can't stand the style of javascript where each for loop causes a new function scope. It makes debugging extremely annoying. The use of _.each, forEach constructs with function parameters makes debugging all that more difficult. I happily manually type all my for(;;) loops in javascript because when I hit my assertions, I have no problem determining exactly what was going on.

OK, so coffeescript is really slow at implementing "local variables".<p>Humm...

The argument for not introducing a 'var' keyword equivalent seems to be "Javascript's implementation sucks", completely glossing over the fact that really it's the lack of block scoping and the presence of undefined that leads to variable 'hoisting' and related issues.<p>CoffeeScript removes the latter, and the former is a lot easier to introduce once you have explicit variable declaration.<p>Seems kinda a circular argument to me.

Jeremy's reply and the counter reply on the original proggit thread are both very interesting, as is the whole thread if you haven't read it, though the tone is abrasive at times:<p><a href="http://www.reddit.com/r/programming/comments/zx137/coffeescript_devs_dont_understand_lexical_scope/" rel="nofollow">http://www.reddit.com/r/programming/comments/zx137/coffeescr...</a><p>As is his original reply 2 years ago:<p><a href="https://github.com/jashkenas/coffee-script/issues/712#issuecomment-430673" rel="nofollow">https://github.com/jashkenas/coffee-script/issues/712#issuec...</a><p>I think in the end because of the lack of block scope in js he ended up choosing the lesser of two evils really.<p>He does pass it off a little lightly though as if it's a feature. Jeremy's argument ultimately seems to boil down to 'it's easier for beginners', which is true and noble I think, but on the other hand it's a very easy way to introduce bugs.<p>It's easy to have a problem domain where you start slipping up, something like a doc with a list of related_docs that you enumerate through, very easy to call that inner variable doc again.<p>Personally one of the reasons I'm in the camp of favouring explicit variable declaration even if it is a bit of a pita when writing little scripts.<p>If cs ever becomes the next jQuery and everyone adopts it to make dealing with js that little less painful I could see demands for 'var' and 'use strict' being introduced. Though cs seems to be perpetually hovering on the cusp of mainstream acceptance. I think he sees less complaining about it as if you're at a level where you write enough code that if affects you, you'll be able to figure out and fix it yourself.

Well, actually...

Dart!