Live data from Hacker News

IcedCoffeeScript

maxtaco.github.com

1–10 of 63 posts

Re: IcedCoffeeScript

#2
I was going to complain that I could find no mention of TameJS (from which the await and defer keywords/features clearly originated). Then I noticed that the IcedCoffeeScript author is also the author of TameJS.

Re: IcedCoffeeScript

#3
So was there more discussion about await and defer in the many github issues on the subject? This output seems more debuggable than previous CScript defer attempts.

Re: IcedCoffeeScript

#5

Why didn't the "iced" feature just get added to CoffeeScript? Why have two separate packages?

I haven't looked at this implementation specifically, but the issue with many similar proposals/implementations is that the generated JavaScript is ugly. One of the nice things about CoffeeScript is that there's no magic--it's very easy to figure out what the generated JavaScript is doing, and there's a straightforward CS JS mapping. jashkenas (CoffeeScript's author) has been reluctant to change that.

Re: IcedCoffeeScript

#6

Why didn't the "iced" feature just get added to CoffeeScript? Why have two separate packages?

This is a fork of the language, not an official feature. It’s as if you wrote your own version of JavaScript that trampolines function calls and performs tail-call optimization. You still need to go through the social process to get your ideas into the main “trunk.” Selling people on adopting your fork might be one way to get everyone excited about the idea.

That being said, right up front he explains the two reasons why this is a departure from CoffeeScript’s core philosophy: `await` and `defer` are changes in the semantics of JavaScript, and not surprisingly, code written in IcedCoffeeScript no longer compiles into more-or-less recognizable JavaScript.

Modulo syntax and sugar, CoffeeScript is JavaScript with some minor changes to the AST (such as soaking up nils with the Elvis operator). IcedCoffeeScript is another language that evolved from JavaScript and transpiles to JavaScript.

Before adding such features willy-nilly to CoffeeScript, folks need to be comfortable walking away from a core value. I’m not saying that’s a bad thing, but it’s a problem related to the Innovator’s Dilemma: To embrace this new value, CoffeeScript will have to alienate some portion of its user base that value compiled JavaScript that is easily recognizable to anyone who has read the CoffeeScript source.

Re: IcedCoffeeScript

#8
post #5

Why didn't the "iced" feature just get added to CoffeeScript? Why have two separate packages?

I haven't looked at this implementation specifically, but the issue with many similar proposals/implementations is that the generated JavaScript is ugly. One of the nice things about CoffeeScript is that there's no magic--it's very easy to figure out what the generated JavaScript is doing, and there's a straightforward CS JS mapping. jashkenas (CoffeeScript's author) has been reluctant to change that.

[deleted]

Re: IcedCoffeeScript

#9
The way that this manages to transform those examples makes me think that it would make all kinds of other things more palatable than the vanilla coffee script. I've written chains of callbacks in plain JS that this would make so much nicer to work with.

Re: IcedCoffeeScript

#10
post #5

Why didn't the "iced" feature just get added to CoffeeScript? Why have two separate packages?

I haven't looked at this implementation specifically, but the issue with many similar proposals/implementations is that the generated JavaScript is ugly. One of the nice things about CoffeeScript is that there's no magic--it's very easy to figure out what the generated JavaScript is doing, and there's a straightforward CS JS mapping. jashkenas (CoffeeScript's author) has been reluctant to change that.

IIRC, Jeremy Ashkenas actually brought this up in the pull request discussion, but he sounded pretty impressed by the minimalism of the code ICS generates. There seems to be more ideology-based opposition among the community.
Post reply on HN