“idempotence” is a disproportionately fancy, unapproachable word for literally just “if nothing needs changing, don’t touch anything”. I bet the term was invented by someone who was trying to justify their paycheck

also, making stuff idempotent just seems like the obviously right thing to do. we don’t need a fancy math term for “hey maybe your patch shouldn’t break stuff that’s already patched”

I’ve been trying to think of a more approachable term than “idempotence” and the best I have so far is “look first”. as in, “make sure your patch looks first (before touching/changing anything)”

@kasdeya it has always spoken volumes to me that in the industry where it's most often used, most of the people who try to use it can't remember how to pronounce it -- no matter how many times they look it up. it's a terrible word

@kasdeya I was going to suggest “if it works don’t fix it” but I’m a bit hesitant because that’s used to justify a lot of things… and I’m not quite sure that fits in.

@kasdeya I mean when is the last time mathematicians named something descriptively

@mira that’s interesting. how could reading the constant value and comparing it to the new value break idempotence? I’m not sure if I understand. but it definitely makes sense that overwriting the constant value would be idempotent, even though you aren’t “looking first”

@mira ohhh - interesting! I see what you mean. my solution to that would still probably be “if the value is false, make it true. otherwise, ignore that config file” instead of “overwrite the value, whatever it is, with true” but I can see how either one is probably equally valid (honestly, unconditionally overwriting it might be better in the rare case of a weird race condition where something else is editing the config file in between the conditional check and the overwrite)

although if the desired behavior was actually “make it false if it started as true, and vice versa” then hmm I guess you’d need to leave some kind of marker to indicate that the patch had already run? so that you don’t just keep inverting it after the initial inversion. so in that case it would be “if the marker exists, do nothing. otherwise invert the boolean”

@kasdeya It's one of those terms that was originally coined by mathematicians before computers existed, so it got a fancy Latin-derived word because the mathematicians love their fancy Latin words. It's used to refer to operations that always have the same result no matter how many times you apply them in a row (absolute value, raising to the 0th or 1st power, multiplying by 0 or 1, etc.)

I think people who apply it in the context of "your patch shouldn't break things if it was applied twice" aren't quite using it in the right context, or at least they're extending the meaning a little bit too far, and you're right that it's a disproportionately fancy way to say "don't break if I apply it twice."

I'd only use it when describing a patch if the patch didn't need to look first, because applying the patch to a pre-patched input would just generate an identical result.

@kasdeya Not to say that programmer lingo isn't unnecessarily complicated because it really can be impenetrable most of the time. Just pointing out that this specific term is really the fault of 19th-century mathematicians.

@kasdeya > “if nothing needs changing, don’t touch anything”

That's not really what it means though, besides that being a mouthful.

It means repeated application of a function/procedure on a same target will not alter its result.

One *can* achieve that by adding checks, there are a lot of other ways too depending on the kind of state and how it is managed.

idempotence -> idem, same (this is actually used by at least some French speakers in regular speech); potence, potent, potential, capacity. It's very straightforward actually.

So a function having "capacity for identical/the same results on application regardless of number of iterations insofar as this number is superior to 0".

@kasdeya especially in distributed or concurrent systems there's a bit more nuance to it, so we feel it does justify having a bit of a fancy word

like for a networked event, idempotence means "if you don't get receipt of sending successfully, it's safe to repeat the same message after a delay" - like from our perspective as the sender, we don't know whether the failure was in sending our event or in receiving the confirmation, so knowing it's safe to try again is really helpful because it means we don't have to reach out and check "hey did you receive this" before retrying

whereas with non-idempotent systems, that delay may cause it conflict with a later message that was sent by another actor in the network, or if we don't check and assume it failed to send, that may result in the creation of duplicate records by the receiver