Hacker News Reader

Comment by forrestthewoods | Hacker News Reader

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.

View on HN

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.

Microsoft uses "Task". I like that way better.

and also the aptly named "TaskCompletionSource", which would be the promise equivalent (using Facebook's terminology)

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

That term actually makes the subject much more understandable.

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.

A promise what you get when you can't get a result immediately: a promise to deliver a result later. "Future" is nonsense terminology.

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.

Or, you know, a promise is another name for assert.

Except of course it isn't. Oops.

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".

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.

Reply on news.ycombinator.com