Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There are two problems with callback based frameworks.

#1 In python specifically, we do not have proper closure and no anonymous blocks, this makes operating it tedious as the definition of the logic for a callback is always somewhere else from where the callback is setup.

#2 In any language supporting proper closures (javascript for instance, hello node.js) excessive, nested use of callback based frameworks leads to the phenomenon of the pyramid of death, whereas you keep nesting closures and you have to keep them all in one place because each depends on its outer scope.

I intently dislike twisted and node.js for these very reasons. I've written my own little framework based entirely on greenlets in python, which is delightful and easy to use and entirely avoids both dislocality of action and the pyramid of death.



In what sense does Python not have "proper closure"? Do you mean mutable closures?

Also, does @inlineCallbacks address your issue? The only fundamental difference I see (other than implementation nastiness, which I guess both have some issue with :)) is that with inlineCallbacks your yields are explicit, and with greenlets they're not.


What do you mean by greenlets?

Twisted feels to me like a grand experiment that's groping towards something that we know is there, but not quite catching it yet. I guess I/O monads feel like slightly further along the path - but they're still not the true solution. What does your system look like?


Greenlets are one-shot coroutines (with no implicit scheduling). They generally work with a C extension that slices the stack.

In IO frameworks that are greenlet based, the greenlet is resumed when it has stuff waiting for it.

The obvious difference to the programmer is that a greenlet won't have yield statements in them, whereas a generator would.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: