Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Case Against Using CoffeeScript

ryanflorence.com

Post reply on HN
Print view View original

61–70 of 142 posts

Re: A Case Against Using CoffeeScript

#61

Post by jashkenas »

wycats wrote: post #13
cheald wrote: post #2

The increase in debugging complexity is a fair point, and it does add an extra step in between finding a problem and fixing it. However, in practice, I'm not sure I've ever had this be a major problem; I've had more problems related to bad error messages from the Coffeescript compiler (generally due to significant-whitespace errors) than I have had in trying to associate Javascript to its source Coffeescript. The res…

First-class functions have the `this` problem in every language, and the fat arrow is very nice syntactic sugar for what you have to do anyway Not true. JavaScript's `this` binding is absolutely not the only way to do it. In Ruby: class Foo def hello return proc { self } end end puts Foo.new.hello.call #=> # In Python: class Foo(object): def hello(self): def zoo(): return self return zoo zoo = Foo().hello() print(zoo…

So, this is really interesting...

JavaScript is forced to make the pessimal choice of only ever having dynamic-bound "this", because of that favorite whipping boy ... prototypal inheritance.

If JavaScript had a notion of a class (even as a constructor function + prototype) definition, then it would be possible to tag methods with the correct instance reference, as in Ruby and in Python. Unfortunately, because the standard pattern for defining an instance method is:

    Klass.prototype.method = function() {
      ...
    };
... where the function is an expression just like any other, you have to have dynamic-bound this to make prototypes work correctly by default.

Re: A Case Against Using CoffeeScript

#62

Post by jashkenas »

mjijackson wrote: post #32
cheald wrote: post #2

The increase in debugging complexity is a fair point, and it does add an extra step in between finding a problem and fixing it. However, in practice, I'm not sure I've ever had this be a major problem; I've had more problems related to bad error messages from the Coffeescript compiler (generally due to significant-whitespace errors) than I have had in trying to associate Javascript to its source Coffeescript. The res…

> Which is exactly what the fat arrow does in Coffeescript. Except when there's a regression in the compiler, and then it doesn't. https://github.com/jashkenas/coffee-script/issues/1842 It's all good though, because "Pull requests are always welcome." :P

Yes -- that needs to be fixed pronto, and a 1.1.4 release cut -- which should include both that patch and a fix for Node 0.6's inconsistent "fs.watch" behavior.

Re: A Case Against Using CoffeeScript

#63

Post by Griever »

ryanflorence wrote: post #49
latchkey wrote: post #35

It took me about 3 months of intense CS usage to really get the hang of it. I've written a good 20-30k lines of CS so far for my application, so I've developed a lot of good practices since I started. Now, I can't imagine writing 'pure' JS ever again. I tend to avoid a lot of the one-line comprehensions for the reasons documented in this article (they get difficult to 'parse'). I also tend to write in a more of a Jav…

> if/when browsers natively support CS. They won't, and source maps are not native support. Check out AMD with RequireJS (make sure you optimize) for your "import" stuff. I haven't incorporated optimization yet for the project, but you can see how it works with my snackJS project http://github.com/rpflorence/snack/tree/amd-coffee/lib

IIRC I believe i read from Paul Irish (I could be mistaken) that Chrome is working to support projects such as CoffeeScript for debugging. No idea how tjry plan to implement this, but I found it to be an exciting possibility.

Re: A Case Against Using CoffeeScript

#64

Post by ryanflorence »

YmMot wrote: post #57
ryanflorence wrote: post #54

Earlier quoted context omitted.

Woah, missed a whole section: > This is not a valid construct. By using "of" you are iterating through the keys of dishes, which will inevitable be strings. No, they are objects with properties like "dirty", not strings. Dishes is an object of key value pairs. I've been very active in MooTools, contributed to its source, and have written plenty of my own stuff to know the importance of iterating arrays v. objects pro…

