Re: Side-effect freedom (Re: When transformation language)

Subject: Re: Side-effect freedom (Re: When transformation language)
From: Paul Prescod <papresco@xxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 19 May 1997 17:04:10 -0400
Vivek Agrawala wrote:
>  Also, could someone point me to a good discussion of the pros & cons of
>  freedom from side-effects?  I am still struggling with problem of
> writing
>  code without maintaining state.

Maybe if you describe what you are having a problem with a side-effect
ree solution could be suggested. I have only run across a few situations
where side-effects would actually make solving a problem much more easy. 

Side-effect freedom makes things much easier to reason about. I think of
all programming languages as living on a spectrum. Assembly language and
languages that are higher level abstractions of it (e.g. C, C++) are
built on top of the Turing-machine idea of computing: a bunch of squares
and your job as a programmer is to fill them and remember what is in
each square. Side-effect free languages build upon a mathematical
formalism called the Lambda-calculus. They start with the idea that
computing something can be done simply by doing a kind of string
substitution or macro replacement. This is easier to reason about
because the result of evaluating foo( a, b, c, d) is *always* the same
if a, b, c, d is the same.

foo( "a", "b", "c", "d") == foo( "a", "b", "c", "d" )

is always true in a functional language. 

But in a regular language you must think: "at what point is foo
executing? What is the state of object Q, a global variable?" 

So lets say that you are debugging a functional language program, all
that you have to know are the inputs and the value will be constant. You
don't have to remember all of the state that may be hanging around. Just
call the function with the values you want to test, check that the
return code is right, and you are done. In C++ or something you can't
really know if a situation is going to arise where some kind of bogus
object-state is going to change the return value of the function call at
some point in the future.

See also:

I don't want to get into a language war, because there are some things
that are much easier to do and think about with traditional languages
and some things that are easier to do with functional languages. I think
that document processing is in the second category: there is an input,
an output and the stylesheet is the mathematical function that maps one
to the other. You can certainly think of many applications that do not
fit this pattern of input-mapping-output and those are jobs I would
usually use something like Perl or C++ for.

 Paul Prescod

 DSSSList info and archive:

Current Thread