It's a joke commit, with auto-generated CoffeeScript from a conversion tool.
About 3,700 deletions come from files that were erroneously replaced by empty files. Another 1,400 or so are from removing the license comment at the top of the files, and I'd imagine stripped comments throughout the code add a bit more.
The actual compression ratio seems to be about 20-25%, then. It's likely that idiomatic CoffeeScript, rather than generated CoffeeScript, would be somewhat shorter, but probably not by a drastic amount; I'm no JavaScript guru but the Node.js source doesn't strike me as verbose to begin with.
It seems to me that CoffeeScript is in some ways an attempt to make you write using only - in the words of Douglas Crockford's book title - "Javascript: The Good Parts". The most representative test of its success would thus be rewriting a bad library or tool into CoffeeScript and seeing if it makes the inner badness come to the surface where you can deal with it more easily. If you're already writing disciplined, well-organized JavaScript, than there's no reason to stop.
diffstats are misleading since it looks like he stripped at least 20 lines of comments from each file (license blurb). If Coffescript really did remove that much code I would seriously consider switching. Most research has shown that bug count is pretty heavily correlated to source line count.
While I don't disagree about the point regarding the relationship between line count and bug count, I'm very wary of this move because they still haven't solved the issue on how to debug CoffeeScript with all your error messages being reported back to you in terms of the compiled Javascript.
That's an implementation detail though. Although it's a lot of work to fix, it's not insurmountable. You would need your development browser to support Coffescript natively. It's not really a serious problem if IE7 generates a Javascript back-trace, right?
The important thing is if Coffeescript really does significantly reduce line count and by extension bug rates. I'm not sure it does, generally syntactical sugar doesn't have that effect.
I hope it does. My life seems nicer when writing Coffeescript vs JS.
You don't need to support CoffeeScript natively. The answer is simple and is called source mapping: the output code carries comments that map each line to a line in the source file. This will also work for LESS and any other transpilers.
Yes, until there are proper stack traces in CoffeeScript, it's very hard for me to adopt it for anything. A project I work on has a small amount of CoffeeScript, and debugging problems in that component is the hardest part of the whole project.
The generated CoffeeScript also seems to be a bit more verbose than necessary, though, as it mimics the JavaScript rather closely. For example, there are several cases where instead of `unless @foo?.bar?.baz?` it does `if not this.foo or not this.foo.bar or not this.foo.bar.baz`.
The thing is that it correlates proportionally and if you change from a more verbose language to a less verbose language you only change the proportion, not the amount of bug.
It's not really an "incredible sounding statement", it's just logic. What makes a program more bug prone is the amount of logic there is in it. If it takes you 1000 lines of code in language X and it takes you 500 lines of code in language Y to write the exact same thing, you still have the same amount of logic in both language. The only difference will be the density of the code. Changing the density of the code doesn't change the fact that it will have the same amount of potential bug in it.
The title, of this submission, does not include the fact that thousands of the deletions have very little to do with a port. All licensing is removed. All comments are removed. Significant carriage returns are removed. As well, while LoC is cool to count, promoting line removals that only include an end-of-block ("}") is not, at all, interesting or helpful.
In short, the diff in LoC is just snark to pull at the strings of those that will correlate LoC to bug counts.
What are the advantages of porting Node.js to CoffeeScript? Node doesn't deal with the DOM or browser incompatibilities, which are the stronger reasons to port.
The first instinct of a beginning JavaScript developer on seeing that code would be to reformat it. Not as much with the CoffeeScript code. Also what would the beginning CoffeeScript programmer reformat it to? With the JavaScript code, just removing the extraneous whitespace ought to work.
Also you didn't account for the widely-deployed technology of paren/bracket matching.
> Telling the user to write something in two different ways,
> depending on the argument being passed, isn't simple.
Huh? Sure it is.
Fun fact: Any algorithm you can write in JavaScript can also be written as a single function, full of nested whiles, if/elses, fors, labels and breaks ... does that mean you should write your entire program as a single function? Nope.
I'd like to think that CoffeeScript functions read better without an "ending delimiter":
In any case, if you're interested in using CoffeeScript, but the lack of an ending delimiter is putting you off -- I encourage you to add one in your fork.
That image does a facile job. You could create an equivalent for almost any other language, and JavaScript would be lucky if that was the worst kind of criticism that could be leveled at it.
To be honest, I do not like the idea.
I do not use node much, only played with it a little.
Now about CoffeeScript, I CANT read it, hurts my brain pretty bad, and I fail to see how can it be good.
No, he wouldn't have. If you use === everywhere, you're wasting bandwidth for the extra character. Use === only when the type matters and is likely to be different. 99% of the time, it's when you want to distinguish between undefined, false, 0, and null.
that's a false economy since you must also include however many bytes it takes to explain in a comment that you used == on purpose, and not as a typo- to warn future maintainers not to switch it to === when they run it through JSLINT.
Just take a look at how Mootools or Node.JS takes care of their documentation. Same principal. There is no need for comments/documentation to muck up code.
It takes more effort to understand the nuances of code written using significant whitespace than it does with a C style language where statements are clearly broken up for you. There is less room for ambiguity, and less room for user error.
Maybe the problem lies in your brain, and not coffee script. You aren't a super genius. Humble yourself, admit you suck ass, and try to make yourself better
About 3,700 deletions come from files that were erroneously replaced by empty files. Another 1,400 or so are from removing the license comment at the top of the files, and I'd imagine stripped comments throughout the code add a bit more.
The actual compression ratio seems to be about 20-25%, then. It's likely that idiomatic CoffeeScript, rather than generated CoffeeScript, would be somewhat shorter, but probably not by a drastic amount; I'm no JavaScript guru but the Node.js source doesn't strike me as verbose to begin with.
It seems to me that CoffeeScript is in some ways an attempt to make you write using only - in the words of Douglas Crockford's book title - "Javascript: The Good Parts". The most representative test of its success would thus be rewriting a bad library or tool into CoffeeScript and seeing if it makes the inner badness come to the surface where you can deal with it more easily. If you're already writing disciplined, well-organized JavaScript, than there's no reason to stop.