[Haskell-cafe] Re: Why functional programming matters

[Derek Elkins]

On Thu, 2008-01-24 at 10:45 +0100, Peter Hercek wrote:
> Tim Chevalier wrote:
> > On 1/23/08, Peter Hercek <phercek at gmail.com> wrote:
> >> Other things did not seem that great for me from the beginning. For
> >> example: referential transparency - just enforces what you can take care
> >> not to do yourself
> > 
> > ...if you never make mistakes, that is.
> > 
> >> (e.g. in C# you just cannot be sure some function is
> >> referentially transparent even when comment claims so - which of course
> >> sucks because programmers are not disciplined).
> > 
> > But if that's the point you're trying to make, I agree that a lot of
> > programmers seem to think they don't make mistakes, and thus might not
> > be receptive to the siren song of referential transparency :-)
> 
> What I wanted to say is that focusing on referential transparency
>   will not appeal that much to an imperative programmer especially
>   when he needs to overcome Haskell learning curve. What may appeal,
>   though, are the consequences of it like:
> * easier to repeat test cases for bugs
> * easier to do automated tests (like quickcheck) since state space
>    is not that big (provided I count automatic vars on stack/heap
>    as state)
> * makes laziness to work which allow easier and efficient expression
>    of producer - consumer type of code
> * easy undo (no need for memento pattern etc)
> * allows monads to work which adds options like built-in user logging
>    or error recovery
> * better changes for compilers to find parallelize automatically
> * safe STM
> ... and probably a lot of more goodies
> 
> On the other side there are downsides like what to do instead of
>   reactive GUIs? GUI is a big part for a lot of applications. A lot
>   of efficient algorithms we have are state based. And again probably
>   more.
> 
> If referential transparency by itself would be that important for
>   imperative languages then it would be already added to IDEs* in
>   some form like a popup menu item with name "check function purity".
>   In some cases you could actually decide that the function is pure
>   (especially if you would go deeper analyzing and annotating your
>   objects with purity flags in your IDE).

Doing it in the IDE would a) require much more from most IDEs and b) be
almost entirely useless.  Most IDEs don't even get as far as parsing the
code, even the the best rarely know much about the actual semantics of
the language.  This would require a rather deep analysis and ultimately
it is undecidable.  Practically speaking, having such a feature in the
IDE would be useless unless the programming style of most "imperative"
programmers changed dramatically.  The only functions such an analysis
would say were pure are those that were rather trivial.  Either way,
having such a feature in the IDE doesn't really help.  A purity checker
in the IDE isn't going to help when the function/method is unknown, e.g.
when I write a function/method that takes a function or an object.  A
"purity annotation" would have to be at the language level, short of
doing a whole-program analysis which would be infeasible.