5 ms·

This article proves not that CoffeeScript is flawed but that Jeff Walker doesn't understand how to use it. For instance, his first example is: # BROKEN

This article proves not that CoffeeScript is flawed but that Jeff Walker doesn't understand how to use it. For instance, his first example is: # BROKEN func 5, { event: (e) -> if e.something 36 else 45, val: 10} Anyone with more than a day's experience with CoffeeScript knows that it's much better to express this with the simpler: # far better func 5, event: (e) -> if e.something 36 else 45 val: 10 Note how just dropping the excessive notation makes the intention clearer while also making the code cleaner. His example on variable capture neatly illustrates a few of the opinions of CoffeeScript that actually make it far easier to reason about code: don't use global variables, and if a variable has the same name, it should refer to the same thing. It's far more confusing to allow rampant variable shadowing. Code that relies on variable shadowing is simply broken. His last example shows a fundamental misunderstanding of not just CoffeeScript, but JavaScript generally. Granted `this` binding can be sometimes confusing, which is why CoffeeScript has a fat arrow (`=>`) to automatically capture `this`.

sAuronas 13y ago
Why not focus on his general point: that CoffeeScript does not fix the problems of JavaScript because it introduces other problems? He obviously knows a lot more than "day's experience". If you make the argument that he needs to learn to write better CoffeeScript then you're lending help to his argument.
- tonyhb 13y ago
  I think that he should at least understand and know the CoffeeScript syntax to argue that it isn't great. If you don't know C, learnt half of it, then moaned that it didn't compile you'd look like a bit of a fool. In this case, it's logical that a comma doesn't go there. A comma would go after the closing `}`, which is optional (and so are commas in objects). If you don't know the rules of a language, I feel like it's easier to criticise wrongly.
- untog 13y ago
  Why not focus on his general point: that CoffeeScript does not fix the problems of JavaScript because it introduces other problems? I think the point is that CoffeeScript does fix some problems of JS, but introduces complications of its own. It's worth it for some, but not others.
ilaksh 13y ago
"More than a day's experience" is not really fair. It took me months to really get used to CoffeeScript, and I certainly left in a few unnecessary commas after the first day. The rest of what you wrote I agree with. But I think the problem is that people are dismissing CoffeeScript before they have learned it, just like I did originally. I now vastly prefer to use CoffeeScript (or rather ToffeeScript these days, but thats another issue) whereas initially I thought that CoffeeScript was a joke. Then I had to learn CoffeeScript because it was used in a library that I needed to understand. It was only _after_ I had invested the time in learning CoffeeScript that I could see the advantages. In fact, up until that point that I had learned it, CoffeeScript _was not_ an advantage for me -- it was a liability, because I didn't know how to use it. When you aren't familiar with a language then whatever advantages it may have are more than offset by the fact that you don't know what you are doing. I think this is a problem that pretty much every new paradigm shares to some degree. It is very difficult for the average person to emotionally get behind the effort to learn a new way of doing things, and psychologically we just aren't wired to make an accurate judgement about whether that will pay off. Judgments and decisions are actually emotional/subconscious and the rationalization comes afterward.
- couchand 13y ago
  Thanks for clarifying my point, since I was a bit brash. The argument you make regarding learning a new language is solid, and I think it can also be applied to new libraries, design patterns or even just coding standards. Now that I think about it, the backwards judgement -> rationalization strategy is one of the more pressing problems facing society, and I was guilty of it just as much by judging the OP first and rationalizing second.
- fat0wl 13y ago
  the minutia of most efficiently optimizing your syntactic sugar to communicate DEEEEP meanings is the most annoying part of the open-source/language community & one of the biggest factors in why i've actually come to like corporate java. i've been on so many RoR interviews where i am dismissed essentially for not knowing enough of cutesy syntax tricks and yet in the Java + plain ol' javascript projects i've worked on I've been exposed to a muuuuuch wider variety of programming design patterns than i ever was in Ruby-land, to the point where i could care less about the tiny semantics these hipsters spout on about one of the few new languages i'm interested in working with now is Clojure simply because they cleanly define libs & then don't have all of this obsessive "syntactic sugar" nitpicking. to make a language / code library usable it shouldn't depend on developers going down a rabbit hole of brackets etc. I understand this is difficult to avoid in the "compile to js"/language pre-processor community but it's why I prefer Dart as a solution. It is an attempt at a clean, robust, simple language rather than a repeat of the annoying language evolution process where devs in the know just talk down to those who don't care to commune with punctuation all day
