Many of the issues raised in this article can be solved by "simply" not doing it (admittedly not always a real solution). Just because the language allows something to be done, doesn't mean it should be done that way. Our team has a styleguide that clearly explains good and bad practice, for CoffeeScript AND Python. (It's possible to do bonkers stuff in Python, too, just harder.) It includes things like: use explicit returns, especially when intending to return nothing; include parenthesis unless it's more clear without them (callback as arguments).
Yes, it'd be great if the language were more explicit and made it harder to do confusing thing. But, its core goal is being "just javascript", which prevents some of that explicitness. Also, the flexibility lets the real goal be clarity.
I find
my_object =
key: 'value'
fn: (response) ->
console.log(response)
to be more clear than my_object = {
key: 'value',
fn: function() {
console.log(response)
}
}
because it doesn't have all the crap. CoffeeScript's whitespace syntax is even more helpful when those objects start getting nested. Plus, not having to deal with trailing commas is amazing. At the same time, someFn arg1, arg2, ->
doStuffInACallback()
, arg3
can be confusing, so parens help: someFn(arg1, arg2, ->
doStuffInACallback()
, arg3)
I try to not be "that guy" when it comes to CoffeeScript, but it's easily one of my favorite languages now. All the crap that JavaScript requires is just gone.someFn(arg1, arg2, (-> doStuffInACallback()), arg3)
But far better, if you have any say in it, is making the callback the final argument to someFn.
someFn arg1, arg2, arg3, -> doStuffInACallback()
The thing about coffeescript is that most of the pitfalls being discussed here are very easily avoided with a modicum of experience and sense, whereas in javascript, many of the core issues simply cannot be avoided, and must be worked around in plainly ugly and bug prone ways (see: string concatenation, this/that juggling, "])})]));, just for starters).
I think a majority can grok and parse Python, but the same can certainly not be said for CS. It's unfortunate too, because it has some Good Parts.
Readability is very subjective and depends on the user's knowledge of the language, as well as personal style, or 'accent', if you will. Code written with, for example, leading commas in dictionaries instead of trailing commas just looks bizarre to me and is a little harder to read, to me, even though I like to do something similar and stack colons.
However a lot of criticism seems to come from the fact that the author is a Python programmer and therefor wants CoffeeScript to be more like Python. No, I am not saying something like the author not understanding it isn't meant to be Python, but for example the implicit vs explicit debate is certainly a more philosophical view. Ask people who prefer other programming languages and they will have a different view. Hey, after all that's why there are so many, even if Ruby, Perl, Python, Falcon, etc. have very similar use cases.
My opinion for example is that dynamic languages are very implicit in first place so saying you don't want that (at all) doesn't make too much sense. I also don't have problems reading CoffeeScript, but occasionally had problems with very explicit languages being too verbose which can make it harder to follow. So looks like my mind works slightly different here.
But back to the article. There are lots of valid points. I think coding guidelines, which one should have working in a team, no matter what language could solve some of them. Some points look a bit like mixing different styles on purpose and at least can't see how you could find something like that in the wild. Just because you can code ugly, it doesn't mean you have to, but again that is more of an opinion. Some people like usually verbose languages, because they say they are easier to read, others like ones with shortcuts or where you have multiple options to express things, making it easier to read (for some people). I for example always enjoyed the fact that Perl has unless and until in place of negated if/while.
But that's more what you prefer. But hey, CoffeeScript is all Javascript, so if your team doesn't like it it's (comparatively) easy to step by step switch back.