I guess at the end your're right. =/ On Tuesday, August 6, 2013 4:06:09 PM UTC+2, greelgorke wrote: > > > > 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.
