[Haskell-cafe] Re: Why functional programming matters

Peter Hercek phercek at gmail.com
Thu Jan 24 04:45:12 EST 2008


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).

* and IDEs like visual studio or eclipse are incredibly good compared
  to the stuff Haskell has; anyway IMHO all IDEs are not good enough
  - they could be much better

Anyway I'm not that qualified to discuss this (I hope this is my last
  post to this thread :) ). I just wanted to point out what could be
  a point of view of an imperative programmer based on what I remember
  from times I was getting more involved with functional programming.
  The reason I started with functional programming is sure not common
  - sometimes I may need to actually prove some program features.


Peter.



More information about the Haskell-Cafe mailing list