[_lce0]

Mathematically a Function is a Relation that has two special properties: uniqueness and existence.

(these properties names can be wrong as I've not study calculus in English)

So on the machine, Immutability plays an important role on the first piece, uniqueness, so it tries to guarantee that results are not just "equal objects, but different instances", which breaks the function definition.

Of course that functions that return a new object for the same arguments, even if it's immutable, are not true math functions.

[mcphage]

Mathematical functions aren't too great a metaphor for computer functions. They share a lot of similarities—domain, range, inputs, outputs, composability. But mathematical functions just are, there's no notion of changing things—however, the most common purpose of computer software is to change things. So it breaks down, or you come up with some way of defining a change without anything changing, which adds a layer of abstraction to everything you try and do.

[mannykannot]

I think it is correct to say that, in the functional paradigm, you effect change by making something new (and forgetting some older things.) Regardless of the paradigm (other than self-modifying code, perhaps) programs just are, but they must be evaluated if they are to do something useful.

I will leave that last sentence as I wrote it, but it immediately leads me to wonder if functions that write functions have wandered into the self-modifying code realm?

[_lce0]

I really agree with you. Think that there's a tension between how a computer works and how a functions operate on data.

Immutability and Referential Transparency help reduce that friction, but in the end we still have not found a real solution. That's why languages like Haskell require a bunch of gymnastics just to allow IO to be seen as pure functions.