Hacker News Reader

Comment by pavel_lishin | Hacker News Reader

Is it difficult to debug the resulting code?

Browser implementors are working on making easier to debug all compile-to-JS languages, including regular minified JavaScript code.

https://bugzilla.mozilla.org/show_bug.cgi?id=618650

https://bugs.webkit.org/show_bug.cgi?id=30933

In the meantime, CoffeeScript tries to make debugging easy by compiling to straightforward, readable JS, with meaningful variable names, normal indentation, and all that. Patches to make the output clearer/cleaner for specific bits are always welcome.

Strait forward and readable in many cases but beware:

http://jashkenas.github.com/coffee-script/#loops

To be clear, I think CoffeeScript is an impressive language/abstraction. I just get tired of people selling the Javascript output as always being "straightforward" and "readable".

Beware of what? It does look quite straightforward and readable to me. The JS actually helps me understand the CoffeeScript (note, I have never seen real CoffeeScript code before.) Even the class definitions and destructuring assignment further along are quite comprehensible. I don't even have to qualify that with "for what they do."

What's wrong with those compiled loops?

The only difference from a "hand-written" loop is that you would use `i` and `ln` instead of `_i` and `_len`, and something in context like `numbers` instead of `_results`.

There are a total of 9 references to the `_vars`. I think line noise in the compiled javascript is a legitimate counter argument to the claim that its strait forward and readable.

12 if you count the declaration. You'd have exactly the same doing it yourself, you can at most reduce it to 10 by declaring i and ln inside for().

You're also overlooking the fact that this can be considered an advantage: variable naming for these transient uses is very consistent. When writing JS you could have names all over, even a different one for every loop.

I've maintained the hoisted index variable and cached the length:

    var i, foods = ['toast', 'cheese', 'wine'], foods_length = foods.length;
    
    for (i = 0; i < foods_length; i++) {
      eat(food[i]);
    }

Prefixing variables with an underscore is not an advantage in readability because it lends nothing to the description of what the variable represents. Its another glyph that you have to visually parse before reaching possible meaning.

I didn't say the underscore is good - it's a necessary evil.

I said consistency is good. And you just proved my point.

The reason why all declarations happen at the top of the current function body, instead of inline with the first assignment is because in JavaScript assignment is a statement, not an expression. You can't do this:

    alert(var one = 2);

In CoffeeScript, (nearly) everything is an expression. So you need to be able to do this:

    alert one = 2

By pushing up all the var declarations, all assignments can be themselves assigned, returned, or passed as arguments to function calls directly.

Aren't local variables scoped to be visible within the entire JavaScript function? I thought the recommendation to declare local variables at the top the function was a reminder (or to avoid accidental importing of global variables of the same name)?

I use coffeescript both clientside and serverside (node). Since semantically the coffeescript maps to javascript almost one-to-one, the only debugging difficulty is mapping line numbers in the error output to the location in the coffee file.

Client-side is zero problem because the chrome and firebug developer tools jump you right to the line in the JS file, and you can figure out where the error is there since the compiled coffeescript is very readable.

Server-side has a slight hassle since there's no clickable link, so the line numbers don't help much, but a quick look at the stack trace makes it pretty easy to find where in the coffeescript its referring to.

Have you tried using node-inspector for server-side code debugging? https://github.com/dannycoates/node-inspector

Wow this is incredible, thanks for the tip!

I might take this back later, but so far, not really. I thought it was going to be, I keep expecting to run into crazy debugging hurdles, but they just haven't showed up yet. Maybe I'm still at a naive point in my development, and just haven't done anything that would trip it up, but so far so good.

Hasn’t been so far. We’re using the barista gem, which dumps to a JS file.

Most of the problems we’ve dealt with have been due to using new syntax, figuring out when we need parentheses/how to pass anonymous functions, and so on.

Referring to the compiled output definitely helps, but we’re pretty familiar with JS at this point. Not sure how difficult it would be for those with less experience.

Reply on news.ycombinator.com