3 ms·

Why would you write this: [long_io_operation with callback] When you can instead write this: [long_io_operation without callback] Off the top of my head, I'd s

by Cushman 16y ago

Why would you write this: [long_io_operation with callback] When you can instead write this: [long_io_operation without callback] Off the top of my head, I'd say because "var result = long_io_operation(req);" is not only not self-documenting but actively deceptive if long_io_operation is an asynchronous call. I'm not sure I see what's to be gained by pretending closures don't exist.

fogus 16y ago
It's not closures that I hope to avoid, but callbacks.
metabrew 16y ago
It's not deceptive if you have a preemptively multitasking runtime that you trust (like the Erlang VM); it's a much more natural way of writing code. Single-threaded, event-driven callback spaghetti makes code harder to read, and inherently means more code. If someone took v8, added lightweight coroutines, and wrote a preemptive scheduler for it, I bet you could massively reduce the SLOC count for large node.js apps.
- sovande 16y ago
  > It's not deceptive if you have a preemptively multitasking runtime that you trust That may be so, but since Javascript is inherently single threaded _and_ this is about javascript I agree with Cushman that it is indeed deceptive.
  - jerf 16y ago
    But we aren't talking about Javascript. It's about a theoretical replacement language. Also, the reason you care about the "synchronicity" in the first place is because your environment forces you to care! When it all Just Works (TM), you don't care whether it's "synchronous" or not. That's a deficiency in your language, not a feature. I'm not theorizing. I program in this sort of language all the time. You worry much more simply about how long something will take, which you can never not worry about, rather than how many bits are "synchronous".
    - deleted 16y ago
      [deleted]
    - deleted 16y ago
      [deleted]
    - deleted 16y ago
      [deleted]
    - sovande 16y ago
      > But we aren't talking about Javascript. It's about a theoretical replacement language. Apparently the plan is to implement this "theoretical replacement language" in javascript using node.js https://github.com/fogus/funode/blob/master/src/funode.js https://github.com/fogus/funode/blob/master/src/funode.js
  - awj 16y ago
    > That may be so, but since Javascript is inherently single threaded Is that in the language standard, or are you confusing details of implementations for the language's design?
    - deleted 16y ago
      [deleted]
    - sovande 16y ago
      Yes, as far as there is a standard and no
d0mine 16y ago
Python's twisted library supports both styles: d = long_io_operation() d.addCallback(callback) d.addErrback(errback) With defer.inlineCallbacks: try: result = yield long_io_operation() callback(result) except Exception, e: errback(e) It is not necessary to use functions in the second case.
- cdavid 16y ago
  It is not that simple in real life, unfortunately. Even ignoring the fact that inlineCallbacks's overhead is significant, inlineCallback forces you to serialize things which may be run in parallel. If you do yield f1() yield f2() You force f1 to finish before being able to start f2, which goes against the whole point of using something like twisted in the first place ! I have also noticed that inlineCallback screw up the traceback (e.g. http://twistedmatrix.com/trac/ticket/3622 http://twistedmatrix.com/trac/ticket/3622 - I still see this with twisted 10.0.0). While I am no genius, I am a decent programmer, with quite a few years of experience in python, and I still can't read most non trivial async code in twisted with confidence. It is almost impossible IMO to get a clear idea of the codeflows and especially error flows to ensure error handling is done right. Error handling is already difficult as is, adding exception made it that much harder, but adding async makes it basically impossible except for Vulcans.
  - d0mine 16y ago
    In real life inlineCallbacks's overhead is not significant compared to typical IO times (even snail in a park reaches its destination sooner than a rocket makes it to Pluto and back). inlineCallbacks allows you to write code in a synchronous manner (that's the point). If you'd like to wait for completion of both f1 and f2 functions simultaneously you could: yield DeferredList([f1(), f2()]) The ticket you mentioned is closed as invalid. Use `failure.printTraceback()`. Non trivial async code is hard to read (period). Exceptions allows you deal with errors in the place where you know what to do with them, not in the place where they arise (as in any other Python code).
    - cdavid 16y ago

by Cushman 16y ago

fogus 16y ago

It's not closures that I hope to avoid, but callbacks.

metabrew 16y ago

It's not deceptive if you have a preemptively multitasking runtime that you trust (like the Erlang VM); it's a much more natural way of writing code. Single-threaded, event-driven callback spaghetti makes code harder to read, and inherently means more code. If someone took v8, added lightweight coroutines, and wrote a preemptive scheduler for it, I bet you could massively reduce the SLOC count for large node.js apps.

sovande 16y ago
> It's not deceptive if you have a preemptively multitasking runtime that you trust That may be so, but since Javascript is inherently single threaded _and_ this is about javascript I agree with Cushman that it is indeed deceptive.
- jerf 16y ago
  But we aren't talking about Javascript. It's about a theoretical replacement language. Also, the reason you care about the "synchronicity" in the first place is because your environment forces you to care! When it all Just Works (TM), you don't care whether it's "synchronous" or not. That's a deficiency in your language, not a feature. I'm not theorizing. I program in this sort of language all the time. You worry much more simply about how long something will take, which you can never not worry about, rather than how many bits are "synchronous".
  - deleted 16y ago
    [deleted]
  - deleted 16y ago
    [deleted]
  - deleted 16y ago
    [deleted]
  - sovande 16y ago
    > But we aren't talking about Javascript. It's about a theoretical replacement language. Apparently the plan is to implement this "theoretical replacement language" in javascript using node.js https://github.com/fogus/funode/blob/master/src/funode.js https://github.com/fogus/funode/blob/master/src/funode.js
- awj 16y ago
  > That may be so, but since Javascript is inherently single threaded Is that in the language standard, or are you confusing details of implementations for the language's design?
  - deleted 16y ago
    [deleted]
  - sovande 16y ago
    Yes, as far as there is a standard and no

d0mine 16y ago

Python's twisted library supports both styles: d = long_io_operation() d.addCallback(callback) d.addErrback(errback) With defer.inlineCallbacks: try: result = yield long_io_operation() callback(result) except Exception, e: errback(e) It is not necessary to use functions in the second case.

cdavid 16y ago
It is not that simple in real life, unfortunately. Even ignoring the fact that inlineCallbacks's overhead is significant, inlineCallback forces you to serialize things which may be run in parallel. If you do yield f1() yield f2() You force f1 to finish before being able to start f2, which goes against the whole point of using something like twisted in the first place ! I have also noticed that inlineCallback screw up the traceback (e.g. http://twistedmatrix.com/trac/ticket/3622 http://twistedmatrix.com/trac/ticket/3622 - I still see this with twisted 10.0.0). While I am no genius, I am a decent programmer, with quite a few years of experience in python, and I still can't read most non trivial async code in twisted with confidence. It is almost impossible IMO to get a clear idea of the codeflows and especially error flows to ensure error handling is done right. Error handling is already difficult as is, adding exception made it that much harder, but adding async makes it basically impossible except for Vulcans.
- d0mine 16y ago
  In real life inlineCallbacks's overhead is not significant compared to typical IO times (even snail in a park reaches its destination sooner than a rocket makes it to Pluto and back). inlineCallbacks allows you to write code in a synchronous manner (that's the point). If you'd like to wait for completion of both f1 and f2 functions simultaneously you could: yield DeferredList([f1(), f2()]) The ticket you mentioned is closed as invalid. Use `failure.printTraceback()`. Non trivial async code is hard to read (period). Exceptions allows you deal with errors in the place where you know what to do with them, not in the place where they arise (as in any other Python code).
  - cdavid 16y ago