Comment by ianstormtaylor | Hacker News Reader

Comment by ianstormtaylor | Hacker News Reader

Parent Full thread

Have to agree with the OP. Even though I can generally read CoffeeScript I'd much rather have all the code I depend on be on JavaScript because I much prefer contributing to JavaScript code.

I also feel like CoffeeScript encourages incredibly complex practices just because the code can be written in a small amount of space. For example, here's a block of code from the library in question:

  sumOverSumBound80: (sigfig=3, scaler=1, upper=true) -> ([num, denom]) -> ->
      sumNum: 0
      sumDenom: 0
      push: (row) ->
          @sumNum   += parseFloat(row[num])   if not isNaN parseFloat(row[num])
          @sumDenom += parseFloat(row[denom]) if not isNaN parseFloat(row[denom])
      value: -> 
          sign = if upper then 1 else -1
          (0.821187207574908/@sumDenom + @sumNum/@sumDenom + 1.2815515655446004*sign*
              Math.sqrt(0.410593603787454/ (@sumDenom*@sumDenom) + (@sumNum*(1 - @sumNum/ @sumDenom))/ (@sumDenom*@sumDenom)))/
              (1 + 1.642374415149816/@sumDenom)
      format: numberFormat(sigfig, scaler)

Have fun reading that... I think claims that CoffeeScript is a write-only language have very legitimate ground.

I'm not a Javascript expert, and I haven't used CoffeeScript before, but this block of code looks perfectly readable to me (except for that ugly mathematical equation). If this is supposed to be an example of unreadable code, then maybe it's time to learn me some Coffeescript...

Indeed, I've never given CoffeeScript more than a cursor glance, but I'll say that rates much higher in readability than average javascript I've written. If that is ment to be an example of bad pratice....

    sumOverSumBound80: (sigfig=3, scaler=1, upper=true) -> ([num, denom]) -> ->

The many arrows in the first line are confusing to me.

In Javascript, that would be three level of nested function, equally if not more confusing.

I agree, this is the hairiest, least documented part of the API. CoffeeScript makes it easier to read than the corresponding Javascript construction but then again this might be CS encouraging things that wouldn't fly in JS for good reason :)

The pivot table needs an aggregator object per cell, so we need a factory-function to provide one (this is the right-most arrow).

That function needs to know which columns to use as the numerator and denominator, without these being passed in on every invocation, so I used a function-generator that closes over those two values.

The third, almost gratuitous layer of function calls allows one to parametrically generate this function-generator with different formatting options.

This is misleading. Of course like Javascript you can write terrible CoffeeScript code. There are plenty of terrible written Javascript code examples out there.

Absolutely, but you get by like Yen (replied) who think that it's completely readable. Whereas in Javascript you're going to have a much harder time arguing that a triple-nested function that returns an object with other functions inside of it is readable. This exact same code in Javascript would be a laughable offense, but people defend it to the death when it's Coffeescript because the complainers "just don't get it".

http://nodejsreactions.tumblr.com/post/51550250985/discoveri...

Hey, I agree with a lot of what you are saying here, but it seems unfair to cherry-pick a single method like you are doing here. There's a lot of confusing JavaScript out there, too.

Reply on news.ycombinator.com