Node.js stdlib ported to CoffeeScript (6,501 additions, 15,896 deletions)
github.com
github.com
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.
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.
Work is underway since August to implement it in WebKit (http://peter.sh/2012/01/css-selector-profiler-source-mapping...) and Gecko (https://wiki.mozilla.org/DevTools/Features/SourceMap - the intern has gone back to school, really?)
Its not even funny anymore.
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.
I could explain why omitting an ending delimiter is an issue, or how easy it is to add a new line or space, but the image does a decent job.
http://img856.imageshack.us/img856/306/javascriptinasimplewa...
Now guess which of the three Javascript examples is generated by.
foo -> bar 'foo', -> 'bar'
CofeeScript isn't pretty very clear.
foo -> bar 'foo', -> 'bar'
CofeeScript isn't simple with anonymous function creation.
foo -> bar 'foo', -> 'bar'
foo(-> bar('foo', -> 'bar'))
The point is an ending delimiter would greatly benefit CoffeScript.
Although CofeeScript certainly has its perks, anonymous function creating isn't simple then Javascript.
> Telling the user to write something in two different ways,
> depending on the argument being passed, isn't simple.
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":
$('button').click ->
alert "hello"
# Or:
app.get '/', (req, res) ->
res.send 'Hello World'
app.get '/', (req,res) ->
res.send 'Hello World'
?There are horrible ways to write a lot of code, especially in whitespace based languages. What does petty comparisons like this bring to the argument?
Basically it would be a lot easier if a ending delimiter was the default for the language.
Also you didn't account for the widely-deployed technology of paren/bracket matching.
*I use vanilla JS.