Comment by crazygringo | Hacker News Reader

Comment by crazygringo | Hacker News Reader

Wow... despite all of the CoffeeScript programming I've done, I've never come across this, but this kind of "edge" case is totally necessary for variables to "usually" be local, but also still always be able to access closure variables in a higher scope -- which are normally contradictory goals.

In a nutshell... it's totally representative of tons of things in CoffeeScript, in trying to:

a) make things easy for the programmer by removing JavaScript features and syntax

b) to make things easy, make various assumptions in ambiguous syntax situations about a programmer's intent

c) introduce no way to guess or predict which way CoffeeScript will act in "edge" cases like this, when assumptions conflict

d) not bother to document what happens in each edge case, or that there even is any kind of edge case at all -- indeed, to make it sound on CoffeeScript's home page / docs that everything is well-defined, when the reality is just an endless list of mysterious and unpredictable transpilation decisions based on internal undocumented CoffeeScript heuristics

I used CoffeeScript for a full year, and then was very happy never to touch it again. Going back to plain JavaScript might not be quite as concise, but the fact that the code always does exactly what you want it to, no surprises (as long as you know the language), let me program in peace again. With CoffeeScript, there's no way to ever feel like you "know" the language, because these kind of edge-case gotchas will getcha day-in, day-out.

> Going back to plain JavaScript might not be quite as concise, but the fact that the code always does exactly what you want it to, no surprises (as long as you know the language), let me program in peace again.

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. :)

> 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.

When using strict mode, which you should be, you're about 0/4.

Your second incorrect complain is especially galling as ECMA-262 goes to extensive length in specifying it (section 10 "Executable Code and Execution Contexts" of the ECMA-262 5.1 specification)

I don't think I agree with your point. Javascript is a very small language, and while there are a number of gotchas they are enumerable and well-defined.

Central concepts:

- Objects

- Prototypes

- Scope chains

- Closures

- Function.bind, Function.apply/Function.call

Gotchas:

- Behavior of the "new" operator

- Value of "this"

- Type coercion, falsiness of "", == vs. ===

- var hoisting

- if/for/while do not create scope

- function expression vs. function declaration

Many of the gotchas are self-evident if you learn the central concepts.

Exactly. I can deal with "gotchas" and edge cases as long as they're documented and I can memorize them -- which is 100% the case with JavaScript.

The reason I'll never use CoffeeScript again isn't because of its gotchas -- it's because there's no way to learn them. They're not documented. They're not predictable from principles. They're completely hidden.

It sounds like CoffeeScript violates the principle of least surprise [1] for you (and me too.) On the other hand, when I use a language like C# (whose author is also behind TypeScript) I often find myself thinking "it should work this way" and then finding out is does work that way.

[1] https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

> these kind of edge-case gotchas will getcha day-in, day-out

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.

> because these kind of edge-case gotchas will getcha day-in, day-out.

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).

Well the original post is one example, obviously.

But, lots of examples below, all from the first few Google results of "coffeescript ambiguity":

http://ruoyusun.com/2013/03/17/my-take-on-coffeescript.html [section "full of surprises"]

http://ceronman.com/2012/09/17/coffeescript-less-typing-bad-...

http://johnbender.us/2012/11/27/math-envy-and-coffeescripts-... [this is a more formal analysis]

Wait, if edge cases turn you away from a language, exactly what languages do you use and for how long?

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.

Reply on news.ycombinator.com