Hacker News Reader

Comment by TrevorBurnham | Hacker News Reader

(I'm the author.)

JavaScript can be pretty overwhelming to newcomers. You mention scope, which is a good example of where CoffeeScript actually clarifies rather than hides the underlying semantics.

The most important thing to understand about scope in JS is that only functions create scope. This is very different from C and Java, and since JavaScript looks like C and Java, that difference is surprising (see e.g. http://www.adequatelygood.com/2010/2/JavaScript-Scoping-and-...). When you learn the same rule in CoffeeScript, it feels a lot simpler. And that understanding can carry over to JS.

Granted, the compiler is generating the `var` keyword for you, but the mapping is trivial. What's important is that scoped variables have the same behavior in both languages.

View on HN

This is tangential to the main thread, but the weirdness that is hoisting surely confuses a lot of people. (To clarify: hoisting seems to me to be more or worse than just "there's no block scoping.") Just now on my the subway ride home I came across this example from David Flanagan's JavaScript: The Definitive Guide:

    var scope = "global";
    function f() {
        console.log(scope); // Prints "undefined", not "global"
        var scope = "local"; // Variable initialized here, but defined everywhere
        console.log(scope); // Prints "local"
    }

I'm someone who uses Javascript only occasionally, and I'm trying to learn it better. But I thought I understood scope just fine: no block scope, function scope, lexical scoping within functions and nested functions. I may have read about "hoisting" before, but honestly it never sunk in until today.

So I'm assuming that Coffeescript always compiles down to Javascript where variables are explicitly hoisted upwards in declaration? (Answer appears to be yes from a few quick tests here...)

I don't see how adding a completely different syntax layer and compilation makes coding in JavaScript less overwhelming.

Using jslint eliminates item 1.

Item 2 is a stupid language quirk. Guess what, Coffeescript is a whole new layer of quirks.

Aside from item 4, the rest are based on a mistaken idea that reducing typing somehow is a huge advantage. (I don't know, it may be for some people but I'm either too fast a typist or too dumb a programmer.)

CoffeeScript is probably very appealing to some people because it imports coding conventions from some other language (Ruby I guess) that they like. I happen to like JavaScript and running code through jslint once in a while is a heckuva lot less annoying than having to compile code and deal with debugging "assembler".

Nice article Trevor. But you could have avoided the last statement creating unnecessary FUD in the minds of Rails users.

Ha, yeah, but I did want to mention the Rails 3.1 support somewhere (a vote of confidence in CoffeeScript from the highly respected Rails team); given that, a link to http://doihavetousecoffeescriptinrails.com/ seemed the best way. Rails people have a good sense of humor. I hope...

All I'm thinking is that people should start using JSLint instead of making up languages on top of JS. That will catch most of the bugs due to common misunderstandings of the language.

JSLint can't solve the "I forgot to include a frickin' explicit return again" problem, can it?

That's a first world problem of ruby devs I think. When you're used to it, you never forget to write return statements.

Ruby is far from the only language that is commonly used without explicit return statements (and it at least has them). It's just currently the most popular one.

Agreed. I hardly think that people who haven't used languages like Ruby or Coffeescript (with implicitly returning the last expression) ever forget return statements in a way where everything would be okay if they just added a "return" keyword. When I use Ruby and Coffeescript, I consciously have to think "no, I _shouldn't_ write return this time"; I find it hard to believe that, without using a language like this, anyone would just write an expression and expect it to be returned. I could see an argument that if you're returning the application of a function, but it has always seemed extremely natural to me that I think about what I'm returning when I write a function; I actually always have a little bit of trouble adjusting to writing Ruby-style return-less code.

it depends on how you think of functions... If you think of everything as an expression, of course it has some kind of value.

That being said I prefer not to have to write "return" but work plenty with languages outside of ruby and have no issues writing return when necessary.

> it depends on how you think of functions... If you think of everything as an expression, of course it has some kind of value.

Sure, and functions by definition return a value. I know programming isn't math, but the notion of a "void function" is somewhat of an oxymoron.

Ruby, Lisp, Smalltalk, Python, Forth, Perl... Nearly anything that's not a descendant of C or Basic lets you write in terms of expressions.

It also can't solve the "`function () { return … }` is syntactically very heavy" problem.

At JSConf yesterday, Brenden Eich (creator of Javascript) specifically said he thought CoffeeScript's syntax was fantastic. He also stood on stage with the CoffeeScript author while he talked about ways to get errors in CS to return line numbers in CS source, rather than JS.

This is why I think 'let' pretty much fixes (or maybe sanitizes) scoping in JavaScript (see e.g. https://developer.mozilla.org/en/New_in_JavaScript_1.7#Block...). In summary, it allows you to define variables per block.

Unfortunately, it's a feature only available in Mozilla's JS engine at the moment.

Reply on news.ycombinator.com