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

Escape from Callback Hell

ianbishop.github.com

Post reply on HN
Print view View original

41–50 of 86 posts

Re: Escape from Callback Hell

#41

Post by Too »

daleharvey wrote: post #26
MatthewPhillips wrote: post #18

Earlier quoted context omitted.

A function that doesn't do IO and a function that does IO sound like totally different functions to me. Why aren't you writing a new function?

That isnt the point, its that you have some nice code that does |var x = someBigFunction()| and at some point in the programs life, something inside someBigFunction turns async, you have a whole restructuring to do.

Then that's a breaking change of the someBigFunction()s interface and it should be treated with care, not just quickly patching on a promise and hope for the best. Javascript is single threaded so when you wrote someBigFunction() you didn't have to think of parallel side effects. If you suddenly pause the execution of someBigFunc() and allow the user to mess around with the interface, the global state that someBigFunc() is working on might become changed.

Simply slabbing on a promise inside such a function only works if the function is pure to start with. Usually that's not the case with slow functions in javascript since the slowest thing in javascript is messing with the DOM, i.e global state.

Re: Escape from Callback Hell

#42

Post by Too » 

    function getItem(id) {
      return $.get("/api/item/" + id);
    }
    $.when(getItem(3), getItem(4)).then(handleSuccess, handleFailure);
Maybe I'm taking the point of the example out of context here, but i worry that promises makes it too easy to write non thought through code like this. Why make two separate http-requests for something that should have been possible to do with one?

Future prediction: Someone will create code similar to the one above but inside a for-loop calling getItem hundreds of times instead of just 2.

Re: Escape from Callback Hell

#43

Post by coldtea »

Swizec wrote: post #2

I honestly find "callback hell" a lot easier to follow and understand than the vast majority of fixes everyone is coming up with. They're just continuations, seriously, what's everyone's problem? You define a function, it gets access to the current scope, it defines the rest of the program flow. If you feel like your code is nesting too deep, you define the function elsewhere and just reference it by name. Then you d…

>They're just continuations, seriously, what's everyone's problem?

That they're badly made continuations, without support from the language.

>If you feel like your code is nesting too deep, you define the function elsewhere and just reference it by name. Then you don't get access to the current scope.

At the cost of moving stuff out of where it's invoked, so making code harder to read.

The problem with callback hell is that is pushes the programmer to write FOR the machine, in the way the machine likes it. Those things should be an implementation detail, and in good languages, are.

Re: Escape from Callback Hell

#44

Post by rapala »

gizmo686 wrote: post #31
MatthewPhillips wrote: post #29

Earlier quoted context omitted.

The function isn't the same, it now how side effects.

Not conceptually. From the perspective of the rest of the program, isPrime(x) has no side effect regardless of which method you use to implement it. If you are working in a purely functional language, then it makes sense to have introducing IO be a major change, as it has huge potential to make a function impure, and assuming IO is a pure function is roughly the equivalent of unsafePerformIO. However, in this case, w…

Of course it's different. What if the IO fails?

Re: Escape from Callback Hell

#45

Post by coldtea »

Swizec wrote: post #21
doktrin wrote: post #16

Earlier quoted context omitted.

IMHO the event model / callback spaghetti / what-have-you is tricky precisely because it operates at a high level of abstraction. Memory management, by comparison, is conceptually simpler because... well... the concept is simple. Allocating and de-allocating resources, while tricky at scale, is something for which everyone (including non-programmers) probably have existing mental models for. Event driven programming,…

You do event driven programming every time an alarm wakes you up or you set an egg timer.

And you do neural networks every time you think and aolve differential equations every time you catch a baseball.

That doesn't make it any less difficult.

Re: Escape from Callback Hell

#46

Post by spion »

If you want this problem solved, vote on the generators issue in v8:

http://code.google.com/p/v8/issues/detail?id=2355

If v8 implements this, both Firefox and Chrome as well as node.js will have yield, enabling libraries like taskjs [1] to be used.

From taskjs.org:

  spawn(function*() {
      var data = yield $.ajax(url);
      $('#result').html(data);
      var status = $('#status').html('Download complete.');
      yield status.fadeIn().promise();
      yield sleep(2000);
      status.fadeOut();
  });
[1]: http://taskjs.org/

Re: Escape from Callback Hell

#47

Post by dons »

tomlu wrote: post #4

It seems like this problem would be elegantly solved by starting a thread, green thread or coroutine (depending on language) for each task and calling the API functions synchronously from within that. I'm not sure what support JS has for these things.

Precisely. Threads allow you to separate concerns better - one thread per task, rather than trying to process all tasks.

Simon Marlow captured this well: http://stackoverflow.com/a/3858684/83805

"the abstractions that threads provide are essential for making server code easier to get right, and more robust"

Re: Escape from Callback Hell

#48

Post by daleharvey »

MatthewPhillips wrote: post #30
daleharvey wrote: post #26

Earlier quoted context omitted.

That isnt the point, its that you have some nice code that does |var x = someBigFunction()| and at some point in the programs life, something inside someBigFunction turns async, you have a whole restructuring to do.

This is just not something that happens in real life. You know what functions are going to be async up-front, and likely make them async even if you don't know, just in case. Since all IO in js is async by default, having a code that does a simple calculation and introducing IO into it is actually a very big change that warrants the refactoring you'll be required to do.

This is definitely something that happens to me a lot in real life.

And there isnt some magical point at which a change becomes large enough that it warrants a refactoring of unrelated code just because of the control flow.

Re: Escape from Callback Hell

#49

Post by lucian1900 »

It seems odd that so many people defend callback nested chains. You end up writing in continuation passing style, when many compilers can do CPS transform for you (Scheme, C#, things like IcedCoffeeScript.

Re: Escape from Callback Hell

#50

Post by Joeri »

coldtea wrote: post #43
Swizec wrote: post #2

I honestly find "callback hell" a lot easier to follow and understand than the vast majority of fixes everyone is coming up with. They're just continuations, seriously, what's everyone's problem? You define a function, it gets access to the current scope, it defines the rest of the program flow. If you feel like your code is nesting too deep, you define the function elsewhere and just reference it by name. Then you d…

> They're just continuations, seriously, what's everyone's problem? That they're badly made continuations, without support from the language. > If you feel like your code is nesting too deep, you define the function elsewhere and just reference it by name. Then you don't get access to the current scope. At the cost of moving stuff out of where it's invoked, so making code harder to read. The problem with callback hel…

Something lie this? http://taskjs.org/
Post reply on HN