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

81–86 of 86 posts

Re: Escape from Callback Hell

#81

Post by fzzzy »

daleharvey wrote: post #69
Evbn wrote: post #64

Earlier quoted context omitted.

Functional programs don't make this easier. And don't say "monad transformer stacks" somehow solve this problem in an easier way.

Not necessarily because it is functional, but Erlang makes this vastly easier. I find the "oh you changed tiny piece of logic, you should totally have to refactor every line of code that follows it" very strange. It obviously sucks, there are far better ways to handle it and they are slowly making it into the language.

Erlang makes it easier because it enforces no shared state between actors, and each actor has it's own independent thread of control.

Re: Escape from Callback Hell

#82

Post by fzzzy »

Joeri wrote: post #50
coldtea wrote: post #43

Earlier quoted context omitted.

> 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/

Unfortunately task.js requires javascript generators which are only implemented in Firefox right now.

Re: Escape from Callback Hell

#83

Post by fzzzy »

daleharvey wrote: post #27

I dont find that promises really help callback hell that much, they are useful but in the case of doing a series of sequential async functions the result is pretty similiar (the promises version is usually longer) I got to write some firefox only code recently and added a delay to a function by just adding ... some code setTimeout(continueFun, 5000) yield; ... more code it felt like magic, I dont like generators and…

Why don't you like generators?

Re: Escape from Callback Hell

#84

Post by fzzzy »

daleharvey wrote: post #27

I dont find that promises really help callback hell that much, they are useful but in the case of doing a series of sequential async functions the result is pretty similiar (the promises version is usually longer) I got to write some firefox only code recently and added a delay to a function by just adding ... some code setTimeout(continueFun, 5000) yield; ... more code it felt like magic, I dont like generators and…

By the way, it is absolutely possible to implement a message passing style on top of generators instead of some random ad hoc resumption policy. Check it out:

https://github.com/fzzzy/pavel.js

The only caveat is that you do have to write "yield receive('pattern')" instead of just "receive('pattern')".

Re: Escape from Callback Hell

#85

Post by Peaker »

fzzzy wrote: post #79
Peaker wrote: post #67

Earlier quoted context omitted.

Haskell definitely makes it easier. You can use preemptive green threads with almost all the ease of cooperatively multitasked code because of the prevalence of immutability. You get the performance benefits of non-blocking code. The simplicity benefits of blocking code. And (almost) none of the threading hell you get in imperative languages.

Are they really preemptive? How does the scheduler decide when to switch?

Yeah, they are preemptive (though there had been a long-standing bug where threads that have no allocations don't get preempted, I believe it is fixed now).

This is some documentation of the scheduler: http://blog.ezyang.com/2013/01/the-ghc-scheduler/

Re: Escape from Callback Hell

#86

Post by rapala »

bjourne wrote: post #71
rapala wrote: post #44

Earlier quoted context omitted.

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

Then the program dies with an exception. What if a memory allocation in a Haskell program fails? It can happen just as well because allocating memory is an impure operation which you still have to perform from pure functions. Haskell just happens to pretend it has infinite memory available because forcing the programmer to attempt handle out of memory conditions would be impractical and annoying. Haskells "purity" is…

So your whole program just crashes because the prime server was not responding? I think that changes the semantics of isPrime quite a bit.
Post reply on HN