Note that the “idempotence” definition that people use to describe side effectful actions is not the mathematical definition.
In math a function is idempotent if:
f(f(x)) = f(x)
This becomes very relevant in functional programming, as in FP the definition of idempotence is the math definition. Mentioning this in order to avoid confusion.
As always developers are overloading math terms in a way as to confuse everyone :-)
I don’t find the resemblance very intuitive. I was familiar with the meaning in TFA and got very confused when acquainted with the math definition.
Also in FP and in computer science in general the more correct term for executing effectful actions only once and then caching the result for subsequent calls is “memoization”.
correct term for executing effectful actions only once and then caching the result for subsequent calls is “memoization”
Memoizing actions which have observable side effects seems more like the sort of situation where you shouldn’t be using memoization. As I understand it the term usually implies an optimization that doesn’t change a program’s semantics, and that’s only the case when the function being memoized is referentially transparent.
Yes, but moreover, it does not make the client request idempotent. The definition given for idempotence is “the property of certain operations whereby they can be applied multiple times without changing the result beyond the initial application”. Making the button un-clickable doesn’t make it possible to apply the operation multiple times without changing the result; it prevents the operation from being applied more than once via the UI.
To make chat message sending idempotent, one could add a unique id or sequence number to each message so that it’s possible to detect and drop the duplicate message.
It’s a trade-off; there’s a cost to using transactions and you can avoid that cost if your operations are idempotent.
As you say though, if it’s infeasible to make an op idempotent then transactions are an excellent fallback :)
Note that the “idempotence” definition that people use to describe side effectful actions is not the mathematical definition.
In math a function is idempotent if:
This becomes very relevant in functional programming, as in FP the definition of idempotence is the math definition. Mentioning this in order to avoid confusion.
As always developers are overloading math terms in a way as to confuse everyone :-)
it’s not confusing in this case. the analogy works perfectly.
I don’t find the resemblance very intuitive. I was familiar with the meaning in TFA and got very confused when acquainted with the math definition.
Also in FP and in computer science in general the more correct term for executing effectful actions only once and then caching the result for subsequent calls is “memoization”.
See: https://en.m.wikipedia.org/wiki/Memoization
Memoizing actions which have observable side effects seems more like the sort of situation where you shouldn’t be using memoization. As I understand it the term usually implies an optimization that doesn’t change a program’s semantics, and that’s only the case when the function being memoized is referentially transparent.
Wouldn’t this mean that if you never get a response, you can’t use the app anymore?
Yes, but moreover, it does not make the client request idempotent. The definition given for idempotence is “the property of certain operations whereby they can be applied multiple times without changing the result beyond the initial application”. Making the button un-clickable doesn’t make it possible to apply the operation multiple times without changing the result; it prevents the operation from being applied more than once via the UI.
To make chat message sending idempotent, one could add a unique id or sequence number to each message so that it’s possible to detect and drop the duplicate message.
Good point. Even nowadays, the web still relies on the “refresh” button as well as system issues are still magically fixed on reboot :)
Why not to use transactions and (compound?) unique indexes in order to make the whole operation atomic?
It’s a trade-off; there’s a cost to using transactions and you can avoid that cost if your operations are idempotent. As you say though, if it’s infeasible to make an op idempotent then transactions are an excellent fallback :)