implicit 13y ago
The argument that "you just don't understand" can excuse any flaw in anything. If someone can reasonably choose to formulate something, and for that formulation to pass static verification but do something totally unexpected, the language is at fault, not the author.
- joev_ 13y ago
  The point is it doesn't pass static verification. It doesn't compile. It's a rather silly thing for the author to argue imho.
  - implicit 13y ago
    Agreed. I was responding more to the assertion that CoffeeScript doesn't have a problem with variable scoping rules. It does and the consequences are scary.
    - couchand 13y ago
      You're right that the scoping rules in CoffeeScript are unintuitive for someone coming from a statically-typed, declare-everything paradigm. But I'd hesitate to call it a problem. It's a feature not a bug that the same symbol in nested scopes always refers to the same variable. As I said previously, I believe code that relies on variable shadowing to work correctly is broken. I've been hit by the scoping rules many times, but every time I ask myself why I'm using identifiers like i, j or x to refer to different variables in nested scopes anyway. Names like that should be reserved for only the tightest of scopes. Is there another aspect of the scoping rules that you're referring to?
      - implicit 13y ago
        I agree that shadowing is bad. Implicitly scoping variables to their lexically-outermost point of use is a terrible solution, though: changing anything in any outer scope can completely change the meaning of code in all nested scopes. That's really really bad. A much better syntax would is to require the 'var' keyword to denote the scope of every variable, but reject shadowed symbols at compile time.
ulisesrmzroche 13y ago
All you did was remove the curly braces and take out a comma that probably didn't compile in the first place though. I don't get what's far better about it. Technically, Coffeescript should know better than to balk at the braces that is abstracting out when they're explicitly declared. And any compiler is going to groan when it gets to that dangling comma.
- couchand 13y ago
  I'm well aware of how little I changed. If I were coding this in my style I'd also move the shorter key/value pair up above the function definition, or more likely simply define the function as a local variable elsewhere. It's very rare that I declare function literals within an object literal. You're right that the comma was the real tragedy. I removed the braces to help illustrate how taking full advantage of the features of the language makes the code stronger. Strictly speaking removing the comma was all that was necessary.
bernardom 13y ago
Rather than downvote, I'm going to comment. I think you could have made your points just as strongly without attacking the author.
- couchand 13y ago
  That's a fair point. In my haste to reply I made too much of a personal attack. The phrasing I should have used is more like what ilaksh said [0], which really gets to the heart of the matter. [0]: https://news.ycombinator.com/item?id=7497354 https://news.ycombinator.com/item?id=7497354
shittyanalogy 13y ago
func 5, val: 10 event: (e) -> if e.something then 36 else 45

sAuronas 13y ago

Why not focus on his general point: that CoffeeScript does not fix the problems of JavaScript because it introduces other problems? He obviously knows a lot more than "day's experience". If you make the argument that he needs to learn to write better CoffeeScript then you're lending help to his argument.

tonyhb 13y ago
I think that he should at least understand and know the CoffeeScript syntax to argue that it isn't great. If you don't know C, learnt half of it, then moaned that it didn't compile you'd look like a bit of a fool. In this case, it's logical that a comma doesn't go there. A comma would go after the closing `}`, which is optional (and so are commas in objects). If you don't know the rules of a language, I feel like it's easier to criticise wrongly.
untog 13y ago
Why not focus on his general point: that CoffeeScript does not fix the problems of JavaScript because it introduces other problems? I think the point is that CoffeeScript does fix some problems of JS, but introduces complications of its own. It's worth it for some, but not others.

ilaksh 13y ago

"More than a day's experience" is not really fair. It took me months to really get used to CoffeeScript, and I certainly left in a few unnecessary commas after the first day. The rest of what you wrote I agree with. But I think the problem is that people are dismissing CoffeeScript before they have learned it, just like I did originally. I now vastly prefer to use CoffeeScript (or rather ToffeeScript these days, but thats another issue) whereas initially I thought that CoffeeScript was a joke. Then I had to learn CoffeeScript because it was used in a library that I needed to understand. It was only _after_ I had invested the time in learning CoffeeScript that I could see the advantages. In fact, up until that point that I had learned it, CoffeeScript _was not_ an advantage for me -- it was a liability, because I didn't know how to use it. When you aren't familiar with a language then whatever advantages it may have are more than offset by the fact that you don't know what you are doing. I think this is a problem that pretty much every new paradigm shares to some degree. It is very difficult for the average person to emotionally get behind the effort to learn a new way of doing things, and psychologically we just aren't wired to make an accurate judgement about whether that will pay off. Judgments and decisions are actually emotional/subconscious and the rationalization comes afterward.