Ok, just to be clear because this comment is ambiguous as to if you understand what I'm saying. The comprehension in your article is not valid, you need to change one thing or the other for it to work. > Dishes is an object of key value pairs Yes, and you are getting the KEYS, not the VALUES. I doubt I need to say this, but per the spec KEYS are ipso facto strings. At the point you do plate.dirty "plate" is a STRING,…

Dishes is an object, a dish is an object. I know what I'm doing :)

    dishes = {
      ryansPlate: { dirty: true },
      yourPlate: { dirty: false },
      hisPlate: { dirty: false }
    }
Now go into the debugger, find the _ref, and then add a break point, inspect it, and you'll see.

Or if it was just JS, you wouldn't have to mess with _ref, you'd just put in a break point right where you were last looking at the code wondering "what kind of object is dishes?"

Edit: Oh snapz you got me!

    for key, plate of dishes
Missed the `key`, post updated. Go ahead an chalk that up to "Ryan doesn't know CS", if you believe it's any more incriminating than missing any ol' arg in a function signature.

Re: A Case Against Using CoffeeScript

#66

Post by YmMot »

ryanflorence wrote: post #64
YmMot wrote: post #57

Earlier quoted context omitted.

Ok, just to be clear because this comment is ambiguous as to if you understand what I'm saying. The comprehension in your article is not valid, you need to change one thing or the other for it to work. > Dishes is an object of key value pairs Yes, and you are getting the KEYS, not the VALUES. I doubt I need to say this, but per the spec KEYS are ipso facto strings. At the point you do plate.dirty "plate" is a STRING,…

Dishes is an object, a dish is an object. I know what I'm doing :) dishes = { ryansPlate: { dirty: true }, yourPlate: { dirty: false }, hisPlate: { dirty: false } } Now go into the debugger, find the _ref, and then add a break point, inspect it, and you'll see. Or if it was just JS, you wouldn't have to mess with _ref, you'd just put in a break point right where you were last looking at the code wondering "what kind…

Sure, and here's the issue:

At the point you do

    plate.dirty
plate === "ryansPlate"

In CoffeeScript the construct for foo of bar

Iterates through the KEYS of bar in turn, assigning them to foo...NOT the values

To be more specific, it iterates through PROPERTY NAMES.

Per the JS spec, property names are always strings (you can't use objects...but you know this I'm just being thorough.)

In your example, you do

   plate.dirty
At this point, plate is equal to "ryansPlate" on the first iteration, "yourPlate" on the second, etc. (well technically the order is undefined, but you get my point)

You want dishes[plate].dirty

To be absolutely clear, I'm don't want to make this out to be anything other than the sort of stupid error all of us make all the time. I'm simply pointing out that I recognize it much quicker because I have a very intuitive understanding of CS at this point. Where you, who are very good at (and used to) JS have a harder time seeing the error.

Likewise, I'm sure that you're aware of the dangers of for-in, I'm simply pointing out that it does no sanity checks so watch out.

Also to be clear, I'm talking about your example as written in the article. Maybe you have some other version that works. Go back to my other comment, I compiled your CS code with the CS compiler. You'll see the error there. If you like I'll make a JSFiddle that demonstrates the problem.

I think you've getting stuck on the fact that in my original criticism I didn't know if dishes was an Array or an Object because it wasn't clear from your code...to be clear it is wrong both ways...so I simply said "it's wrong, something must be changed" apologies if this was ambiguous. Now that you've clarified, it's still wrong...just a particular kind.

Re: A Case Against Using CoffeeScript

#67

Post by jaekwon »

teejae wrote: post #44
jaekwon wrote: post #25

Earlier quoted context omitted.

The arguments you use against CoffeeScript are actually the reasons why I love CoffeeScript and the fat arrow. To see what scope the fat arrow is bound to, all you need to do is scan up the parent scope in the file and look for a thin arrow (or a class declaration). Your "whitespace problem" is my solution.

