Hacker News Reader

Comment by apg | Hacker News Reader

This post raises a few questions for me... and perhaps some one more versed in these stacks can provide answers.

- Does the use of CoffeeScript alleviate the MC Escher-esque quality of callbacks within closures involved in working with Javascript on both the server and client (and the data store)? I can totally see the appeal of CoffeeScript's syntax. Giving the programmers something different to look (and learn) at probably provides some cognitive benefit as well.

- Is there an acronym/name (ala LAMP) for the Node/MongoDB/Redis stack?

View on HN

1. CoffeeScript doesn't alleviate this yet. I doubt will be much progress on this until we find a good way to implement defer/async. https://github.com/jashkenas/coffee-script/issues/350#issuec...

I am writing a sizable Node app myself. In the end, you just get used to the callback style.

I am assuming that CoffeeScript should be able to add new syntax where the need arises, as the number of CoffeeScript users is probably still pretty low and able to adapt to change.

From what I can tell, CoffeeScript - and the Javascript/Node world - would really benefit from something like F#'s workflow/computation-expression syntax, which will take a fairly straight-forward readable statement and behind the scenes de-sugar the hell out of it into a bunch of closures.

http://en.wikibooks.org/wiki/F_Sharp_Programming/Computation...

EDIT: search for "De-sugared syntax" on this page for an example.

That's correct -- because we compile to "standard" JavaScript, we're at least somewhat comfortable introducing significant changes (even to the syntax) where desirable. Even if you never get around to updating older pieces of code, all of the compiled JS continues to be fully compatible and interoperable with the newer stuff.

Where is the love for [Deferreds?](http://www.sitepen.com/blog/2010/05/03/robust-promises-with-...)?

Deferreds are * Mostly monadic (creating a deferred is "return", the "then" method is "fmap" and "bind"). * Can be implemented as a library, without a separate compilation step or having to patch the runtime. * Avoids most of the CPS inversion of control madness. You can return and store promises and you can also add callbacks after the fact so code is much more flwxible. (writing sequential async loops is still annoying though)

After reading that ticket, I think the solution is going to have to involve more than one keyword. It's curious to see that the objection is to the hideous mass of js that "defer" compiles down into. I kind of thought that was the point of CoffeeScript.

I think the following links are relevant for those of us that know much less than you:

I liked this article that discusses three different solutions to callbacks with different compromises: http://blog.willconant.com/post/7523275566/continuations-in-...

Jeremy discusses #350 and tamejs here: http://news.ycombinator.com/item?id=2777196

Tamejs have a great writeup about the callback spaghetti problem here: http://tamejs.org/

- Daniel is going to write another post detailing this. The answer is that when you combine CoffeeScript and a good async library, you can indeed get rid of that stuff.

- MoNsteR? =)

when you combine CoffeeScript and a good async library, you can indeed get rid of that stuff

My experience has been that you could only do this in few cases. Not an issue that can be worked around elegantly in libraries, you need language support. http://tamejs.org/

LNMR... um... LaMiNaR? RoMuLaN?

I just ran the letters modb-re-nojs-li through my handy word_solver and came up with some candidates: MoRN, NoRM, ModeRN, NiMRod, ReMiNd, MeRLiN, LiMNeR, NiMbLeR

Reply on news.ycombinator.com