IMHO and being a newbie having 20 years of professional C/C++/C#
experience but hardly any Haskell experience, I agree with this… I find the
monad syntax very confusing, because it looks so much like imperative code, but
it isn’t. Personally I also liked the Concurrent Clean approach, although this
also introduced extra syntax for the compiler, while ‘cmd1 >>= \x…’ does
not. You have to type more, but you see much clearer what is going on.
Peter
PS: It would be very nice for beginners to have a special tool /
text editor that allows you see the desugared form of monads and other
constructs…
From: haskell-cafe-bounces@haskell.org
[mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Paul Hudak
Sent: Wednesday, August 08, 2007 8:21 PM
To: haskell-cafe@haskell.org
Cc: paul.hudak@yale.edu
Subject: [Haskell-cafe] a regressive view of support for imperative
programming in Haskell
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@yale.edu
New Haven, CT 06520-8285 WWW: www.cs.yale.edu/~hudak