For what it's worth from a Haskell newbie (and from someone who's been doing FP since November, mainly in Scala.)<br><br>I really like Haskell's purity and having the clear separation between zero side effects and monads is most excellent.
<br><br>It was quite a brain change to program functionally. It took a lot of work and a lot of discipline. In Scala, I set myself the goal of not having any variables (except as instance variables of a very limited number of classes... Scala doesn't support monads), but to only use single-assignment values. At first, it was really hard to think in a new way. Now, I find that, even when I write Java code, I write in a functional style.
<br><br>The benefit for me is reducing the number of moving parts as well as forcing me to do significantly more design work up front. Now, the OO ideal was to model ones class hierarchy and the messages and the code will all flow automagically. In my 17 years, dozens of commercial applications, and 1M+ LoC of OO programming, it's never worked that way for me.
<br><br>On the other hand, programming in a state-minimized (or state-free) way makes me work a lot more to define my types and how the types interact with each other. I find that I'm spending a lot more time "up front" piecing the types together. I am spending no time worrying about hidden state (gee, if I call X before I call Y, the state will not be set up, so I have to shoe-horn some sort of test to make sure that the state is set up correctly.)
<br><br>I also find that my code is shorter and less dense at the same time. The "what" part of my code is easier to see because filter/map/zip constructs are a lot less distracting than "new array/for/if/..." constructs.
<br><br>The proof is in the output for me. My web framework (<a href="http://liftweb.net">http://liftweb.net</a>) and the commercial product that my team is building with Scala (<a href="http://www.circleshare.com">http://www.circleshare.com
</a>) have been remarkably stable and low in bugs. And the bugs have by and large been "logic" bugs rather than "changing X which caused a bug in Z because the state was wrong" bugs. The code bases are large enough, that I'd normally be expecting to see breakage from unexpected side effects from code changes. That hasn't started happening.
<br><br>Part of the challenge that Haskell and Scala and the other FP languages face is the pain developers face as they change the way they approach and solve problems. Based on my 28 years of professional coding, I think that FP is the single best and single most important technology that I've invested my time in. I think that Haskell's brand of purity is hyper-important and will allow for assembly of significantly more complex systems than will any other technology that I've seen.
<br><br>Please, keep to the vision. The vision is powerful, inspiring, and I believe correct.<br><br>Thanks,<br><br>David<br><br><div><span class="gmail_quote">On 8/8/07, <b class="gmail_sendername">Paul Hudak</b> <<a href="mailto:paul.hudak@yale.edu">
paul.hudak@yale.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<font face="Arial">All of the recent talk of support for imperative
programming in Haskell makes me really nervous. To be honest, I've
always been a bit uncomfortable even with monad syntax. Instead of:<br>
<br>
do x <- cmd1<br>
y <- cmd2<br>
...<br>
return e<br>
<br>
I was always perfectly happy with:<br>
<br>
cmd1 >>= \x-><br>
cmd2 >>= \y-><br>
...<br>
return e<br>
<br>
Functions are in my comfort zone; syntax that hides them takes me out
of my comfort zone.<br>
<br>
In my opinion one of the key principles in the design of Haskell has
been the insistence on purity. It is arguably what led the Haskell
designers to "discover" the monadic solution to IO, and is more<br>
generally what inspired many researchers to "discover" purely
functional solutions to many seemingly imperative problems. With
references and mutable data structures and IO and who-knows-what-else
to support the Imperative Way, this discovery process becomes stunted.<br>
<br>
Well, you could argue, monad syntax is what really made Haskell become
more accepted by the masses, and you may be right (although perhaps
Simon's extraordinary performance at OSCOM is more of what we need).
On the other hand, if we give imperative programmers the tools to do
all the things they are used to doing in C++, then we will be depriving
them of the joys of programming in the Functional Way. How many times
have we seen responses to newbie posts along the lines of, "That's how
you'd do it in C++, but in Haskell here's a better way...".<br>
<br>
I hope I don't start a flame war with this post -- I'm just expressing
my opinion, which admittedly is probably regressive rather than
progressive :-).<br>
<br>
-Paul<br>
</font><br>
<pre cols="72">-- <br>Professor Paul Hudak<br>Department of Computer Science Office: (203) 432-1235<br>Yale University FAX: (203) 432-0593<br>P.O. Box 208285 email: <a href="mailto:paul.hudak@yale.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
paul.hudak@yale.edu</a>
New Haven, CT 06520-8285 WWW: <a href="http://www.cs.yale.edu/%7Ehudak" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.cs.yale.edu/~hudak</a>
</pre>
</div>
<br>_______________________________________________<br>Haskell-Cafe mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">
http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br><br></blockquote></div><br><br clear="all"><br>-- <br>lift, the fast, powerful, easy web framework<br><a href="http://liftweb.net">http://liftweb.net</a>