

Node.js stdlib ported to CoffeeScript (6,501 additions, 15,896 deletions) - jashkenas
https://github.com/joyent/node/pull/2472

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

~~~
leptons
because, coffeescript is a joke

------
dkasper
This kind of trolling should not be on Hacker News, and I definitely can't
believe it got 70 points. Might be time for some more Erlang articles...

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

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

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

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

Work is underway since August to implement it in WebKit
([http://peter.sh/2012/01/css-selector-profiler-source-
mapping...](http://peter.sh/2012/01/css-selector-profiler-source-mapping-and-
software-rendering/)) and Gecko
(<https://wiki.mozilla.org/DevTools/Features/SourceMap> \- the intern has gone
back to school, really?)

------
jashkenas
Darn, this looks like auto-generated CoffeeScript. Much less interesing...

~~~
amasad
Its definitely generated. Just compared some files from the output from
<http://js2coffee.org>

Its not even funny anymore.

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

------
limeblack
Although it is a nice joke, CofeeScript has several issues.

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...](http://img856.imageshack.us/img856/306/javascriptinasimpleway.png)

Now guess which of the three Javascript examples is generated by.

    
    
        foo -> bar 'foo', -> 'bar'
    

The point, is that Javascript is simple in demonstrating what are and aren't
functions because it has an ending delimiter.

CofeeScript isn't pretty very clear.

~~~
jashkenas
To play devil's advocate: Does JavaScript have "several issues", in that it
allows you to write your first example like this?

<https://gist.github.com/1567793>

~~~
limeblack
which of the three Javascript examples is generated by?

    
    
        foo -> bar 'foo', -> 'bar'
    

The point, is that Javascript is simple in demonstrating what are and aren't
functions because it has an ending delimiter.

CofeeScript isn't simple with anonymous function creation.

~~~
jashkenas
FYI, function application wraps rightward to the end of the line, or the end
of the block, so:

    
    
        foo -> bar 'foo', -> 'bar'
    

Means:

    
    
        foo(-> bar('foo', -> 'bar'))
    

But in any case, you wouldn't write it like that.

~~~
limeblack
Telling the user to write something in two different ways, depending on the
argument being passed, isn't simple.

The point is an ending delimiter would greatly benefit CoffeScript.

Although CofeeScript certainly has its perks, anonymous function creating
isn't simple then Javascript.

~~~
jashkenas

        > 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":

    
    
        $('button').click ->
          alert "hello"
    
        # Or:
    
        app.get '/', (req, res) ->
          res.send 'Hello World'
    

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.

~~~
fooandbarify
Jeremy, I don't know much about CoffeeScript but I'm having a really hard time
parsing your last example. Did you mean

    
    
      app.get '/', (req,res) ->
        res.send 'Hello World'
    
    ?

~~~
jashkenas
I did indeed. Serves me right for commenting on the run.

------
mbq
Great, now go and convert Linux kernel to OOC; I'm sure Linus will merge it
right away.

------
lepht
I'd be curious to see whether there's any substantial performance differences

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

~~~
ntime
"hurts my brain" == "don't understand"

*I use vanilla JS.

~~~
djtriptych
If you really used vanilla JS you would have used the typed equality operator
:P. === fo' life.

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

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

~~~
maratd
You put comments in code? I place all comments in a separate markdown file.

~~~
vertr
Could you share a link that describes this? I'm having trouble finding
anything about it.

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

