Live data from Hacker News

CoffeeScript2 - A Redesign of the CoffeeScript Compiler

github.com

11–20 of 46 posts

Re: CoffeeScript2 - A Redesign of the CoffeeScript Compiler

#11
post #5

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.

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 tersene…

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.

Re: CoffeeScript2 - A Redesign of the CoffeeScript Compiler

#13

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

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).

Re: CoffeeScript2 - A Redesign of the CoffeeScript Compiler

#15

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.

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.

Re: CoffeeScript2 - A Redesign of the CoffeeScript Compiler

#16

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

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.

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 for a resource on defining grammars for AST to CST transformations.

Re: CoffeeScript2 - A Redesign of the CoffeeScript Compiler

#17

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

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.

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.

Re: CoffeeScript2 - A Redesign of the CoffeeScript Compiler

#18

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.

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.

I will suggest a few alternatives: Winescript, Caffèscript, Browniscript, Shortscript and Rubyscript.

Re: CoffeeScript2 - A Redesign of the CoffeeScript Compiler

#19

Earlier quoted context omitted.

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.

I will suggest a few alternatives: Winescript, Caffèscript, Browniscript, Shortscript and Rubyscript.

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.

Re: CoffeeScript2 - A Redesign of the CoffeeScript Compiler

#20

Earlier quoted context omitted.

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.

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.

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... (PDF) , section 7.9

[2]: http://brendaneich.com/2012/04/the-infernal-semicolon/, specifically "The moral of this story: ASI is (formally speaking) a syntactic error correction procedure."

Post reply on HN