Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IcedCoffeeScript

maxtaco.github.com

Post reply on HN
Print view View original

11–20 of 63 posts

Re: IcedCoffeeScript

#11

Post by chc »

raganwald wrote: post #6
russianbandit wrote: post #4

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…

As a user, you don't really need to walk away from anything. There isn't any difference between Iced CoffeeScript output that doesn't use await and vanilla CoffeeScript output. You could literally switch out somebody's name-brand CoffeeScript for Iced and he'd never know the difference unless he had a function called await. It's purely an ideological concern, not a practical one.

Re: IcedCoffeeScript

#12

Post by nailer »

The aim of your docs should be to show how simple and readable IcedCoffeeScript is: using multi character variable names in your examples would help to achieve that.

Re: IcedCoffeeScript

#13

Post by chc »

Detrus wrote: post #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.

Here's the main one for Iced: https://github.com/jashkenas/coffee-script/pull/1942

I remember there was another discussion before where they first started talking about Max's implementation, but I can't seem to find it at the moment. That did seem to be the general consensus, though.

Re: IcedCoffeeScript

#14

Post by raganwald »

chc wrote: post #11
raganwald wrote: post #6

Earlier quoted context omitted.

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…

As a user, you don't really need to walk away from anything. There isn't any difference between Iced CoffeeScript output that doesn't use await and vanilla CoffeeScript output. You could literally switch out somebody's name-brand CoffeeScript for Iced and he'd never know the difference unless he had a function called await. It's purely an ideological concern, not a practical one.

You’re preaching to the choir!

But one objection we will both encounter repeatedly is that if a language supports feature X, and you work on a team/inherit code/use libraries, there will always be people who don’t want to use feature X but wind up dealing with it any ways because someone else used it.

So the naysayers will claim that if it’s added to the core language, it’s only a matter of time before they wind up dealing with it whether they like it or not. Given the way that most Ruby users have to live with monkey-patching in Ruby whether they do it themselves or not, I fully expect that if await and defer are added to core CS, there will be libraries or CommonJS modules that use it and presto, you may find yourself looking at some of its output in the debugger one day.

I’d rather use the feature myself and benefit from it, but I can accept what the luddites are saying even if I don’t end up coming to the same conclusion about whether the feature should be added or withheld :-)

UPDATE: I recall being told that tail-call optimization should not be added to certain languages because it encourages programmers to write recursive functions that are “hard to read.” You might argue that if you never write recursive functions, why should you care? But people do care.

Re: IcedCoffeeScript

#15

Post by bascule »

When I made this comment the other day, I wasn't actually serious that someone should build a JavaScript compiler that does CPS:

"CPS is also generally used as an IR in compilers, not something you write by hand"

http://news.ycombinator.com/item?id=3511211

This reminds me of my Celluloid::IO system in Ruby (which uses coroutines to provide a synchronous API), except Celluloid::IO lets you have as many event loops as you want:

https://github.com/tarcieri/celluloid-io

Re: IcedCoffeeScript

#16

Post by patrickwiseman »

Being able to syntactically assemble several parallel requests together has an obvious advantage in making code more readable. Having a hard time wrapping my mind around the keywords. From the examples I think more wait/collect than await/defer. For instance:

Await these items that I want to defer.

Wait on this code block and collect these items.

Re: IcedCoffeeScript

#17

Post by equark »

Why is defer needed? Why can't I follow C# and do:

   result = await search("test")
Is this just so that it plays nicely with non-standard callback APIs? I'd prefer to introduce Promises (i.e., q) and have await interact with that. I guess this is not the NodeJS way though.

Re: IcedCoffeeScript

#18

Post by crazygringo »

equark wrote: post #17

Why is defer needed? Why can't I follow C# and do: result = await search("test") Is this just so that it plays nicely with non-standard callback APIs? I'd prefer to introduce Promises (i.e., q) and have await interact with that. I guess this is not the NodeJS way though.

search("test") is not an asynchronous call, in your example, because there's no callback function. (In JavaScript)

defer() is needed because it becomes the placeholder for the callback function, and lets Iced know how many functions it needs to wait to call back.

Re: IcedCoffeeScript

#19

Post by udp »

mayoff wrote: post #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.

It actually used to be called Tame, not Iced:

https://github.com/jashkenas/coffee-script/pull/1942#issueco...

Re: IcedCoffeeScript

#20

Post by tsuraan »

nailer wrote: post #12

The aim of your docs should be to show how simple and readable IcedCoffeeScript is: using multi character variable names in your examples would help to achieve that.

When you see a two-liner of

  for k, i in keywords
    search k, defer out[i]
Do you really get lost or confused? Are you actually complaining about a problem, or just a violation of your favorite style guide? Personally, I'm looking for what makes IcedCoffeeScript unique; all else is just cruft, so keeping that terse is just fine with me.
Post reply on HN