KC comments the posting of Donn Cave referring to the soundness of some potential approach of software engineers:

Apparently on such solid ground that you hinder their critical thinking skills by answering for them

Monsieur KC, do you want to discuss, or just to be cute?

In both cases, begin by signing your posts. I will not discuss with an anonymous, and concerning your question about referential transparency, I permit myself to send you to some standard literature. Over.

==
Chris Smith:

When we're talking about different uses of the word "function" in
programming languages, side effects refer to any effect other than
evaluating to some result when applied to some argument.  For example,
in languages like C, printf takes some arguments, and returns an int.
When viewed as just a function, that's all there is to it; functions
exist to take arguments and produce return values.  But C extends the
definition of a function to include additional effects, like making
"Hello world" appear on a nearby computer screen.

... And here I disagree. If printf, or whatever explodes an atomic bomb, this is not a "side effect". If a procedure executes such a statement: "x = x+1", or "a[1]=a[2]", it IS.
And even that, not always !

In Clean, which is as pure as Haskell, there are "unique access" variables, and it is possible to write (+/-...)

# myFile = write myFile "Hello World"

And the point is that WHATEVER happens to the outer world, and the computer file system in particular, there are no side effects within the program. The "#" construction is a "temporal", sequential part of a purely functional expression, exactly as a monadic chain in Haskell, disguised as a do block. There are two "distinct" file objects, the "previous", and the "next" one, which happen to share the same name, because *the type system* prevents that a computing block refers to both. Either the old, or the new.

This is my philosophy. If somebody disagrees, that's alright.

Jerzy Karczmarczuk