
Tim Chevalier wrote:
On 1/23/08, Peter Hercek
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.