For classes, I'm still unclear as to why you might even use the thin arrow, lest you're providing a mixin. Thoughts?

The constructor doesn't need one, and there is a small performance hit for binding =>.

Mixins... Can you show me an example?

Times when you need a reference to a canonical function object, like with $.proxy and $.unbind. (CoffeeScript could implement => to set the original function as a property of the bound function)

Added a question on github: https://github.com/jashkenas/coffee-script/issues/1934

Re: A Case Against Using CoffeeScript

#68

Post by jashkenas »

tjholowaychuk wrote: post #38
cheald wrote: post #5

Earlier quoted context omitted.

I dunno. I think that a lot of that is just a matter of developer maturity and code discipline. If you can't recognize a code smell when you're writing code, the problem is probably that you aren't mature enough as a developer, not that the language is bad for allowing it. I don't think that most seasoned developers would look at that 160-column list comprehension, say "okay, that works!" and move on to the next task…

I've seen terrible JS, but I've seen much worse CS. Most programmers have relatively no sense of organization, and when unleashed with CS create things far more nasty than their JS counterparts. nasty: https://github.com/jashkenas/coffee-script/blob/master/src/r... nasty: https://github.com/jashkenas/coffee-script/blob/master/src/o... nasty: https://github.com/jashkenas/coffee-script/blob/master/src/c... sexy: https:…

Unfortunately, in this particular case, the code was equally nasty even when all of those methods were written in Ruby, and has grown nastier over time through pull requests. I think it tells you far more about the author than the language ;)

Re: A Case Against Using CoffeeScript

#69

Post by ryanflorence »

YmMot wrote: post #66
ryanflorence wrote: post #64

Earlier quoted context omitted.

Dishes is an object, a dish is an object. I know what I'm doing :) dishes = { ryansPlate: { dirty: true }, yourPlate: { dirty: false }, hisPlate: { dirty: false } } Now go into the debugger, find the _ref, and then add a break point, inspect it, and you'll see. Or if it was just JS, you wouldn't have to mess with _ref, you'd just put in a break point right where you were last looking at the code wondering "what kind…

Sure, and here's the issue: At the point you do plate.dirty plate === "ryansPlate" In CoffeeScript the construct for foo of bar Iterates through the KEYS of bar in turn, assigning them to foo...NOT the values To be more specific, it iterates through PROPERTY NAMES. Per the JS spec, property names are always strings (you can't use objects...but you know this I'm just being thorough.) In your example, you do plate.dirt…

We replied simultaneously, view my response above, and yes, I'd also do `for own key, plate` in real code (which I think its really awesome).

Re: A Case Against Using CoffeeScript

#70

Post by YmMot »

ryanflorence wrote: post #64
YmMot wrote: post #57

Earlier quoted context omitted.

Ok, just to be clear because this comment is ambiguous as to if you understand what I'm saying. The comprehension in your article is not valid, you need to change one thing or the other for it to work. > Dishes is an object of key value pairs Yes, and you are getting the KEYS, not the VALUES. I doubt I need to say this, but per the spec KEYS are ipso facto strings. At the point you do plate.dirty "plate" is a STRING,…

Dishes is an object, a dish is an object. I know what I'm doing :) dishes = { ryansPlate: { dirty: true }, yourPlate: { dirty: false }, hisPlate: { dirty: false } } Now go into the debugger, find the _ref, and then add a break point, inspect it, and you'll see. Or if it was just JS, you wouldn't have to mess with _ref, you'd just put in a break point right where you were last looking at the code wondering "what kind…

> Go ahead an chalk that up to "Ryan doesn't know CS", if you believe it's any more incriminating than missing any ol' arg in a function signature.

Precisely what I intend to do. Everyone makes little logic errors and whatnot, I was just trying to use this as an opportunity to show that people who are, while not necessarily new, but not super experienced...will have a harder time spotting stuff like this in the language.

This is understandably frustrating, so sometimes it colors some of their opinion.

Post reply on HN