3 ms·

Nice to have you chime in here Jeremy. I personally use CoffeeScript a lot. I also code in Ruby and understand its appeal from that perspective. However I am cu

Nice to have you chime in here Jeremy. I personally use CoffeeScript a lot. I also code in Ruby and understand its appeal from that perspective. However I am curious what your take is on dxbydt's reply below. He makes a very interesting comment about the overhead of objects vs simple message passing/currying/etc.

jashkenas 14y ago
My take is that it's a classic straw man -- you can write inefficient functional code that constantly manufactures and throws away closures ... just as easily as you can write inefficient object-oriented code that constantly manufactures and throws away objects. The point of object-orientation is that "simple message passing/currying/etc" rarely stays simple for long. Eventually your system wants to have many different pieces of data that all share common functionality, and objects are a great way to model that. But if you prefer to work procedurally, and have a big data structure and a bunch of little functions that operate on it -- that's fine too. CoffeeScript and JavaScript support both.
- oinksoft 14y ago
  I note the same in another part of this thread, showing how you can write his JS in less CS code. However, I'd argue that the reason most people are adopting CoffeeScript is for the "class ... extends" as it lets them model their JavaScript code much like they might have in their old Java, and more likely, PHP projects. And once you throw that out, the main draws remaining are default argument values, string interpolation, and the ? operator. The question is, do those benefits warrant the added layer of complexity? Many of us who have worked with JavaScript for a very long time wonder about this, and dread the deeply nested class hierarchies we might encounter in CS projects because CS makes that so _easy_ to do. But bad programmers will write bad code in any language, and I hate to think what a dev who uses `class ... extends` as a crutch would write in plain JavaScript. So, I have both positive and indifferent feelings about CoffeeScript, the only negatives being with the handling of variable scope/shadowing, which is of course opinionated and neither right nor wrong, and the parser itself which makes for ugliness like window.addEventListener 'load', -> # Do stuff ... , false # leading comma is needed above.
  - deleted 14y ago
    [deleted]
  - roopeshv 14y ago
    the only reason i use CS is because I can get away with typing way less than needed. There is a one time cost (huge? or not!) for setting up tooling to compile it automatically. If not anything, typing is the only reason I love CS. Because studies have shown (anyone got links, i know them from greg wilson's talk from CUSEC) 1) Less lines of code - less mistakes 2) You produce same number of lines of code, no matter the language and (not related to studies) 3) less lines to debug 4) if you can deal with the idiosyncrasies of JS, that person can deal with CS quite well. (stawman argument anyone?)
  - danmaz74 14y ago
    I don't know about most people, but I use CS a lot and never use classes... :)
- dxbydt 14y ago
  > "you can write inefficient functional code that constantly manufactures and throws away closures ... just as easily as you can write inefficient object-oriented code that constantly manufactures and throws away objects." Very true, except that it doesn't happen in practice. There's a more elaborate discussion in Joshua Suereth's book "Scala in Depth" on this very topic, because Scala has the exact same problem. A boatload of OO Java guys are now migrating to Scala, bringing their OO with them. Teaching them Scala is trivial, teaching them FP is not. The example Joshua gives is "a cat catches a bird and eats it". How should programmers model that ? What programmers should do is focus on the verbs. So first define a catch function and an eat function. Then compose them like this: catch(...) andThen eat(...). Define a Cat trait and a Rat trait & you are in business. What most programmers will do is focus on the nouns. So they will first define a class Cat {} with two methods catch() and eat(), then a class Bird {}, then wonder about whether there must be some class Animal {} which Cat & Bird must inherit from, except that birds aren't really animals, so...finally they'll create a cat object and a bird object and call cat.catch(bird) and then cat.eat(bird). When the program runs, there'll be many cats & many more birds & all these little objects will unnecessarily bring things to a crawl. This has nothing to do with CoffeeScript the language, which ofcourse supports FP as much as it does OO. Its just that in practice people latch on to the OO aspects of CoffeeScript because that's just how most people process problems.
  - jashkenas 14y ago
    "Doc, it really hurts me when I hit my hand with this hammer. What should I do?" "Stop hitting yourself with a hammer."

jashkenas 14y ago

My take is that it's a classic straw man -- you can write inefficient functional code that constantly manufactures and throws away closures ... just as easily as you can write inefficient object-oriented code that constantly manufactures and throws away objects. The point of object-orientation is that "simple message passing/currying/etc" rarely stays simple for long. Eventually your system wants to have many different pieces of data that all share common functionality, and objects are a great way to model that. But if you prefer to work procedurally, and have a big data structure and a bunch of little functions that operate on it -- that's fine too. CoffeeScript and JavaScript support both.

oinksoft 14y ago
I note the same in another part of this thread, showing how you can write his JS in less CS code. However, I'd argue that the reason most people are adopting CoffeeScript is for the "class ... extends" as it lets them model their JavaScript code much like they might have in their old Java, and more likely, PHP projects. And once you throw that out, the main draws remaining are default argument values, string interpolation, and the ? operator. The question is, do those benefits warrant the added layer of complexity? Many of us who have worked with JavaScript for a very long time wonder about this, and dread the deeply nested class hierarchies we might encounter in CS projects because CS makes that so _easy_ to do. But bad programmers will write bad code in any language, and I hate to think what a dev who uses `class ... extends` as a crutch would write in plain JavaScript. So, I have both positive and indifferent feelings about CoffeeScript, the only negatives being with the handling of variable scope/shadowing, which is of course opinionated and neither right nor wrong, and the parser itself which makes for ugliness like window.addEventListener 'load', -> # Do stuff ... , false # leading comma is needed above.
- deleted 14y ago
  [deleted]
- roopeshv 14y ago
  the only reason i use CS is because I can get away with typing way less than needed. There is a one time cost (huge? or not!) for setting up tooling to compile it automatically. If not anything, typing is the only reason I love CS. Because studies have shown (anyone got links, i know them from greg wilson's talk from CUSEC) 1) Less lines of code - less mistakes 2) You produce same number of lines of code, no matter the language and (not related to studies) 3) less lines to debug 4) if you can deal with the idiosyncrasies of JS, that person can deal with CS quite well. (stawman argument anyone?)
- danmaz74 14y ago
  I don't know about most people, but I use CS a lot and never use classes... :)
dxbydt 14y ago
> "you can write inefficient functional code that constantly manufactures and throws away closures ... just as easily as you can write inefficient object-oriented code that constantly manufactures and throws away objects." Very true, except that it doesn't happen in practice. There's a more elaborate discussion in Joshua Suereth's book "Scala in Depth" on this very topic, because Scala has the exact same problem. A boatload of OO Java guys are now migrating to Scala, bringing their OO with them. Teaching them Scala is trivial, teaching them FP is not. The example Joshua gives is "a cat catches a bird and eats it". How should programmers model that ? What programmers should do is focus on the verbs. So first define a catch function and an eat function. Then compose them like this: catch(...) andThen eat(...). Define a Cat trait and a Rat trait & you are in business. What most programmers will do is focus on the nouns. So they will first define a class Cat {} with two methods catch() and eat(), then a class Bird {}, then wonder about whether there must be some class Animal {} which Cat & Bird must inherit from, except that birds aren't really animals, so...finally they'll create a cat object and a bird object and call cat.catch(bird) and then cat.eat(bird). When the program runs, there'll be many cats & many more birds & all these little objects will unnecessarily bring things to a crawl. This has nothing to do with CoffeeScript the language, which ofcourse supports FP as much as it does OO. Its just that in practice people latch on to the OO aspects of CoffeeScript because that's just how most people process problems.
- jashkenas 14y ago
  "Doc, it really hurts me when I hit my hand with this hammer. What should I do?" "Stop hitting yourself with a hammer."