I've been coding CS for over a year now and I like it, I've never found it hard to debug and it's just easier to read.
1. @ = this
2. -> to => solves almost every context problem
3. Object notation by simply using colons ':'
$('body').css
color: 'red'
background: 'blue'
5. jsondata?[2]?.hierarchy?.url
6. Optional brackets allow very terse/clean code:
setTimeout ->
statement
, 1000
8. Automatic return on last line
9. I also like how CS handles scoping, even though others might not. My very few globals are ALLCAPS and everything else is local scoped. I don't do things like {log, tan} = Math in the global scope just to save a few keystrokes elsewhere.
Add jQuery/Backbone/Underscore/Bootstrap to the mix and you can develop some very large, complex apps with CS in a very clean way. Of course, people may not like some of the above syntax but I love not having to write/parse 2x as much code.
However, it also provides a few new ways to shoot yourself in the foot. Automatic return may be one example. Generally, thanks to terser syntax, the code may become illegible very quickly—especially in an environment with many contributors and little care about coding style.
IMO successful CoffeeScript usage in larger projects requires strict coding guidelines. Maybe the language would even benefit from more ‘centralized’ and opinionated approach, like Python's PEPs.
This is all good and fine until you realize that this will bite your ass when you need to write performance-sensitive code. So you end up with lots of explicit 'return' statements at the end of your functions.
> 9. things like {log, tan} = Math in the global scope just to save a few keystrokes elsewhere.
It's not only for saving keystrokes, but may also be improving performance. Some reason people add `local _G = _G` to the top of Lua source files to speed up access to _G.
For me there's a noticeable productivity and enjoyment boost from the more terse syntax and that makes it more than worth it for me.
http://meta.discourse.org/t/is-it-better-for-discourse-to-us...
White-space sensitive languages are great because they reward you for writing with style, plus you don't have to worry about matching and aligning braces all the time.
Lots more discussion here: https://news.ycombinator.com/item?id=3379962
That said, I find almost any issue with writing JavaScript can be easily mitigated by utilizing JSHint, and you get the added benefit of sticking with the base language, which is better because if you're writing raw JS everyday, your skills are more transferable than if you're writing CS every day if only for the fact that you can still write JS in a CS-only stack, but you can't write CS in a JS-only stack.
Really the problem is implicit declarations of any sort; they're great for one-liners, but they really suck when you're writing real software.
[But if you've gotta have 'em, please, at least don't copy Python...]
It's actually a funny thing -- out of all of the folks who actually have tried playing around with CoffeeScript in earnest (participated in issues or the mailing list), I can count on the fingers of one hand the number who have actually disliked working with the scoping semantics. There's a far larger number of folks who like to worry about the scope semantics without ever having tried it.
If you want to have var with the same name as something in an outer scope, there are ways to do it, specifically an IIFE.
Here's an article for you: https://github.com/raganwald/homoiconic/blob/master/2012/09/...
Enforcing best practices by throwing errors where other languages wouldn't (like Go does) is one thing. Enforcing them by introducing difficult-to-track bugs into code that happens to be in the same file as other code which uses bad practices is another. This is a bug, not a feature.
My point is that as unfortunate quirks go, this one isn't actually that big of a problem in practice, especially if you know to watch out for it and take simple steps to protect yourself from it.
Please don't say something along the lines of, 'If you hire bad coders, what do you expect to happen?' Bad coders are almost inevitable, and their harm should be confined to code they actually write. Their bad code shouldn't have spooky action at a distance on good code someone else wrote.
Of course you can. You simply enclose the block in an immediate function (using "do") and declare your local variables as parameters to the function. Do that, and it is impossible for any outer scope to screw your code up.
If you're working on a project where lots of coders of questionable aptitude are going to have commit access, you make declaring local variables this way a required convention.
If you're working on a project where changes get approved by a small number of capable maintainers, then you:
1. Do not allow commits that create short or common names (i, x, arr, log, etc.) in high scope levels, and
2. Require that short or common names in inner scopes be declared using local scoping via "do".
Now, should CoffeeScript give some nicer sugar to encourage this kind of local variable use? Yes, probably. But it is incorrect to say that CS doesn't give you the tools to protect yourself from outer scope pollution.