6 ms·

CoffeeScript2 - A Redesign of the CoffeeScript Compiler

76 points by netbyte 14y ago

chime 14y ago
This looks like a great project. Wish I would have known about the Kickstarter campaign for it sooner. Can't wait to try it out.
jashkenas 14y ago
Very much looking forward to seeing how this turns out. To view a list of some of the public-facing things Michael wants to change, take a look here: https://github.com/michaelficarra/coffee-of-my-dreams https://github.com/michaelficarra/coffee-of-my-dreams
- GeZe 14y ago
  For those who don't want to wait, most of the public-facing changes listed there are already in LiveScript (http://gkz.github.com/LiveScript/ http://gkz.github.com/LiveScript/) - though with a few more (in my opinion well justified) incompatibilities.
- TazeTSchnitzel 14y ago
  He wants to remove semicolons except where absolutely necessary? Is he nuts? The compiled output shouldn't be relying on an error-correction feature. Especially since it might break minifiers and validators.
  - michaelficarra 14y ago
    That would just be a default in my fork. Since the output will be massively configurable, you can use any style you can imagine, including a single line with all the braces and semicolons and whitespace you want. See http://oai.cwi.nl/oai/asset/10876/10876D.pdf http://oai.cwi.nl/oai/asset/10876/10876D.pdf for a resource on defining grammars for AST to CST transformations.
  - mistercow 14y ago
    I'm not sure I agree that ASI is an "error-correction feature". Die-hard always-semicolon advocates certainly would like to paint it that way, but I think that may be rewriting history a bit.
    - tomku 14y ago
      The ECMAscript standard[1] and the creator of the language[2] are pretty clear about it. From what I know of parsing, anything phrased in terms of adding tokens post-lexing in order to make an invalid parse tree valid as opposed to encoding the semantics in the grammar itself is most definitely an error correction method. I think that a lot of the confusion comes from taking the term "error" personally. Nobody wants to be told that their programming style relies on "error correction" to be parsed, but it's just an implementation detail of the parser, not some kind of qualitative statement about your programming skills. Changing the name does not change how the parser works, and does not make anyone involved a better or worse programmer. [1]: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf http://www.ecma-international.org/publications/files/ECMA-ST... (PDF) , section 7.9 [2]: http://brendaneich.com/2012/04/the-infernal-semicolon/ http://brendaneich.com/2012/04/the-infernal-semicolon/, specifically "The moral of this story: ASI is (formally speaking) a syntactic error correction procedure."
      - mistercow 14y ago
        Fair enough, but a statement like "compiled output shouldn't be relying on an error-correction feature" is only (self-evidently) true if we're using the informal, taking-it-personally connotations of "error correction".
  - ajross 14y ago
    I recognize the minifier significance. But wait, there are validators (!?) that choke on valid (!) syntax?
    - TazeTSchnitzel 14y ago
      Lacking semicolons is an error, most validators error on it unless you tell them to ignore it.
    - mistercow 14y ago
      Also, any minifier that turns valid javascript into invalid javascript is broken, full stop.
      - ajross 14y ago
        Yes yes, but some do, it was a giant flame war, and I'll admit that it can be a practical issue (if not a correctness one) for javascript to rely on automatic semicolon insertion if it means you can't use your minifier of choice. But trying to use a "validator" that validates a languages other than the one you are writing is just plain insane.
- michaelficarra 14y ago
  I just want to make sure people know that those changes are bound for a fork once I reach full compliance with the current compiler. The project's one and only goal is to implement the language exactly as Jeremy's compiler does, but be prettier underneath (more extensible, versatile, configurable, robust, etc).
sirclueless 14y ago
Forgive me for being skeptical, but it seems to me that CoffeeScript is going the way of Lisp: a language by hackers for hackers, with way too many incompatible implementations because each implementer has their own pet features that must be included.
- yuchi 14y ago
  There's already a production ready transpiler, and a big bunch of production code to test against every new transpiler. Why do you think this is going to be a reason for fragmentation? And, by the way, coffeescript is not intended to be a language for hackers (I mean, only for hackers) but for Ruby programmers moving to javascript, JS programmers looking for a more terse syntax and programmers with an eye for terseness. In my opinion it has only two big flaws that need to be targeted by new transpilers: 1) for --> each 2) parens free chainable syntax.
  - mistercow 14y ago
    Well, one reason that it could go that way is that the attitude that the maintainers has had toward feature-creep is "just make your own fork!" That's why we now have more dialects than we can shake a stick at, but it has kept the main branch from becoming PHP.
  - charliesome 14y ago
    Please stop saying 'transpiler'. The CoffeeScript compiler is no less deserving of the term than any other compiler.
    - mistercow 14y ago
      "Transpiler" is a subset of "compiler", so it can hardly be a demeaning term. A transpiler is simply a compiler that translates code from language A to language B where A and B have roughly the same abstraction level. It is true that CoffeeScript is slightly more abstract than JavaScript in a few features (although JavaScript's inheritance model is more abstract than CoffeeScript's classes, for example), but any difference in abstraction level is tiny compared to the difference between, say, C and assembly.
