If you can't debug in CoffeeScript, you can't take it seriously. Even meta-CSS frameworks suffer from this problem when there's errors you have to back-track through a whole layer.
I don't the fact that CoffeeScript can't be debugged until browsers support it. JavaScript errors are bad enough, but until I can get a CoffeeScript source line number in an error I simply refuse.
I'd say this "difficult-to-debug" attitude comes from those who did not actually tried to work with CoffeeScript and just think that would be the case.
We have a lot of code in it already and debugging was never an issue.
Not me so much as others - it's a very common problem I've seen when debugging other people's CoffeeScript code. CoffeeScript is a bit of a different situation than other languages since with other languages, it's the norm (i.e. Ruby) - however, with JavaScript, it is not something inherent in JS, so when people jump from JS to CoffeeScript, there is a disconnect.
What's with the insta-downvotes whenever someone mentions Coffeescript's debugging issues? I am not an active Coffeescript developer, but I thought that debugging line-by-line was prohibitively difficult, especially in the browser. Has this changed? If not, why the animosity?
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.
I'd hardly characterise coffeescript generated js as difficult to debug (even the OO flavoured bits). My experience and that of most others I've seen online is that the mapping from the js that you debug back to the coffeescript that generated is trivially done in your head.
Another pain is (was?) debugging. This might have changed since but back when I tried and rejected using it. But back then, if you had an error at line X it would report the (compiled) JavaScript line rather than the CoffeeScript line - meaning you'd need to figure out which CS code generated what line of JS code in order to hunt down and fix issues.
I agree the other issue with someone like me using CoffeeScript is that first I'd want to really understand Javascript otherwise I'd never be able to trust that I could fix any bugs I ran across, it's another layer of abstraction I essentially don't need.
While this is an issue, it's a pretty minor one from my own (limited) experience using CoffeeScript. It's extremely easy to relate the JS errors to your CS code, since the JS generated is so readable. It's just a little tedious to have to take a look at the generated JS, but not that bad really. Try it out for some node.js stuff and see for yourself.
Also, the issue is being fixed for Chrome/Firefox, which is good enough for dev work.
Can you please give some details about your debugging workflow? I'd love to know what works well, as I've been a bit nervous about making the leap to CoffeeScript for more than just goofing around for this reason. I write a little Python, but I'm not great with JavaScript, and this seems like a barrier.
My biggest problem is definitely the source maps. It took me forever to get them to "work" and while the stack traces are mostly correct, they're often off by a line number or two. This makes debugging ridiculously hard when the line numbers are just "close".
I know this might not sound like a big deal in the grand scheme of things, but I also don't think CoffeeScript really improves on js all that much, so the annoyances of source maps are just not worth it to me personally.
As someone who is doing more and more coffeescript this is awesome. However debugging in the console seemed like the only way I was going to stay fresh in native javascript!
As a year-long CoffeeScript user, I have a few points to rebut:
debugging workflow: he makes a long list of bullet points, when in practice you can find the error directly in your coffeescript code 90% of the time, since you have a clear image of what it's compiling to and errors tend to happen on the piece you're working on. Hopefully source-mapping in Firebug/Inspector will be ready in a few months and end this discussion.
"We Process Images and Symbols Faster than Words": It has been demonstrated that the understanding of text is based on the same principle, we don't "read" words, we identify them. and and or are as much a symbol as == and && (which you still can use if you think they are more visible).
"ugly syntax": the examples are ugly. Don't use a trailing if for long conditions, don't create huge one-line comprehensions. You can do worse in javascript.
if five and six and seven
doSomething()
"bad parts": every language has bad parts, but the example is just bad practice. Just because you can omit return and start an object literal without indentation doesn't mean you should.
reply