Am Dienstag, 6. August 2013 12:51:35 UTC+2 schrieb Christopher Probst: > > I think, you are actually wrong about the composeable aspect. Callbacks do > not compose by default. Compose means easy chaining of elements without > putting glue between each element. The glue would represent error checking. > A callback can return an error or a result. So no, you cannot simply > compose them, as you would with usual functions.
yes i'm aware of the error checking, and i also consider it a problem, because it mixes the concerns of error handling with the actual business logic (yes, some error handling can be business logic too.) but if you're ok with jut passing by the error without to worry about them till the very last resort, then you can. btw. for me is it much more important to compose the async operations easily. and this is more a matter of compatibility than of callback/noncallback. you can do it with callbacks. and a callback doesn't return. it gets error or result and does something with it. > > If you really want to compose callbacks you have to introduce monads, > where the context is carried with (like a bind method). And of course there > are already abstractions but this shows that raw callbacks are definitely > not composable. > in js you have some posibilities to carry context: closures, Function#bind and old school hash-objects (but the latter is of course not that cool). so what is a raw callback? its a function that takes an error and one or more result params. go and curry it, compose it, bind it, do whatever you think you need. sure, js functions has limits at the edge. > > And what you are saying about the "old" sync way is equally wrong in my > opinion. Thinking synchronous is the way you solve problems naturally. > Maybe you learned thinking with callbacks, and I admit that it's not that > difficult, it's just not beautiful. Coming from a computer science > background solving problems beautiful is the most important thing to > provide stable and easy to understand code, at least in my opinion. > the truth is, that we solve problems in whichever way fits in. if i need to make some food hot, i start synchronous and put it on a dish, place it into microwave oven and start it. but then i go away and do something else, till i'm called back. we should do this in programming too. callbacks are not more difficult or understandable. thats why they are still popular, as Mikeal pointed out. The problem is not the callback itself, it's how mindlessly we use them sometimes. Promises, fibers, grean threads wont solve this particular problem. Unfortunately. > > And by the way: Callbacks are stil imperative, just more verbose than > (green-)threads or coroutines(yield). Functional programming is a totally > different thing. Javascript is not functional, not even a bit ;) Well it > has functions, but... > yes they are imperative. if you wish them so. But they can be also message receivers. Trevor pointed that out. I guess almost everything is in some kind imperative in programming. well except prolog and json may be :P > Async callbacks are an implementation detail of asynchronous programming, > not a pattern everybody should use. Ryan Dahl describes node.js as a > simple/low-level layer to create higher abstractions on. He said that > higher abstractions are good in general but he see's node as a foundation > for that. > Promises are an implementation detail of asynchronous programming, not a pattern everybody should use. Message passing is an implementation detail of asynchronous programming, not a pattern everybody should use. Shared memory with Locks is an implementatio... uh you get it i think. Yes callbacks are low-level abstraction. very low to the language, in fact they built on very raw language tools: functions as values, sometimes closure scope. We have higher level abstractions in core: EventEmitters and Streams. And we have even more of them in user-land. > > The best abstractions are green threads. Every problem you have can be > solved with a bunch of green threads because you can create millions of > them. They can talk to each other using messaging without locks and can be > distributed as well without losing the mental model. And the best thing: > They compose by default! > Yes, i certainly agree. but face the reality: we don't have them yet, and wont have them in near future. at least not in core or v8. erlang is the only platform i'm aware of, which has them and gained enough traction. and erlang is specifically made for solving problems in distributed way. thats great! and surely i would either take erlang then. Look, my point is: we should solve our problems in every way it fits. and there is room for callbacks, promises, events and streams etc. we shouldn't throw something away, just because someone thinks it's looks ugly. most of us are pretty fine with callbacks, and most of us would agree that if there is something really better we should try it. but have to be better in any way, or else it wont replace anything. so the whole discussion about promises and callbacks is pointless. there is clear convention: callbacks are least common determinator in node, if you wanna be compatible, design your interface that it can deal with them, either pure, via EventEmitter or Streams. everywhere else do what you like. just don't blame other for refusing your decisions regarding that. :) green promised callback emitter streams ftw -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
