3 ms·

I think you are arguing a very niche perspective here. The concept of idempotence in mathematics predates futures/promises by about a century and is part of th

I think you are arguing a very niche perspective here. The concept of idempotence in mathematics predates futures/promises by about a century and is part of the general background understood by most people exposed to any CS concepts. It has been prevalent across a wide range of communities discussing networking protocol and message-passing designs since the inception of the Internet. It appears in countless RFCs and other standards documents which are read by people building web-based systems. The concept of futures/promises you are promoting is honestly a niche part of computer science from the 1970s which persists in an intersection of distributed systems research and programming language research. It was never the prevalent formalism shared by general CS or network engineering communities. Meanwhile, a different aspect of the same 1970s concept has had a rebirth as an asynchronous programming syntax and appears in widely consumed languages. This different camp of PL researchers has essentially won the popularity contest which defines the new "standard" meaning of futures and promises for the general technical audience.

naasking 9y ago
I'm not arguing against idempotency, or attempting to redefine it, I'm pointing out that "idempotent key" as used in this article precisely denotes a future. You might as well write an article on a "text-based client/server GET/PUT/POST protocol" without labelling it HTTP. It's stupid and unnecessarily obfuscated. This abstraction has a well-known technical name, so use it, don't invent a new term. And I frankly find it bizarre that you call futures/promises "niche" when they're now part of every web browser in the world and millions of programmers use them every day. The fact that these futures aren't durable isn't relevant since the browser environment itself is transient.
- dboreham 9y ago
  But it doesn't "precisely denote a future". Not even remotely close to the same thing.
  - naasking 9y ago
    What a great argument. Idempotency keys are single-assignment/idempotent variables. Promises are single-assignment/idempotent variables. They're totally not the same thing!
- saltcured 9y ago
  I find it bizarre for you to invoke the niche E programming language as if it is obviously relevant to any use of unique identifiers for detecting replay of messages. Why don't we criticize the author for his lack of Petri nets, or his glaring omission of a denotational semantics in the appendix to his article? At this point in the discussion, I am unsure that you understand promises in distributed systems formalism, because you seem to be conflating it with the ones recently en vogue in Javascript and other popular languages. Those futures/promises in every web browser in the world are a purely local asynchronous programming idiom, or what I like to think of as CPS unconversion. I didn't suggest that browser programming is a niche concept, but it also has nothing to do with organizing idempotent remote state changes over a lossy message channel. There is a vast literature using many different forms of explicit identifier tied to some form of idempotence. Do you run around the IETF and W3C telling them to stop saying "Message-ID" when they really mean futures/promises? Or security researchers with their nonces? How about those pesky IPv4 and IPv6 designers with their silly ports, SYN cookies, and sequence numbers?
  - naasking 9y ago
    > Why don't we criticize the author for his lack of Petri nets, or his glaring omission of a denotational semantics in the appendix to his article? Oh, was I asleep when Petri nets and denotational semantics are now used by millions of programmers around the world? > Those futures/promises in every web browser in the world are a purely local asynchronous programming idiom, or what I like to think of as CPS unconversion. I didn't suggest that browser programming is a niche concept, but it also has nothing to do with organizing idempotent remote state changes over a lossy message channel. Of course it does, and I already made this point so I don't know why you're ignoring it. Add durability to browser promises, and there you go. The durability is irrelevant to the semantics. > Do you run around the IETF and W3C telling them to stop saying "Message-ID" when they really mean futures/promises? Or security researchers with their nonces? Nonces and Message-IDs have different semantics than promises. It's like you're not even listening. Idempotency keys have the same semantics as promises. Ergo, they are promises. Promises are idempotent, but not every idempotent abstraction is a promise. It's simple, I'm not sure where the confusion lies.

naasking 9y ago

I'm not arguing against idempotency, or attempting to redefine it, I'm pointing out that "idempotent key" as used in this article precisely denotes a future. You might as well write an article on a "text-based client/server GET/PUT/POST protocol" without labelling it HTTP. It's stupid and unnecessarily obfuscated. This abstraction has a well-known technical name, so use it, don't invent a new term. And I frankly find it bizarre that you call futures/promises "niche" when they're now part of every web browser in the world and millions of programmers use them every day. The fact that these futures aren't durable isn't relevant since the browser environment itself is transient.

dboreham 9y ago
But it doesn't "precisely denote a future". Not even remotely close to the same thing.
- naasking 9y ago
  What a great argument. Idempotency keys are single-assignment/idempotent variables. Promises are single-assignment/idempotent variables. They're totally not the same thing!
saltcured 9y ago
I find it bizarre for you to invoke the niche E programming language as if it is obviously relevant to any use of unique identifiers for detecting replay of messages. Why don't we criticize the author for his lack of Petri nets, or his glaring omission of a denotational semantics in the appendix to his article? At this point in the discussion, I am unsure that you understand promises in distributed systems formalism, because you seem to be conflating it with the ones recently en vogue in Javascript and other popular languages. Those futures/promises in every web browser in the world are a purely local asynchronous programming idiom, or what I like to think of as CPS unconversion. I didn't suggest that browser programming is a niche concept, but it also has nothing to do with organizing idempotent remote state changes over a lossy message channel. There is a vast literature using many different forms of explicit identifier tied to some form of idempotence. Do you run around the IETF and W3C telling them to stop saying "Message-ID" when they really mean futures/promises? Or security researchers with their nonces? How about those pesky IPv4 and IPv6 designers with their silly ports, SYN cookies, and sequence numbers?
- naasking 9y ago
  > Why don't we criticize the author for his lack of Petri nets, or his glaring omission of a denotational semantics in the appendix to his article? Oh, was I asleep when Petri nets and denotational semantics are now used by millions of programmers around the world? > Those futures/promises in every web browser in the world are a purely local asynchronous programming idiom, or what I like to think of as CPS unconversion. I didn't suggest that browser programming is a niche concept, but it also has nothing to do with organizing idempotent remote state changes over a lossy message channel. Of course it does, and I already made this point so I don't know why you're ignoring it. Add durability to browser promises, and there you go. The durability is irrelevant to the semantics. > Do you run around the IETF and W3C telling them to stop saying "Message-ID" when they really mean futures/promises? Or security researchers with their nonces? Nonces and Message-IDs have different semantics than promises. It's like you're not even listening. Idempotency keys have the same semantics as promises. Ergo, they are promises. Promises are idempotent, but not every idempotent abstraction is a promise. It's simple, I'm not sure where the confusion lies.