7 ms·

For the interested (and with the caveat that I definitely would not suggest it for the Khan Academy's purposes), CoffeeScript does try to address all of the iss

For the interested (and with the caveat that I definitely would not suggest it for the Khan Academy's purposes), CoffeeScript does try to address all of the issues that John raises in his post. Type Coercion: There is no `==` in CoffeeScript. You usually write `if x is y` in order to be particularly clear, but if you're in the mode of most other scripting languages, and you write `if x == y`, it will compile to `if (x === y) {` in JavaScript. John's note about `x == null` being the only useful application of double equals is quite true, and something that CoffeeScript provides in the existential operator: `if x?` Falsy Values: The existential operator helps you ask the question "Does this value exist?" (Is this value not either null of undefined?) ... which covers many of the use cases for having saner falsy values in JavaScript. For example, instead of JS' `if (string) {` ... where the string may be the empty string, you have `if string?` Function Declarations: JavaScript having function declarations, function expressions, and named function expressions as three functionally different things is indeed a wart on the language. Especially so because JavaScript having a single type of function is one of the beautiful aspects that shines in comparison to languages like Ruby, where you have methods, blocks, procs, lamdas, and unbound methods -- all of which behave in slightly different ways. CoffeeScript only provides JS's function expressions. Block Scope: This is a tricky one, because unfortunately it can't be emulated in a performant way in JavaScript. So all that CoffeeScript can provide is the "do" keyword, which immediately invokes the following function, forwarding arguments. So, if a regular "for" loop looks like this: for item, index in list ... A faux-block-scoped "for" loop would look like this: for item, index in list do (item, index) -> ...

danmaz74 15y ago
As matter of fact, while I was reading the post the first that came to my mind was how much the recommendations reminded me of the CoffeeScript introductory page...
latchkey 15y ago
These are all reasons why I've adopted CoffeeScript over JS. Sure, you can accomplish the same exact things in JS, but they are far more natural with CS and with far less typing. Less typing is less chance for mistakes and bugs and makes an easier learning experience. One other line item is the encapsulation of classes in CS. Doing that in CS is natural and easy to explain to a first year programmer. Accomplishing the same thing in JS is far more boilerplate and much harder to explain why you have to fight the language to accomplish something as simple as a class. Sure, you probably shouldn't learn CS without at least a general understanding of JS, but I definitely think that CS is the next logical step for the second semester.
- gliese1337 15y ago
  Seeing as how one of the arguments for teaching JavaScript first is that it lets you teach about prototypical inheritance before the students get used to class-based inheritance, the complexity of simulating a class in JavaScript is probably not the best objection to using it instead of CoffeeScript. If you teach them CoffeeScript, then you will teach them class-based inheritance just like everywhere else, and miss out on the prototype paradigm.
  - latchkey 15y ago
    I'm ok with missing out on the prototype paradigm. To me, it is a wart for JavaScript. There has been a ton of discussion on why libraries like DateJS, which pollute the Date prototype, are bad. http://stackoverflow.com/questions/4823682/javascript-namespace-pollution-issue http://stackoverflow.com/questions/4823682/javascript-namesp...
    - wwweston 15y ago
      The discussion you're linking to doesn't appear to discuss either general problems with the prototype paradigm or specific problems with adding properties/methods to the Date prototype. The closest it seems to come is a warning about not trying to modify the prototype of an object through its __proto__ property (or, I suppose, .getPrototypeOf), which isn't the same thing.
  - Cushman 15y ago
    Personally, I treat the `class` keyword as a useful (and powerful) macro for constructing prototypes. I imagine if someone thought they were building a 'real' class-based program for too long, they'd be in for a few surprises later on.
  - jashkenas 15y ago
    This is a common misconception. CoffeeScript's "class" keyword is just JavaScript prototypal inheritance. They work and are used in precisely the same way. There's nothing here to "miss".
__david__ 15y ago
I don't understand the (anti) hype about type coercion and the '==' operator. I get a faintly cargo-culty vibe from people when they talk about '===' vs '==', since the examples are usually very strange things that I never see in production. I'm not an expert in JavaScript but I've written a fair amount and a couple largish programs and I've never been bitten by a type-coercion bug involving '=='. The weird subtle bugs I see are usually associated with me using "for (i in a)" for arrays instead of the more ugly C style for loop, which results in "i" being a string (which usually doesn't matter except when using "+" which is sometimes addition and sometime string concatenation). So, is '==' really that bad? Has anyone seen (otherwise) well-written production code fail because of '==' vs '==='?
- neimado 15y ago
  In 15 years of coding javascript I've never had a significant problem with == vs ===. If anything using === got me into more trouble than using ==, but it really depends on coding style and making other mistakes that would cause a problem down the line with ===. If your coding style doesn't lead you into those mistakes you'll never see them, but other might. It's still not a good reason to abandon javascript and go to coffeescript.
- hassing 15y ago
  I spent a lot of time trying to track down bug in a system once (in php) that was caused by this. I don't remember the exact problem but basically it did something like "if(x == 5)" which is true for both 5 and "5" - but later in the code it was important that the value was actually 5 and not "5". But I think the main thing is that for people beginning programming it's better to have less flexibility. In most production system it might not matter that 5=="5" but it's important for beginners to understand how different types work. And it helps give a better insight into how if statements, and boolean logic in general, work.
  - z92 15y ago
    > but later in the code it was important that the value was actually 5 and not "5". The bug was in that part and not in previous if(5=="5") part. Issues like these appear when Java programmers start to code PHP as if it's Java.
gnaritas 15y ago
And made the mistake of making whitespace significant thereby driving off people in droves.
- dextorious 15y ago
  It's 2011. We love significant whitespace now, get on with the times...
  - neimado 15y ago
    No, "we" really do not love significant whitespace.
  - gnaritas 15y ago
    No, we don't. Kids who don't know better might think it's cool; it isn't.
    - dextorious 15y ago
      Yeah. Because only kids use and love Python and like the significant whitespace, right? And Haskell with it's significant whitespace --yeah, that's another language for "kids who don't know better"... Anyway --you're a Smalltalk guy. How do you get to talk about weird syntax people don't like? Do many people like interleaving-argument selectors?
      - gnaritas 15y ago
        You're mistaken if you don't think a shit ton of people dislike Python exactly because of significant white space as well as it being the source of a great many bugs. As for Smalltalk, yes, they do like them, since faking them by passing literal hashes is a common pattern.
        dextorious 15y ago
        """You're mistaken if you don't think a shit ton of people dislike Python exactly because of significant white space""" Those people don't use Python anyway. There are a shit ton of people disliking anything you can think of. I don't know of many people that tried actually USING Python and still dislike the use of whitespace. I also don't think the "whitespace haters" are intelligent about it or have any basis. For one, you should follow EXACTLY the same whitespace conventions in any bracketed language, even C. That is: you should properly indent blocks, and you should not mix spaces and tabs. If someone does not do that, I don't really think many people would like to work with his code. And if he already does that, then Python's whitespace is not any different, it just removes the brackets. """as well as it being the source of a great many bugs.""" I cannot think of ANY bug that can be caused by Python's use of significant whitespace. On the contrary, it prevents a lot of common bugs in bracketed languages (if/else nesting, etc). The only think Python's use of whitespace can cause is compiler error messages (when you have messed the indentation) -- which is totally different from "bugs". So, what bugs are you talking about? Any specific example? """As for Smalltalk, yes, they do like them, since faking them by passing literal hashes is a common pattern.""" Literal hashed are more like named arguments than Smalltalk selectors. For one, elements inside them are optional...
deleted 15y ago
[deleted]
deleted 15y ago
[deleted]
leptons 15y ago
What, no disclaimer that you are actually the creator of coffeescript?? Your comment seems a bit biased to me. But I'd expect nothing less from a coffeescripter. So you think it's better for someone who has no experience coding to have to understand why they would write some code one way, then have to "transpile" to something else to get it to run? Then if something goes wrong they have to figure out how to fix it in two languages? This doesn't sound like something I would recommend for a beginner, or someone experienced for that matter.
- munaf 15y ago
  Probably the reason he said: "...I definitely would not suggest it for the Khan Academy's purposes"
- joblessjunkie 15y ago
  No, he specifically said at the start that he doesn't recommend it to Khan Academy. To me, it reads as if he is simply supporting John Resig's decisions about what parts of JavaScript to teach -- by virtue of having made those same decisions in designing CoffeeScript.
deleted 15y ago
[deleted]
6ren 15y ago
CoffeeScript is a subset of JavaScript with bindings to an alternate syntax (CoffeeScript). John's suggestion is an enforced subset of JavaScript, with the advantage that (some) JavaScript in the wild is understandable; error messages are in terms of the source language (very helpful, more so for beginners); and yields a skill with greater marketability (so far). Why not use the same subset as CoffeeScript? In some cases, this simply forbids some constructs; in other cases it allows a construct, but only in certain contexts. A mathematically precise but implementation-unfriendly definition is: only allow the subset of JavaScript that is the compilation of some CoffeeScript program.
- Cushman 15y ago
  You totally could; that would be "good" JavaScript. No problem with that. Some of us like a cleaner, poetic syntax with significant whitespace and a few useful macros; we like CoffeeScript.
  - deleted 15y ago
    [deleted]
swannodette 15y ago
Block Scope: This is a tricky one, because unfortunately it can't be emulated in a performant way in JavaScript. This is not true. ClojureScript does this and it's plenty efficient. What you lose is mutability of the loop local from inside a closed over function. Given how many people get burned by the JavaScript behavior clearly block scope is expected. I doubt anyone would miss the dubious ability to mutate a loop local via callback. Certainly not as much as I miss control over scope & names in CoffeeScript.
limeblack 15y ago
Javascript in a simple way. http://img856.imageshack.us/img856/306/javascriptinasimpleway.png http://img856.imageshack.us/img856/306/javascriptinasimplewa...

danmaz74 15y ago

As matter of fact, while I was reading the post the first that came to my mind was how much the recommendations reminded me of the CoffeeScript introductory page...

latchkey 15y ago

These are all reasons why I've adopted CoffeeScript over JS. Sure, you can accomplish the same exact things in JS, but they are far more natural with CS and with far less typing. Less typing is less chance for mistakes and bugs and makes an easier learning experience. One other line item is the encapsulation of classes in CS. Doing that in CS is natural and easy to explain to a first year programmer. Accomplishing the same thing in JS is far more boilerplate and much harder to explain why you have to fight the language to accomplish something as simple as a class. Sure, you probably shouldn't learn CS without at least a general understanding of JS, but I definitely think that CS is the next logical step for the second semester.

gliese1337 15y ago
Seeing as how one of the arguments for teaching JavaScript first is that it lets you teach about prototypical inheritance before the students get used to class-based inheritance, the complexity of simulating a class in JavaScript is probably not the best objection to using it instead of CoffeeScript. If you teach them CoffeeScript, then you will teach them class-based inheritance just like everywhere else, and miss out on the prototype paradigm.
- latchkey 15y ago
  I'm ok with missing out on the prototype paradigm. To me, it is a wart for JavaScript. There has been a ton of discussion on why libraries like DateJS, which pollute the Date prototype, are bad. http://stackoverflow.com/questions/4823682/javascript-namespace-pollution-issue http://stackoverflow.com/questions/4823682/javascript-namesp...
  - wwweston 15y ago
    The discussion you're linking to doesn't appear to discuss either general problems with the prototype paradigm or specific problems with adding properties/methods to the Date prototype. The closest it seems to come is a warning about not trying to modify the prototype of an object through its __proto__ property (or, I suppose, .getPrototypeOf), which isn't the same thing.
- Cushman 15y ago
  Personally, I treat the `class` keyword as a useful (and powerful) macro for constructing prototypes. I imagine if someone thought they were building a 'real' class-based program for too long, they'd be in for a few surprises later on.
- jashkenas 15y ago
  This is a common misconception. CoffeeScript's "class" keyword is just JavaScript prototypal inheritance. They work and are used in precisely the same way. There's nothing here to "miss".

__david__ 15y ago

I don't understand the (anti) hype about type coercion and the '==' operator. I get a faintly cargo-culty vibe from people when they talk about '===' vs '==', since the examples are usually very strange things that I never see in production. I'm not an expert in JavaScript but I've written a fair amount and a couple largish programs and I've never been bitten by a type-coercion bug involving '=='. The weird subtle bugs I see are usually associated with me using "for (i in a)" for arrays instead of the more ugly C style for loop, which results in "i" being a string (which usually doesn't matter except when using "+" which is sometimes addition and sometime string concatenation). So, is '==' really that bad? Has anyone seen (otherwise) well-written production code fail because of '==' vs '==='?

neimado 15y ago
In 15 years of coding javascript I've never had a significant problem with == vs ===. If anything using === got me into more trouble than using ==, but it really depends on coding style and making other mistakes that would cause a problem down the line with ===. If your coding style doesn't lead you into those mistakes you'll never see them, but other might. It's still not a good reason to abandon javascript and go to coffeescript.
hassing 15y ago
I spent a lot of time trying to track down bug in a system once (in php) that was caused by this. I don't remember the exact problem but basically it did something like "if(x == 5)" which is true for both 5 and "5" - but later in the code it was important that the value was actually 5 and not "5". But I think the main thing is that for people beginning programming it's better to have less flexibility. In most production system it might not matter that 5=="5" but it's important for beginners to understand how different types work. And it helps give a better insight into how if statements, and boolean logic in general, work.
- z92 15y ago
  > but later in the code it was important that the value was actually 5 and not "5". The bug was in that part and not in previous if(5=="5") part. Issues like these appear when Java programmers start to code PHP as if it's Java.

gnaritas 15y ago

And made the mistake of making whitespace significant thereby driving off people in droves.

dextorious 15y ago
It's 2011. We love significant whitespace now, get on with the times...
- neimado 15y ago
  No, "we" really do not love significant whitespace.
- gnaritas 15y ago
  No, we don't. Kids who don't know better might think it's cool; it isn't.
  - dextorious 15y ago
    Yeah. Because only kids use and love Python and like the significant whitespace, right? And Haskell with it's significant whitespace --yeah, that's another language for "kids who don't know better"... Anyway --you're a Smalltalk guy. How do you get to talk about weird syntax people don't like? Do many people like interleaving-argument selectors?
    - gnaritas 15y ago
      You're mistaken if you don't think a shit ton of people dislike Python exactly because of significant white space as well as it being the source of a great many bugs. As for Smalltalk, yes, they do like them, since faking them by passing literal hashes is a common pattern.
      - dextorious 15y ago
        """You're mistaken if you don't think a shit ton of people dislike Python exactly because of significant white space""" Those people don't use Python anyway. There are a shit ton of people disliking anything you can think of. I don't know of many people that tried actually USING Python and still dislike the use of whitespace. I also don't think the "whitespace haters" are intelligent about it or have any basis. For one, you should follow EXACTLY the same whitespace conventions in any bracketed language, even C. That is: you should properly indent blocks, and you should not mix spaces and tabs. If someone does not do that, I don't really think many people would like to work with his code. And if he already does that, then Python's whitespace is not any different, it just removes the brackets. """as well as it being the source of a great many bugs.""" I cannot think of ANY bug that can be caused by Python's use of significant whitespace. On the contrary, it prevents a lot of common bugs in bracketed languages (if/else nesting, etc). The only think Python's use of whitespace can cause is compiler error messages (when you have messed the indentation) -- which is totally different from "bugs". So, what bugs are you talking about? Any specific example? """As for Smalltalk, yes, they do like them, since faking them by passing literal hashes is a common pattern.""" Literal hashed are more like named arguments than Smalltalk selectors. For one, elements inside them are optional...

deleted 15y ago

[deleted]

deleted 15y ago

[deleted]

leptons 15y ago

What, no disclaimer that you are actually the creator of coffeescript?? Your comment seems a bit biased to me. But I'd expect nothing less from a coffeescripter. So you think it's better for someone who has no experience coding to have to understand why they would write some code one way, then have to "transpile" to something else to get it to run? Then if something goes wrong they have to figure out how to fix it in two languages? This doesn't sound like something I would recommend for a beginner, or someone experienced for that matter.

munaf 15y ago
Probably the reason he said: "...I definitely would not suggest it for the Khan Academy's purposes"
joblessjunkie 15y ago
No, he specifically said at the start that he doesn't recommend it to Khan Academy. To me, it reads as if he is simply supporting John Resig's decisions about what parts of JavaScript to teach -- by virtue of having made those same decisions in designing CoffeeScript.

deleted 15y ago

[deleted]

6ren 15y ago

CoffeeScript is a subset of JavaScript with bindings to an alternate syntax (CoffeeScript). John's suggestion is an enforced subset of JavaScript, with the advantage that (some) JavaScript in the wild is understandable; error messages are in terms of the source language (very helpful, more so for beginners); and yields a skill with greater marketability (so far). Why not use the same subset as CoffeeScript? In some cases, this simply forbids some constructs; in other cases it allows a construct, but only in certain contexts. A mathematically precise but implementation-unfriendly definition is: only allow the subset of JavaScript that is the compilation of some CoffeeScript program.

Cushman 15y ago
You totally could; that would be "good" JavaScript. No problem with that. Some of us like a cleaner, poetic syntax with significant whitespace and a few useful macros; we like CoffeeScript.
- deleted 15y ago
  [deleted]

swannodette 15y ago

Block Scope: This is a tricky one, because unfortunately it can't be emulated in a performant way in JavaScript. This is not true. ClojureScript does this and it's plenty efficient. What you lose is mutability of the loop local from inside a closed over function. Given how many people get burned by the JavaScript behavior clearly block scope is expected. I doubt anyone would miss the dubious ability to mutate a loop local via callback. Certainly not as much as I miss control over scope & names in CoffeeScript.

limeblack 15y ago

Javascript in a simple way. http://img856.imageshack.us/img856/306/javascriptinasimpleway.png http://img856.imageshack.us/img856/306/javascriptinasimplewa...