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