5 ms·

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 mu

by nas 15y ago

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.

jashkenas 15y ago
It tends to reduce LOC from JavaScript by about 30%-50% ... nothing near this as extreme as this auto-generated version.
shuzchen 15y ago
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.
- azakai 15y ago
  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.
- nas 15y ago
  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 15y ago
    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-and-software-rendering/ http://peter.sh/2012/01/css-selector-profiler-source-mapping...) and Gecko (https://wiki.mozilla.org/DevTools/Features/SourceMap https://wiki.mozilla.org/DevTools/Features/SourceMap - the intern has gone back to school, really?)
schwap 15y ago
Also some of the replacement coffeescript files are just empty files.
chc 15y ago
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`.
HoLyVieR 15y ago
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.
- bullshite 15y ago
  Presumably you have sources to back up this incredible sounding statement.
  - HoLyVieR 15y ago
    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.
    - PLejeck 15y ago
      Beautifully said, truly. The problem isn't the language, it's the program.

by nas 15y ago

jashkenas 15y ago

It tends to reduce LOC from JavaScript by about 30%-50% ... nothing near this as extreme as this auto-generated version.

shuzchen 15y ago

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.

azakai 15y ago
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.
nas 15y ago
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 15y ago
  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-and-software-rendering/ http://peter.sh/2012/01/css-selector-profiler-source-mapping...) and Gecko (https://wiki.mozilla.org/DevTools/Features/SourceMap https://wiki.mozilla.org/DevTools/Features/SourceMap - the intern has gone back to school, really?)

schwap 15y ago

Also some of the replacement coffeescript files are just empty files.

chc 15y ago

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

HoLyVieR 15y ago

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.

bullshite 15y ago
Presumably you have sources to back up this incredible sounding statement.
- HoLyVieR 15y ago
  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.
  - PLejeck 15y ago
    Beautifully said, truly. The problem isn't the language, it's the program.