pistoriusp 14y ago
I don't think it's fair that he should be allowed to use the name "CoffeeScript 2." I feel that it implies that it's an official project, but it's actually a re-implementation and separate project. And if they're not backwards compatible it could lead to a ton of confusion and a fragmented language. I think if you want your own project then you should at the very least get your own name.
- mistercow 14y ago
  I would be surprised if he didn't have Ashkenas's blessing on the name, since he's been the second biggest contributor to the main CoffeeScript project.
- michaelficarra 14y ago
  Fear not. The re-implementation will be completely backwards compatible. It just a smoother compilation pipeline, and adds some output configurability. But regardless, Jeremy and I have decided it would be best to change the name.
  - jQueryIsAwesome 14y ago
    I will suggest a few alternatives: Winescript, Caffèscript, Browniscript, Shortscript and Rubyscript.
    - michaelficarra 14y ago
      The names I suggested were "CoffeeScript: Reloaded", "CoffeeScript Episode II: Attack of the Clones", "The CoffeeScript Supremacy", and "Live Free or CoffeeScript Hard". Technically, right now it's "CoffeeScript II: The Wrath of Khan". Jeremy suggested CoffeeScript Redux. That's probably the best choice, though a little boring.
      - a-priori 14y ago
        Might I suggest "CoffeeScript II: Electric Boogaloo"?
emp_ 14y ago
When I saw the empty repo (just with the README) and before reading the kickstarter page or comments here, I thought it was another vapor.js-like joke as a compliment to the original compiler, which IMO does it very well.
desireco42 14y ago
I am ok with anything @jashkenas blesses. Thanks Groupon and others for supporting this, I would agree with commenters that name is confusing.
kristianp 14y ago
Here is a relevant groupon blog post: https://engineering.groupon.com/2012/javascript/looking-forward-to-an-interesting-summer/ https://engineering.groupon.com/2012/javascript/looking-forw... How about multiple backend support? Perhaps then someone could add a dart or NaCl backend.
- michaelficarra 14y ago
  I hadn't seen that blog post. Thanks for that.
- almost 14y ago
  CoffeeScript relies heavily on the underlying JavaScript semantics (which is one of the main reasons it's so useful: It's Just JavaScript) so other backends would most likely be a lot harder to do than the JS one.
deleted 14y ago
[deleted]
pbiggar 14y ago
The phrase "proper compiler-design principles" really gets on my nerves for some reason. It instantly makes me doubt the ability of the person saying it. It seems to say "I've heard of Lex/Yacc and once glanced at the Dragon Book". Anyway, I gather the OP is a coffeescript core contributor, so my default opinion is probably wrong in this case, hopefully.
deleted 14y ago
[deleted]
tferris 14y ago
This and nine more CoffeeScript derivates* from people who rather like to fragment a landscape with marginal improvements instead of supporting the leading pack are the reasons that CoffeScript hasn't reach critical mass and will fail as a standard. * https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang...
- johnfn 14y ago
  CoffeeScript hasn't attained critical mass? It's the 10th most popular language on github[1], over a decade younger than all the other contenders, and growing quickly. Even if CoffeeScript was as niche as you argue, I'm not convinced that that would have any bearing on its success. CoffeeScript doesn't need a wide community to achieve success because it compiles to and is completely interoperable with JavaScript, the most popular programming language. [1]: https://github.com/languages https://github.com/languages
  - tferris 14y ago
    Regarding the front end side the CoffeeScript adoption is high and mainly driven by Rails but if you look at the back end it's different: CoffeeScript could not established with Node (most npm packages are in plain JS) and mixing Coffee and JS on the backend does not really work out (it's possible though).
