[Haskell-cafe] a regressive view of support for imperative programming in Haskell

[David Pollak]

For what it's worth from a Haskell newbie (and from someone who's been doing
FP since November, mainly in Scala.)

I really like Haskell's purity and having the clear separation between zero
side effects and monads is most excellent.

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.

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.

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

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.

The proof is in the output for me.  My web framework (http://liftweb.net)
and the commercial product that my team is building with Scala (
http://www.circleshare.com) 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.

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.

Please, keep to the vision.  The vision is powerful, inspiring, and I
believe correct.

Thanks,

David

On 8/8/07, Paul Hudak <paul.hudak at yale.edu> wrote:
>
>  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:
>
> do x <- cmd1
>      y <- cmd2
>      ...
>      return e
>
> I was always perfectly happy with:
>
> cmd1 >>= \x->
> cmd2 >>= \y->
> ...
> return e
>
> Functions are in my comfort zone; syntax that hides them takes me out of
> my comfort zone.
>
> 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
> 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.
>
> 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...".
>
> 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
> :-).
>
>   -Paul
>
> --
> Professor Paul Hudak
> Department of Computer Science    Office: (203) 432-1235
> Yale University                   FAX:    (203) 432-0593
> P.O. Box 208285                   email:  paul.hudak at yale.edu
> New Haven, CT 06520-8285          WWW:    www.cs.yale.edu/~hudak <http://www.cs.yale.edu/%7Ehudak>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


-- 
lift, the fast, powerful, easy web framework
http://liftweb.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20070809/ac1e5e85/attachment.htm