What is a difference between definitions reference transparency and deterministic function?

Question

Reference transparency (Wikipedia):

An expression is said to be referentially transparent if it can be replaced with its value without changing the behavior of a program (in other words, yielding a program that has the same effects and output on the same input).

And also (Learn you some Erlang):

Functions always returning the same result for the same parameter is called referential transparency

Deterministic function (MSDN):

Deterministic functions always return the same result any time they are called with a specific set of input values.

If we are talking about deterministic functions, we mean referential transparency? If we are talking about referential transparency, we mean deterministic functions?

Answer 1

Expressions can be more complex than a simple function call, so "referential transparency" applies to a larger class of entities than "deterministic". As applied to functions they are the basically the same in that a function application is referentially transparent if and only if it is deterministic. An expression built up out of deterministic functions will be referentially transparent, though it is also possible to have an expression referentially transparent even though some of its ingredients are non-deterministic (0*rand() for a silly example, although there are less silly examples where random seeds are used to get to a deterministic answer).

Answer 2

Note that your definition of referential transparency specifically mentions "the same effects and output on the same input". If your expression includes effects, such as I/O, then it can be referentially transparent without being deterministic (both as defined above).

On the other hand, pure functional programming focuses on functions without effects, which can be reliably deterministic. Deterministic functions are necessarily referentially transparent, but the reverse is not true.

Consider making the distinction between "effects", which are the important and necessary business of writing programs in the first place, and "side effects" where effects may occur that are not apparent to the caller. This opacity, which is the opposite of referential transparency, is what makes it hard to reason about the code you are calling.