> There are no problems with reusability that I can think of as a result of the
> internal state machine. The functions passed to `.then` are just plain
> functions, so they are perfectly reusable.
Sorry, i should be more clear about reusability i’m referring are not the
functions you passed, but the Promise itself, suppose we have an async
operation readDB, we can construct a web api using Promise like this:
express = require('express');
express = require('express');
express = require('express');
express = require('express');
var Action, Promise, action, callback, express, fs, http, promise, testAction;
express = require('express');
http = require('http');
fs = require('fs');
Action = require('action-js');
Promise = require('bluebird');
promise = express();
action = express();
callback = express();
promise.get('/', function(req, res) {
return new Promise(function(resolve, reject) {
return fs.readFile('./test', {
encoding: 'utf8'
}, function(err, data) {
return resolve(data + new Date().getTime());
});
}).then(function(data) {
return res.send(data);
});
});
http.createServer(promise).listen(8123);
testAction = new Action(function(cb) {
return fs.readFile('./test', {
encoding: 'utf8'
}, function(err, data) {
return cb(data + new Date().getTime());
});
});
action.get('/', function(req, res) {
return testAction.go(function(data) {
return res.send(data);
});
});
var express = require('express');
var testApp = express()
testApp.get(‘/test', function(req, res) {
new Promise(function(resolve, reject) {
readDB('test', function(data) {
resolve(someProcess(data));
});
})
.then(function(data) {
res.send(data);
});
});
So you’re creating a Promise for every request, using my solution you can reuse
Action like this:
var express = require('express');
var testApp = express()
var testAction = new Action(function(cb) {
return readDB(‘test’, function(err, data) {
cb(process(data));
});
});
testApp.get(‘/test', function(req, res){
testAction
.go(function(data) {
res.send(data);
});
});
Every time you call go, the readDB run again, you won’t waste time on
recreating whole callback chain.
I even benchmarked such situation, where Action can get close performance to
raw callback, Promise will pay about 10~15% punishment depend on readDB
cost(this high readDB cost, the lower Promise creation cost), but i’m not going
to attack on Promise performance problem anymore, since it’s not meaningful
without statistic.
> The state machine approach won't lead to race conditions in a multi-threaded
> environment because the promise state machine will always live on a single
> thread. If JavaScript ever gets shared memory multi-threading it will be
> carefully restricted to prevent this kind of problem.
No doute on that.
> By contrast, systems built without a carefully engineered state machine (e.g.
> Thunks and your continuation based system) tend to lead to race conditions in
> user land code. Once people try and write parallel code or caching/memoised
> using lazy continuation based systems they quickly end up needing to convert
> them into some kind of eager data structure. This is often done badly (it's
> very difficult to get right) and can lead to very hard to debug race
> conditions. By contrast, promises are very carefully designed and tested
> implementations of exactly this functionality.
Well, i understand that Promise are javascript’s choice, and i think i
understand the reason now, but i really don’t think lazy data structure lead to
race conditions ; ), but again i won’t going to defend for lazy data structure
without any statistic either.
~winter
> On Oct 4, 2015, at 6:55 PM, Forbes Lindesay <[email protected]> wrote:
>
> There are no problems with reusability that I can think of as a result of the
> internal state machine. The functions passed to `.then` are just plain
> functions, so they are perfectly reusable.
>
> I don't think there is a significant overhead to promises once properly
> optimised. I don't see how your solution would lead to lower overhead.
>
> The state machine approach won't lead to race conditions in a multi-threaded
> environment because the promise state machine will always live on a single
> thread. If JavaScript ever gets shared memory multi-threading it will be
> carefully restricted to prevent this kind of problem.
>
> By contrast, systems built without a carefully engineered state machine (e.g.
> Thunks and your continuation based system) tend to lead to race conditions in
> user land code. Once people try and write parallel code or caching/memoised
> using lazy continuation based systems they quickly end up needing to convert
> them into some kind of eager data structure. This is often done badly (it's
> very difficult to get right) and can lead to very hard to debug race
> conditions. By contrast, promises are very carefully designed and tested
> implementations of exactly this functionality.
>
> _____________________________
> From: 韩冬 <[email protected] <mailto:[email protected]>>
> Sent: Saturday, October 3, 2015 1:04 p.m.
> Subject: Re: Alternative to Promise
> To: Benjamin Gruenbaum <[email protected] <mailto:[email protected]>>
> Cc: <[email protected] <mailto:[email protected]>>
>
>
> Hey Benjamin
>
> I want to know more about the implementation about Promise after two day of
> research, there’re two different ways of implementing a chain style control
> structure, one is based on an internal state machine, which save the callback
> for a moment, and resolve them after async function finish, the other one is
> based on continuation, every node on the chain are a new continuation contain
> the computation on the chain, some kind of porting the ConT monad from
> haskell to javascript, i’d like to compare them and get to know why the
> state-machine based solution eventually won?
>
> Here is my summary:
> Pros for state machine based solutions:
> Auto memorization.
> Easy sementics.
> Cons for state machine based solutions:
> Bad reusability.
> Larger overhead.
> Pros for continuation based solutions:
> Good reusability, since continuation are just functions.
> Lower overhead.
> Cons for continuation based solutions:
> Complex sementics.
> No memorization(can be done by other ways).
> Do you agree with me on this summary? and suppose in future javascript will
> get multicore support, will the state-machine based solution subject to race
> condition?
>
> Thanks again for giving me lots of detail about the history, now i need more
> : )
>
> On Oct 1, 2015, at 4:42 PM, Benjamin Gruenbaum < [email protected]
> <mailto:[email protected]>> wrote:
>
>
> > Where do you get the courage to challenge every inventor that they have to
> > learn everything you've learned before they making decisions?
>
> Can we please keep it civil?
>
> > the question is why not check other languages first, when there’re nice
> > solutions already there.
>
> Promises are rooted in the 1980s and have been pretty much adopted in every
> mainstream programming language one way or another:
>
> - Task - C#
> - Future - Scala
> - Deferred - Python
> - CompletableFuture - Java
> - Future - C++
>
> And so on and so on. The technical committee also includes people who
> pioneered the concept. Practically everyone on this list knows Haskell, and
> ConT isn't really anything new to any of us. We can all explore various
> alternatives that are the continuation monad
> (http://blog.sigfpe.com/2008/12/mother-of-all-monads.html
> <http://blog.sigfpe.com/2008/12/mother-of-all-monads.html>) all day long -
> but JavaScript already has continuations through promises and they are
> already in the standard so there is absolutely zero chance they'll be
> "swapped" for something else at this point.
>
> There are about 3 years of discussions to read about the choices and the
> rationale for why promises behave exactly the way they behave and you're
> welcome to read those on the specific choices.
>
> If you're interested in current proposals for other async primitives for the
> language - there is currently an observable proposal and an async iterator
> proposal - both solve different issues than promises (multiple values over
> push/pull) and are currently in design stages.
>
> In general, the list frowns upon people who "plug their library" in the list
> - so I suggest that in the future you start your email with the specific
> problem you want to address and what you do differently. The more concise you
> write (and external links aren't that great for this) the better chance
> you'll get more responses from people involved.
>
> Cheers and good luck,
> Benjamin
> _______________________________________________
> es-discuss mailing list
> [email protected] <mailto:[email protected]>
> https://mail.mozilla.org/listinfo/es-discuss
> <https://mail.mozilla.org/listinfo/es-discuss>
>
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
