4 ms·

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

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.

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.