[Haskell-cafe] Re: Channel9 Interview: What makes imperative programming so difficult

[Doaitse Swierstra]

If you ask an "ordinary" programmer what is the effect of an  
assignment like:

x := <expr>

you will get an answer along the lines: the <expr> is evaluated and  
the result is stored in a box named "x".

If you ask him/her whether something else has happened the answer  
will usually be "no"; and this is the wrong answer, since one tends  
to overlook the fact that one has, by mentioning the variable "x",  
also indicated that the old value of "x" is no longer needed. As such  
imperative programming is "functional programming with explicit  
garbage collection".

This may have been a necessity in the old days, when memory was  
scarce and machines slow (in my first course on numeric algorithms we  
were taught to declare the variables x, y, z, n, m, i, and j, and the  
array a, and to solve our problems with those only; points would be  
deducted for making use of more variables, or not reusing whenever  
possible!). Nowadays I think everyone agrees that automatic garbage  
collection is a good thing; think about the amount of wasted  
programmer years of people figuring out where they have space leak,  
etc., and users of programs getting a disappointing feeling about  
computer science as a whole since apparently we keep delivering  
programs that stop to work at unpredictable moments.

So, one might wonder whether assignments are always bad, bringing us  
back to the OO discussion. Of course if we have the following  
expression:

  digest.chew.eat.serve.cook.chop.pluck.kill $ chicken

we all have a definite feeling that after applying the functions, the  
original object is no longer available, and the FP view does not feel  
entirely natural.

  Doaitse Swierstra