Scoping in CoffeeScript and JavaScript

I'm sympathetic to your point, but this seems entirely wrong in context, because JS exhibits all the flaws you decry and more.

JS is often an ambiguous language, and often behaves poorly in edge cases. Even in the specific example (variable scope) the JS rules are arcane, poorly documented, confuse the hell out of even experienced JS programmers, and are hard to debug. Unless your argument boils down to "I know JS much better than Coffeescript, so its edge cases are less surprising to me", where in the world is the "win" from switching to Javascript from Coffeescript?

For what its worth, I've used Coffeescript more than you, and I find it does have the problems you state, as do pretty much all languages; it's one of degree. Coffeescript is worse than, eg, lua, but better than, eg, Javascript. And of the feasible languages to write code that will run in the browser, Coffeescript is the best choice (if the decision is purely based on "will my code do what I want/are edge cases going to bite me unpleasantly"). But that's just my personal experience. :)

Not my experience in 3 years writing CS; can't even remember last time I blamed something on the language. There are very little rough edges if you use a consistent, good coding style.

I'm waiting for ES6 to abandon ship, might take a while.

Examples please?

I've done lots of CoffeeScript in the last year and I had no gotchas at all. I'm able to predict the JS output of my Coffee files accurately and it never surprises me (well, once, when I ran into a compiler bug).

If Jeremy and the rest of the CS core contributors documented things like this it would cause more confusion. Look how contrived the examples in the blog post are to begin with.

That is not quite the case in javascript, `var` creates a binding (also `let` in ES6), and assignment assigns to the binding.

There is the issue that assigning to an non-existant binding creates a global one, but strict mode will turn it into an error and linters have little issue recognizing and warning against it either.

The main reason to use Coffeescript is in place of Javascript, which already has plenty of warts to avoid, many more serious that this issue, and many of which Coffeescript helps to alleviate. If time spent on something is important to you, Coffeescript can help save a great deal through it's expressiveness, especially in areas where vanilla JS is awkward (eg. OOP).

Personally, with relation to the scoping issue, I tend towards using Underscore's higher-order iteration functions (each, map, reduce, etc.) in most cases instead of Coffeescript's `for`, which eliminates this issue entirely due to the scoping of the anonymous functions passed to them.

[1] Like representing datastructures. Or that subclass-without-constructor subtlety (https://github.com/jashkenas/coffee-script/issues/2956).

The value of coffeescript is that when written well you can get a very high signal to noise ratio in your codebase. When I say "noise", I'm referring to low value syntax and boilerplate, things like:

var someFunc, _this; _this = this; someFunc = function(){ return _this.foo; }

By comparison, the coffeescript is: someFunc = => @.foo

In the coffeescript example, it is immediately obvious what 'someFunc' does. A trained javascript developer will be good at filtering the junk, and extracting the bits that are actually meaningful and important. But any time you are parsing through a bunch of junk to get to the meaningful stuff, you are opening the door to make mistakes, and increasing the time it takes to comprehend/load the code into your brain.

Another important benefit of readable & concise code is that you can hold more of it on a screen at a time, which makes it easier to keep a full class in context and/or work on a small screen (e.g. laptop on the go). I would much rather work with a 100 line coffeescript file than a 300 line javascript file.

This is the same reason I really love the underscore library (not coincidentally also an Ashkenas product). Everything it does is something any competent JS developer can do. But it does it in one line, and in a way that is very easy to read.

Incidentally, using a library like underscore with good iterators also avoids a common class of the "variable capturing" problem, as you don't end up using named variables for iteration (opting instead for map/reduce/find/etc). We otherwise use descriptive names in our project, so the chance of a clash is minimal. In my year and a half on the project, I've yet to run into a "variable capturing" bug. Admittedly that does mean that when it finally happens, I probably won't be looking for it.

What are the limitations of the type checker? i.e. does the compiler fully have your back, or are we just talking validating whether or not a method param takes a String vs. an Int?

Coffee is a dream [for me], JavaScript, not so much.

3. is solved in ES6 with `let` (currently working in Firefox, behind a flag in Chrome, no support in Opera, Safari, MSIE or Node). Note that let also 1. isn't hoisted and 2. forbids double declaration (`let x; let x;` is an error)

2) Globals with 'x = 1' throws an error when run in strict mode.

3) They couldn't change the meaning of 'var', but they introduced 'let' which does just that - applies to a block rather than the whole function.

Actually, it does have a meaning. Transcompilers are compilers that compile one language to another language at a similar level of abstraction.

I don't think it does. The JS broken behaviour described in the article is that if you happen to forget the "var" keyword when assigning a variable then you will create a global variable. "let" is great, but it doesn't fix that problem.

Now pass the sunshine juice and follow me back to the drum circle.