When we say “pure functions are free” out loud, of course it seems categorically false, and I don’t think anyone has ever credibly argued for this claim. And yet I think it is an implicit assumption of a lot of functional programming development, specifically that which attempts to build “referentially transparent” systems on top of an imperative, impure systems and languages, rather than starting with a new language from scratch.

My example of React.js is the pinnacle of this, all features like hooks, contexts, and concurrent mode only make sense when they estimate the cost of re-executing pure functions to be free, or at least negligible, and yet real-world experience indicates this is definitely not the case.

> One benefit (with respect to the CPU) of pure functions is that they can be cached because you know you'll get the same result for each call (of course, this impacts memory), which you can't guarantee with impure functions. But that's a tradeoff of memory for time.

In my personal experience, I’ve become pretty skeptical of trading memory for execution time. Especially in garbage-collected languages, what you save in execution time you lose in GC pauses, so the end result is you get neither.

Caching is and will continue to be a core building block of performance in current sw (and hw) systems. And it's a boon when you have a tool to fix one of the two hard problems[1].

[1] The famous quote: "There are only two hard things in Computer Science: cache invalidation and naming things." (attributed to Phil Karlton)

> Especially in garbage-collected languages, what you save in execution time you lose in GC pauses, so the end result is you get neither.

This only applies to GC languages that lack language features support for value types, stack allocation or native heap support.

There are some wildly imaginative benefits of FP sold in words by some advocates, oftentimes imagining what could be in a runtime or compiler based on the maths of what’s promised by the practice. It’s easy to imagine that if an expensive function call always produces the same results it can be optimized to a single call, after which all further calls are free (a memory access). It’s easy to then overstate or imply that calling a pure function guarantees that kind of optimization even if it doesn’t.

You are right of course, that this is not always implemented. I'd add though, that an impure implementation would never allow for such an optimization. The rest is the job of compiler developers. Of course you need to keep an eye on runtime execution cost as well. That is part of your job.

> One benefit (with respect to the CPU) of pure functions is that they can be cached

Only if the input space is very small. If your function takes as input two booleans and a string you know is an ID from a relatively static and small set of IDs, memoization is the way to go. If your function takes in two arbitrary floats, trying to memoize anything will only make your program run slower and leak memory.

Permanent memoization is not your only option.

Caching the result of common inputs and discarding not-recently-used results can be useful on functions with huge - but nonuniformly distributed - input and output spaces. At the extreme, you might have procedural image or texture generation - perhaps the postprocessing of another image or texture, for example. Impurity is a great way to end up with serious cache invalidation bugs when untracked inputs are changed, and purity a great way to avoid them.

Well, caching is a thing that shouldn't be done "just because" but after some analysis that says it's worth it. And as MaulingMonkey said, a cache doesn't need to keep everything, just enough things to improve performance. And if the cache is costing you performance versus recomputation, then don't do it. I mean, just like anything else in life, if it hurts don't do it. If it costs you performance in a way that you care about, use an alternative.