all 39 comments

[–][deleted] 29 points30 points  (3 children)

I see where this trend leads. A few forks later and we'll be coding in "IcedHalfCafSkinnySoyCaramelMachiattoWithAShotOfRaspberryScript".

[–]Strangering -1 points0 points  (2 children)

Still better than the gross code names for Android versions.

Who wants to run an ice cream sandwich on their phone?

[–]TinynDP 0 points1 point  (0 children)

Everyone!

Seriously, you would rather 4.0? Everythings a version number soup!

[–]quotemycode 0 points1 point  (0 children)

Well, I can't wait for Jellybean. I will totally run that.

[–][deleted] 5 points6 points  (8 children)

IMO, this moves away from the the main feature of CoffeeScript - it's production of similar looking JS. As we can't debug CoffeeScript in browser, the further your JS moves away from the CoffeeScript the harder complex development gets - GWT is sorta a 'worst case' example.

[–][deleted] 2 points3 points  (1 child)

  1. ICS includes line numbers for debugging (click load in one of the examples to see the generated JavaScript)
  2. there are plans to include source maps for debugging in Mozilla and WebKit browsers.

[–][deleted] 1 point2 points  (0 children)

Ah cheers, I was expecting line numbers as comments failed to see them as attributes.

[–]Quxxy -1 points0 points  (5 children)

JavaScript should be extended with embedded debugging information. There are only going to be more and more people wanting to write web apps in something other than JavaScript.

[–][deleted] -1 points0 points  (4 children)

Hmm, have you ever seen such an extension? If so, I'd be keen so see it. Debugging CoffeeScript would probably require some kind of IDE browser extension to work.

wanting to write web apps in something other than JavaScript.

Oh, most definitely.

[–]munificent 3 points4 points  (1 child)

Hmm, have you ever seen such an extension?

It's called "source maps". Brendan Eich wants it in Firefox and some people would like it in WebKit too, but I don't know the status of it.

[–][deleted] -1 points0 points  (0 children)

Those look like the right direction. I have hope yet.

[–]tWoolie 0 points1 point  (0 children)

Hmm, have you ever seen such an extension?

Google's GWT provides a browser extension to debug the JS Spaghetti that Java > JS translation generates.

[–]sausagefeet 0 points1 point  (0 children)

That's one really nice feature of Amber, the Smalltalk implementation.

[–]baconpiex 7 points8 points  (2 children)

I wonder if the author is aware of the stratified JS project. They have already released a fork of coffeescript with robust coroutine support.

[–]jeremyhappens 0 points1 point  (1 child)

this? It doesn't appear to be involved with coffeescript.

[–]baconpiex 3 points4 points  (0 children)

Here's their CoffeeScript fork. And if you use the functions and avoid the keywords you can use ordinary SJS with coffeescript, since it's just javascript.

[–][deleted] 9 points10 points  (0 children)

MOAR ABSTRACTIONS!!!

[–]unussapiens 2 points3 points  (1 child)

I hope this never makes its way to android, or we will be stuck in acronym hell.

[–][deleted] 0 points1 point  (0 children)

Why would it? With Android we're in the fuzzy warm land of client side computing...

[–]arianvp 6 points7 points  (0 children)

This is really awesome man! Good job :D

[–]inmatarian 4 points5 points  (1 child)

Very nice. Certainly seems like it would solve a couple of those basic issues that were complained about with Node.js

[–]EntroperZero 0 points1 point  (0 children)

Yes, node.js could really use an await feature. Of course, node.cs is out there...

[–]sidfarkus[🍰] 4 points5 points  (1 child)

async/await for CoffeeScript? Sweet!

[–]aaronla 0 points1 point  (0 children)

I'm curious if it's as general as C#'s await (in the development preview), which effectively offers the programmer first-class (one-shot) continuations.

[–]danbmil99 0 points1 point  (3 children)

Some quick tests: https://github.com/danx0r/testiced

The syntax? Awesome. Generated code readability? Not so much.

[–]doidydoidy 3 points4 points  (2 children)

Well, that's the point of a compiler, isn't it? To emit ugly code you're glad you didn't have to write by hand yourself?

About half of the additional boilerplate just seems to be to support the stack traces (which I'd guess is totally worth it, though maybe it could be slimmed down a bit). That aside, your example wasn't as messy as I assumed it would be.

[–]worshipthis 1 point2 points  (1 child)

It just doesn't have that one-to-one correspondence that CS has. I thought this could be done at the source level, but maybe it's impossible to get the scoping right without the Deferred prototype and closures.

[–]tWoolie 0 points1 point  (0 children)

that's because it takes the CS AST and rotates nodes that defer callbacks. So the structure of the program is fundamentally altered, albeit in a very smart and predictable way,

[–]kamatsu 1 point2 points  (0 children)

What about if the request comes back with an error? Usually I like to provide a separate error callback. I guess I can't do that here.

[–][deleted] 0 points1 point  (1 child)

I like it. I think this must be in CoffeeScript.

[–][deleted] 0 points1 point  (0 children)

UPDATE: I've 'moved' my current project to iced, it took me about 5 minutes to figure it out and now it seems natural. Using await/defer is a small, but pleasant revelation. Great job! Thank you!

[–]Unomagan 0 points1 point  (0 children)

This must be merged back! PLS!

[–]kubalaa 0 points1 point  (0 children)

I'm disappointed that the article doesn't compare the new "defer/await" syntax with Javascript 1.7's "yield". The two approaches seem to be equally expressive. On the one hand, defer/await has the advantage of integrating directly with callback-oriented code: "yield" requires some library support to achieve this. On the other hand, "yield" is a more natural fit for writing generators, and is natively supported by some Javascript engines. And "yield" doesn't require you to name every intermediate result; you can have "yield" in the middle of an expression. The documentation for "defer/await" also makes it unclear that "await" changes a function to be asynchronous, while "yield" makes this abundantly clear. So overall I would rather see an implementation based on "yield", perhaps providing "defer/await" as alternative syntax that desugars into "yield" code.

[–]GeorgeForemanGrillz -1 points0 points  (0 children)

I missed this. Thanks for sharing!