Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Promises are not neutral enough

staltz.com

Post reply on HN
Print view View original

111–120 of 133 posts

Re: Promises are not neutral enough

#111

Post by Rapzid »

magnushiie wrote: post #10

I think the author wants promises to represent computation, whereas they represent predetermined (i.e. single-shot) events. He mentioned C# Tasks, which do mainly represent computation, but in some cases Tasks are also used as events and this gets confusing as hell. I've worked with C# Tasks and hope that MS once cleans this up and builds the stuff on promises instead. Note that the C# language construct uses the awa…

As it is, the fact that the promise initializer function is called immediately is a god send. If I had a dollar for every concurrency race-like condition that has prevented..

Constructor doesn't just take a function, it takes a closure if you so choose.. A closure that has immediate access to resolve and reject and doesn't have to worry about other code paths access its enclosed vars first.

Re: Promises are not neutral enough

#112

Post by squiggleblaz »

woah wrote: post #65
_greim_ wrote: post #19

I don't know. André Staltz is a great programmer, but I can't help but think what seems "opinionated" to him about promises boils down to the fact that they don't perfectly match certain quasi-ideological preferences he has about async programming, at the expense of all other concerns. As he states at the end, promises still work, you can get things done and everything is fine. But the part about them being opinionat…

I have to agree. This blog post comes from a place of judging what is "better" by some arbitrary abstract metrics (hint: the author's own library wins this contest). It doesn't consider what programmers use them for. Promises are meant to semantically (and with async/await, syntactically) resemble a function call as closely as possible, while minimizing confusing errors. The author's "improvements" would ruin this. I…

Although I don't like most of his alleged improvements, surely a separate map/flatMap would be more like function calls.

If I write

    function foo(v) {
        return function () { return v }
    }

    const fv = foo(4)
then I expect fv will be a function, not a number. In that respect, I think the choice to make `then` flatten was a poor decision that makes it more confusing for people who don't really take the time to understand. Such people don't realise it's confusing: they simply notice it's usually convenient; but they're inhibited from drawing the correct analogies.

But as for the rest. Yeah, it's just arbitrary and weird. Maybe we should make integers all arrays lazy by default too?

Re: Promises are not neutral enough

#113

Post by spion »

mathgladiator wrote: post #109
spion wrote: post #97

Earlier quoted context omitted.

MobX is the most powerful front end development library on the market right now. It single-handedly solves the cache invalidation problem in a performant way, and its pluggable into any framework. And yes, promises limit it.

How does one measure power? What market?

By actually using the thing being criticised instead of giving it the middlebrow dismissal.

The "market" of application state management libraries.

Re: Promises are not neutral enough

#115

Post by reaktivo »

A reminder that LazyPromises are trivial to implement:

    function LazyPromise(executor) {
      this.then = (resolve, reject) => new 
    Promise(executor).then(resolve, reject);
      this.catch = (resolve, reject) => new 
    Promise(executor).catch(reject);
    }

Re: Promises are not neutral enough

#116

Post by naasking »

amptorn wrote: post #91
naasking wrote: post #81

Earlier quoted context omitted.

> This blog post comes from a place of judging what is "better" by some arbitrary abstract metrics Or you could consider the possibility that they aren't arbitrary at all. Perhaps these properties are well motivated by, for instance equational reasoning, which is a cornerstone of extensible and maintainable programming. > Promises are meant to semantically (and with async/await, syntactically) resemble a function cal…

> equational reasoning, which is a cornerstone of extensible and maintainable programming What are the other cornerstones?

Abstraction. Composition. Probably a couple of others.

Re: Promises are not neutral enough

#117

Post by naasking »

spion wrote: post #113
mathgladiator wrote: post #109

Earlier quoted context omitted.

How does one measure power? What market?

By actually using the thing being criticised instead of giving it the middlebrow dismissal. The "market" of application state management libraries.

Frankly, S.js looks better. Simple and performant.

Re: Promises are not neutral enough

#118

Post by spion »

naasking wrote: post #117
spion wrote: post #113

Earlier quoted context omitted.

By actually using the thing being criticised instead of giving it the middlebrow dismissal. The "market" of application state management libraries.

Frankly, S.js looks better. Simple and performant.

Slightly confusing api, no structural comparison, no adapters for popular frameworks (e.g. S.js-react or S.js-preact), no laziness (computations are recomputed even if they're not requested by reactions).

Re: Promises are not neutral enough

#119

Post by naasking »

spion wrote: post #118
naasking wrote: post #117

Earlier quoted context omitted.

Frankly, S.js looks better. Simple and performant.

Slightly confusing api, no structural comparison, no adapters for popular frameworks (e.g. S.js-react or S.js-preact), no laziness (computations are recomputed even if they're not requested by reactions).

Why use react when you can use Surplus which is based on S.js? Surplus is the fastest among all of the JS frameworks and supports JSX.

"Slightly confusing" == I'm not familiar with it. Not really an objection.

"No structural comparison": don't know what this is supposed to mean.

Re: laziness, actually redundant recomputations are not performed. Not sure where you go that impression.

Re: Promises are not neutral enough

#120

Post by spion »

naasking wrote: post #119
spion wrote: post #118

Earlier quoted context omitted.

Slightly confusing api, no structural comparison, no adapters for popular frameworks (e.g. S.js-react or S.js-preact), no laziness (computations are recomputed even if they're not requested by reactions).

Why use react when you can use Surplus which is based on S.js? Surplus is the fastest among all of the JS frameworks and supports JSX. "Slightly confusing" == I'm not familiar with it. Not really an objection. "No structural comparison": don't know what this is supposed to mean. Re: laziness, actually redundant recomputations are not performed. Not sure where you go that impression.

I don't want to use surplus because e.g. I want to use well developed UI components or toolkits like blueprintjs, which is implemented on top of React.

Slightly confusing is a real objection. MobX strives to implement transparent reactive programming, where the way you access, update and transform values works exactly like it would with regular objects. S.js has a worse learning curve.

Redundant computations are computed; see: https://codepen.io/anon/pen/vdWomE?editors=0010

even though the completed() computed isn't used anywhere, the reduction is still being recomputed every time todo state changes

Post reply on HN