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

[peterv]

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 at haskell.org
[mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Paul Hudak
Sent: Wednesday, August 08, 2007 8:21 PM
To: haskell-cafe at haskell.org
Cc: paul.hudak at 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 at yale.edu
New Haven, CT 06520-8285          WWW:    www.cs.yale.edu/~hudak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20070808/d64dc972/attachment-0001.htm