rjd 14y ago
So... I hope this isn't the future of updates to open source projects... crowd fund us or we won't do it... starting to see a pattern projects using this technique (albeit none are out rightly saying them won't its just implied)... not sure its a healthy development myself.
- tinco 14y ago
  It is an excellent development. It means developers can finally start to live from _independent_ open source development. This is not and never will be a replacement for hobby opensource, because that is done by developers who just want to do it, it would not make sense for them to threaten to not do it if we don't give them money. This is for the people who contribute to opensource, but also have a day job developing low-impact closed source commercial software, who don't have time or energy for large refactorings and rewrites. "Crowd fund us or we won't do it" sure is a lot better than "We won't do it".

76 points by netbyte 14y ago

chime 14y ago

This looks like a great project. Wish I would have known about the Kickstarter campaign for it sooner. Can't wait to try it out.

jashkenas 14y ago

Very much looking forward to seeing how this turns out. To view a list of some of the public-facing things Michael wants to change, take a look here: https://github.com/michaelficarra/coffee-of-my-dreams https://github.com/michaelficarra/coffee-of-my-dreams

GeZe 14y ago
For those who don't want to wait, most of the public-facing changes listed there are already in LiveScript (http://gkz.github.com/LiveScript/ http://gkz.github.com/LiveScript/) - though with a few more (in my opinion well justified) incompatibilities.
TazeTSchnitzel 14y ago
He wants to remove semicolons except where absolutely necessary? Is he nuts? The compiled output shouldn't be relying on an error-correction feature. Especially since it might break minifiers and validators.
- michaelficarra 14y ago
  That would just be a default in my fork. Since the output will be massively configurable, you can use any style you can imagine, including a single line with all the braces and semicolons and whitespace you want. See http://oai.cwi.nl/oai/asset/10876/10876D.pdf http://oai.cwi.nl/oai/asset/10876/10876D.pdf for a resource on defining grammars for AST to CST transformations.
- mistercow 14y ago
  I'm not sure I agree that ASI is an "error-correction feature". Die-hard always-semicolon advocates certainly would like to paint it that way, but I think that may be rewriting history a bit.
  - tomku 14y ago
    The ECMAscript standard[1] and the creator of the language[2] are pretty clear about it. From what I know of parsing, anything phrased in terms of adding tokens post-lexing in order to make an invalid parse tree valid as opposed to encoding the semantics in the grammar itself is most definitely an error correction method. I think that a lot of the confusion comes from taking the term "error" personally. Nobody wants to be told that their programming style relies on "error correction" to be parsed, but it's just an implementation detail of the parser, not some kind of qualitative statement about your programming skills. Changing the name does not change how the parser works, and does not make anyone involved a better or worse programmer. [1]: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf http://www.ecma-international.org/publications/files/ECMA-ST... (PDF) , section 7.9 [2]: http://brendaneich.com/2012/04/the-infernal-semicolon/ http://brendaneich.com/2012/04/the-infernal-semicolon/, specifically "The moral of this story: ASI is (formally speaking) a syntactic error correction procedure."
    - mistercow 14y ago
      Fair enough, but a statement like "compiled output shouldn't be relying on an error-correction feature" is only (self-evidently) true if we're using the informal, taking-it-personally connotations of "error correction".
- ajross 14y ago
  I recognize the minifier significance. But wait, there are validators (!?) that choke on valid (!) syntax?
  - TazeTSchnitzel 14y ago
    Lacking semicolons is an error, most validators error on it unless you tell them to ignore it.
  - mistercow 14y ago
    Also, any minifier that turns valid javascript into invalid javascript is broken, full stop.
    - ajross 14y ago
      Yes yes, but some do, it was a giant flame war, and I'll admit that it can be a practical issue (if not a correctness one) for javascript to rely on automatic semicolon insertion if it means you can't use your minifier of choice. But trying to use a "validator" that validates a languages other than the one you are writing is just plain insane.
michaelficarra 14y ago
I just want to make sure people know that those changes are bound for a fork once I reach full compliance with the current compiler. The project's one and only goal is to implement the language exactly as Jeremy's compiler does, but be prettier underneath (more extensible, versatile, configurable, robust, etc).

sirclueless 14y ago

Forgive me for being skeptical, but it seems to me that CoffeeScript is going the way of Lisp: a language by hackers for hackers, with way too many incompatible implementations because each implementer has their own pet features that must be included.

yuchi 14y ago
There's already a production ready transpiler, and a big bunch of production code to test against every new transpiler. Why do you think this is going to be a reason for fragmentation? And, by the way, coffeescript is not intended to be a language for hackers (I mean, only for hackers) but for Ruby programmers moving to javascript, JS programmers looking for a more terse syntax and programmers with an eye for terseness. In my opinion it has only two big flaws that need to be targeted by new transpilers: 1) for --> each 2) parens free chainable syntax.
- mistercow 14y ago
  Well, one reason that it could go that way is that the attitude that the maintainers has had toward feature-creep is "just make your own fork!" That's why we now have more dialects than we can shake a stick at, but it has kept the main branch from becoming PHP.
- charliesome 14y ago
  Please stop saying 'transpiler'. The CoffeeScript compiler is no less deserving of the term than any other compiler.
  - mistercow 14y ago
    "Transpiler" is a subset of "compiler", so it can hardly be a demeaning term. A transpiler is simply a compiler that translates code from language A to language B where A and B have roughly the same abstraction level. It is true that CoffeeScript is slightly more abstract than JavaScript in a few features (although JavaScript's inheritance model is more abstract than CoffeeScript's classes, for example), but any difference in abstraction level is tiny compared to the difference between, say, C and assembly.

pistoriusp 14y ago

I don't think it's fair that he should be allowed to use the name "CoffeeScript 2." I feel that it implies that it's an official project, but it's actually a re-implementation and separate project. And if they're not backwards compatible it could lead to a ton of confusion and a fragmented language. I think if you want your own project then you should at the very least get your own name.

mistercow 14y ago
I would be surprised if he didn't have Ashkenas's blessing on the name, since he's been the second biggest contributor to the main CoffeeScript project.
michaelficarra 14y ago
Fear not. The re-implementation will be completely backwards compatible. It just a smoother compilation pipeline, and adds some output configurability. But regardless, Jeremy and I have decided it would be best to change the name.
- jQueryIsAwesome 14y ago
  I will suggest a few alternatives: Winescript, Caffèscript, Browniscript, Shortscript and Rubyscript.
  - michaelficarra 14y ago
    The names I suggested were "CoffeeScript: Reloaded", "CoffeeScript Episode II: Attack of the Clones", "The CoffeeScript Supremacy", and "Live Free or CoffeeScript Hard". Technically, right now it's "CoffeeScript II: The Wrath of Khan". Jeremy suggested CoffeeScript Redux. That's probably the best choice, though a little boring.
    - a-priori 14y ago
      Might I suggest "CoffeeScript II: Electric Boogaloo"?

emp_ 14y ago

When I saw the empty repo (just with the README) and before reading the kickstarter page or comments here, I thought it was another vapor.js-like joke as a compliment to the original compiler, which IMO does it very well.

desireco42 14y ago

I am ok with anything @jashkenas blesses. Thanks Groupon and others for supporting this, I would agree with commenters that name is confusing.

kristianp 14y ago

Here is a relevant groupon blog post: https://engineering.groupon.com/2012/javascript/looking-forward-to-an-interesting-summer/ https://engineering.groupon.com/2012/javascript/looking-forw... How about multiple backend support? Perhaps then someone could add a dart or NaCl backend.

michaelficarra 14y ago
I hadn't seen that blog post. Thanks for that.
almost 14y ago
CoffeeScript relies heavily on the underlying JavaScript semantics (which is one of the main reasons it's so useful: It's Just JavaScript) so other backends would most likely be a lot harder to do than the JS one.

deleted 14y ago

[deleted]

pbiggar 14y ago

The phrase "proper compiler-design principles" really gets on my nerves for some reason. It instantly makes me doubt the ability of the person saying it. It seems to say "I've heard of Lex/Yacc and once glanced at the Dragon Book". Anyway, I gather the OP is a coffeescript core contributor, so my default opinion is probably wrong in this case, hopefully.

deleted 14y ago

[deleted]

tferris 14y ago

This and nine more CoffeeScript derivates* from people who rather like to fragment a landscape with marginal improvements instead of supporting the leading pack are the reasons that CoffeScript hasn't reach critical mass and will fail as a standard. * https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang...

johnfn 14y ago
CoffeeScript hasn't attained critical mass? It's the 10th most popular language on github[1], over a decade younger than all the other contenders, and growing quickly. Even if CoffeeScript was as niche as you argue, I'm not convinced that that would have any bearing on its success. CoffeeScript doesn't need a wide community to achieve success because it compiles to and is completely interoperable with JavaScript, the most popular programming language. [1]: https://github.com/languages https://github.com/languages
- tferris 14y ago
  Regarding the front end side the CoffeeScript adoption is high and mainly driven by Rails but if you look at the back end it's different: CoffeeScript could not established with Node (most npm packages are in plain JS) and mixing Coffee and JS on the backend does not really work out (it's possible though).

rjd 14y ago

So... I hope this isn't the future of updates to open source projects... crowd fund us or we won't do it... starting to see a pattern projects using this technique (albeit none are out rightly saying them won't its just implied)... not sure its a healthy development myself.

tinco 14y ago
It is an excellent development. It means developers can finally start to live from _independent_ open source development. This is not and never will be a replacement for hobby opensource, because that is done by developers who just want to do it, it would not make sense for them to threaten to not do it if we don't give them money. This is for the people who contribute to opensource, but also have a day job developing low-impact closed source commercial software, who don't have time or energy for large refactorings and rewrites. "Crowd fund us or we won't do it" sure is a lot better than "We won't do it".