couchand 13y ago
Thanks for clarifying my point, since I was a bit brash. The argument you make regarding learning a new language is solid, and I think it can also be applied to new libraries, design patterns or even just coding standards. Now that I think about it, the backwards judgement -> rationalization strategy is one of the more pressing problems facing society, and I was guilty of it just as much by judging the OP first and rationalizing second.
fat0wl 13y ago
the minutia of most efficiently optimizing your syntactic sugar to communicate DEEEEP meanings is the most annoying part of the open-source/language community & one of the biggest factors in why i've actually come to like corporate java. i've been on so many RoR interviews where i am dismissed essentially for not knowing enough of cutesy syntax tricks and yet in the Java + plain ol' javascript projects i've worked on I've been exposed to a muuuuuch wider variety of programming design patterns than i ever was in Ruby-land, to the point where i could care less about the tiny semantics these hipsters spout on about one of the few new languages i'm interested in working with now is Clojure simply because they cleanly define libs & then don't have all of this obsessive "syntactic sugar" nitpicking. to make a language / code library usable it shouldn't depend on developers going down a rabbit hole of brackets etc. I understand this is difficult to avoid in the "compile to js"/language pre-processor community but it's why I prefer Dart as a solution. It is an attempt at a clean, robust, simple language rather than a repeat of the annoying language evolution process where devs in the know just talk down to those who don't care to commune with punctuation all day

implicit 13y ago

The argument that "you just don't understand" can excuse any flaw in anything. If someone can reasonably choose to formulate something, and for that formulation to pass static verification but do something totally unexpected, the language is at fault, not the author.

joev_ 13y ago
The point is it doesn't pass static verification. It doesn't compile. It's a rather silly thing for the author to argue imho.
- implicit 13y ago
  Agreed. I was responding more to the assertion that CoffeeScript doesn't have a problem with variable scoping rules. It does and the consequences are scary.
  - couchand 13y ago
    You're right that the scoping rules in CoffeeScript are unintuitive for someone coming from a statically-typed, declare-everything paradigm. But I'd hesitate to call it a problem. It's a feature not a bug that the same symbol in nested scopes always refers to the same variable. As I said previously, I believe code that relies on variable shadowing to work correctly is broken. I've been hit by the scoping rules many times, but every time I ask myself why I'm using identifiers like i, j or x to refer to different variables in nested scopes anyway. Names like that should be reserved for only the tightest of scopes. Is there another aspect of the scoping rules that you're referring to?
    - implicit 13y ago
      I agree that shadowing is bad. Implicitly scoping variables to their lexically-outermost point of use is a terrible solution, though: changing anything in any outer scope can completely change the meaning of code in all nested scopes. That's really really bad. A much better syntax would is to require the 'var' keyword to denote the scope of every variable, but reject shadowed symbols at compile time.

ulisesrmzroche 13y ago

All you did was remove the curly braces and take out a comma that probably didn't compile in the first place though. I don't get what's far better about it. Technically, Coffeescript should know better than to balk at the braces that is abstracting out when they're explicitly declared. And any compiler is going to groan when it gets to that dangling comma.

couchand 13y ago
I'm well aware of how little I changed. If I were coding this in my style I'd also move the shorter key/value pair up above the function definition, or more likely simply define the function as a local variable elsewhere. It's very rare that I declare function literals within an object literal. You're right that the comma was the real tragedy. I removed the braces to help illustrate how taking full advantage of the features of the language makes the code stronger. Strictly speaking removing the comma was all that was necessary.

bernardom 13y ago

Rather than downvote, I'm going to comment. I think you could have made your points just as strongly without attacking the author.

couchand 13y ago
That's a fair point. In my haste to reply I made too much of a personal attack. The phrasing I should have used is more like what ilaksh said [0], which really gets to the heart of the matter. [0]: https://news.ycombinator.com/item?id=7497354 https://news.ycombinator.com/item?id=7497354

shittyanalogy 13y ago

func 5, val: 10 event: (e) -> if e.something then 36 else 45