Tim Chevalier wrote:
On 1/23/08, Peter Hercek <[EMAIL PROTECTED]> 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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
