8 ms·

Rats, the terminology is backwards from the E/JavaScript promise/future distinction: https://en.wikipedia.org/wiki/Futures_and_promises#Read-only_views https://

Rats, the terminology is backwards from the E/JavaScript promise/future distinction: https://en.wikipedia.org/wiki/Futures_and_promises#Read-only_views https://en.wikipedia.org/wiki/Futures_and_promises#Read-only... There's been a push to standardize "Promise" to be the read-only side and "Future" to mean the resolver/promise pair, but Folly Futures use the opposite convention. Agreeing on terminology is hard. :) Edit: I think it's fine that Folly adopted the C++11 convention. I'm just whining in the open that that promise vs. future may never be agreed upon.

forrestthewoods 11y ago
I fucking hate the terms future and promise so god damn much. The names are beyond stupid. They're just confusing as hell. No one can read the names and make an educated guess as to which is which it what they do. The following is my favorite interview response of all time. Q: what's a quaternion? A: I don't know... But I bet it has four parts. Genius! An honest answer followed by a wise educated guess. Now, what's a future and what's a promise? How can you remember the difference? Good luck! Those terms should be retired forever.
- gohrt 11y ago
  A promise what you get when you can't get a result immediately: a promise to deliver a result later. "Future" is nonsense terminology.
  - obstinate 11y ago
    You could as easily say that a promise is a promise you've made to produce a piece of data in the future. That's the problem with the term -- it's equally easy to interpret it as the consumption or production side of the equation. As an exercise in skeuomorphism, it's poor, since just like in real life, you can equally give and receive a promise.
  - revelation 11y ago
    Or, you know, a promise is another name for assert. Except of course it isn't. Oops.
  - kriro 11y ago
    That's exactly what a "future" is in trading terms. I think the problem is conflating domains. I'm pretty sure most people will interpret future as "the future" and not as a "future contract".
- Aleman360 11y ago
  Microsoft uses "Task". I like that way better.
  - Cakez0r 11y ago
    and also the aptly named "TaskCompletionSource", which would be the promise equivalent (using Facebook's terminology)
    - jmtulloss 11y ago
      That is, their terminology for this project. In facebook's Bolts framework for iOS they use Task and TaskCompletionSource https://github.com/BoltsFramework/Bolts-iOS#tasks https://github.com/BoltsFramework/Bolts-iOS#tasks
  - yelnatz 11y ago
    That term actually makes the subject much more understandable.
    - masklinn 11y ago
      It doesn't. "Task" has a notion of side-effect and no notion of yielding a value. Except a task can yield a value and have no side-effect.
- obstinate 11y ago
  Make a header file for your project that exports the Facebook headers and typedefs the names to something that makes sense. I like source and sink. Producer and consumer are fine too. Emitter and receiver are fine as well. And writer/reader. If you do this, then you only have to make sense of which side is which once, then forever after you'll have sensible names for the things (at least in your project). The important thing is to always treat the name the same. Generally, I treat types as nouns. So an emitter is something that emits something. It's passed to the routine that consumes the data. On the other hand, a consumer consumes, so it's passed to a routine that emits something for consumption.
- rattray 11y ago
  I've always found "promise" intuitive personally; it returns a guarantee about a future action. "Future" gives me a vague idea that it has to do with something later, but isn't great. Learning these terms isn't that tough, either. I don't find "promise" any less intuitive than "statement", "expression", "parameter", or "argument". I'm just used to the latter ones.
fugalh 11y ago
Scala also takes the same way C++11 does, and to my mind it makes more sense this way. So from my perspective Javascript is the backward duck here. I agree it would be nice if we could all just settle on something
- No1 11y ago
  E came out in 1997. From my perspective, Scala and C++11 are the backward ducks (unless you can point to something earlier using the Scala/C++11 nomenclature). I agree the Scala/C++11 way might make a little more sense intuitively, but it really doesn't help flipping the definitions around.
  - modersky 11y ago
    It's much older than that. See https://en.wikipedia.org/wiki/Futures_and_promises https://en.wikipedia.org/wiki/Futures_and_promises The distinction between futures and promises in the wikipedia article matches Scala's terminology exactly.
    - No1 11y ago
      Yes, Wikipedia's terminology exactly matches that of Scala, but that's because Wikipedia references a Scala SIP ;) It's always bothered me that Baker and Hewitt felt the need to coin the term "future" when they were clearly aware of "promise" and "eventual". Their main distinction seems to be that a future is a 3-tuple (process, cell, queue). One can argue that their future meets the "read-only view" definition because cell is only to be written to by the same tuple's process. But they never explicitly distinguish a future as "a read-only placeholder view of a variable," and E was the first publicly-available language to make that very distinction (please correct me if I'm wrong), only they happened to use "promise" in that regard. In any case, I trust your judgement on the matter more than my own, just wish everyone had picked a nomenclature and stuck with it.

forrestthewoods 11y ago

I fucking hate the terms future and promise so god damn much. The names are beyond stupid. They're just confusing as hell. No one can read the names and make an educated guess as to which is which it what they do. The following is my favorite interview response of all time. Q: what's a quaternion? A: I don't know... But I bet it has four parts. Genius! An honest answer followed by a wise educated guess. Now, what's a future and what's a promise? How can you remember the difference? Good luck! Those terms should be retired forever.

gohrt 11y ago
A promise what you get when you can't get a result immediately: a promise to deliver a result later. "Future" is nonsense terminology.
- obstinate 11y ago
  You could as easily say that a promise is a promise you've made to produce a piece of data in the future. That's the problem with the term -- it's equally easy to interpret it as the consumption or production side of the equation. As an exercise in skeuomorphism, it's poor, since just like in real life, you can equally give and receive a promise.
- revelation 11y ago
  Or, you know, a promise is another name for assert. Except of course it isn't. Oops.
- kriro 11y ago
  That's exactly what a "future" is in trading terms. I think the problem is conflating domains. I'm pretty sure most people will interpret future as "the future" and not as a "future contract".
Aleman360 11y ago
Microsoft uses "Task". I like that way better.
- Cakez0r 11y ago
  and also the aptly named "TaskCompletionSource", which would be the promise equivalent (using Facebook's terminology)
  - jmtulloss 11y ago
    That is, their terminology for this project. In facebook's Bolts framework for iOS they use Task and TaskCompletionSource https://github.com/BoltsFramework/Bolts-iOS#tasks https://github.com/BoltsFramework/Bolts-iOS#tasks
- yelnatz 11y ago
  That term actually makes the subject much more understandable.
  - masklinn 11y ago
    It doesn't. "Task" has a notion of side-effect and no notion of yielding a value. Except a task can yield a value and have no side-effect.
obstinate 11y ago
Make a header file for your project that exports the Facebook headers and typedefs the names to something that makes sense. I like source and sink. Producer and consumer are fine too. Emitter and receiver are fine as well. And writer/reader. If you do this, then you only have to make sense of which side is which once, then forever after you'll have sensible names for the things (at least in your project). The important thing is to always treat the name the same. Generally, I treat types as nouns. So an emitter is something that emits something. It's passed to the routine that consumes the data. On the other hand, a consumer consumes, so it's passed to a routine that emits something for consumption.
rattray 11y ago
I've always found "promise" intuitive personally; it returns a guarantee about a future action. "Future" gives me a vague idea that it has to do with something later, but isn't great. Learning these terms isn't that tough, either. I don't find "promise" any less intuitive than "statement", "expression", "parameter", or "argument". I'm just used to the latter ones.

fugalh 11y ago

Scala also takes the same way C++11 does, and to my mind it makes more sense this way. So from my perspective Javascript is the backward duck here. I agree it would be nice if we could all just settle on something

No1 11y ago
E came out in 1997. From my perspective, Scala and C++11 are the backward ducks (unless you can point to something earlier using the Scala/C++11 nomenclature). I agree the Scala/C++11 way might make a little more sense intuitively, but it really doesn't help flipping the definitions around.
- modersky 11y ago
  It's much older than that. See https://en.wikipedia.org/wiki/Futures_and_promises https://en.wikipedia.org/wiki/Futures_and_promises The distinction between futures and promises in the wikipedia article matches Scala's terminology exactly.
  - No1 11y ago
    Yes, Wikipedia's terminology exactly matches that of Scala, but that's because Wikipedia references a Scala SIP ;) It's always bothered me that Baker and Hewitt felt the need to coin the term "future" when they were clearly aware of "promise" and "eventual". Their main distinction seems to be that a future is a 3-tuple (process, cell, queue). One can argue that their future meets the "read-only view" definition because cell is only to be written to by the same tuple's process. But they never explicitly distinguish a future as "a read-only placeholder view of a variable," and E was the first publicly-available language to make that very distinction (please correct me if I'm wrong), only they happened to use "promise" in that regard. In any case, I trust your judgement on the matter more than my own, just wish everyone had picked a nomenclature and stuck with it.