I haven't been following this thread closely, but would it be rude to suggest that someone who
doesn't want to put the effort into learning the (admittedly difficult) concepts that Haskell
embodies shouldn't be using the language? Haskell was never intended to be The Next Big Popular
Language. It was intended to be a purely functional language for people who want to use purely
functional languages and who are willing to learn new concepts if it enables them to program in that
style. That now includes IO and monads, so if people aren't willing to learn that, they should go
on using python or whatever. That said, of course we should strive to have better teaching
materials, but there are a number of good IO/monad tutorials on the web.
I used to love programming in python, but then I learned Scheme, then Ocaml, and then Haskell and at
each stage I absorbed a few new concepts. Now programming in python feels very primitive to me.
Haskell is interesting because it enables us to write programs more effectively (in many cases, at
least) than we can in other languages, but the learning curve is steep -- there ain't no such thing
as a free lunch.
Mike
David Menendez wrote:
On Dec 10, 2007 1:44 PM, Dan Piponi <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
When someone comes to me and says "I have this Python script that
scans through these directories and finds the files that meet these
criteria and generates a report based on this template, could I do it
better in Haskell?" it'd be good to have a better answer than "to do
this you could use the IO monad, but to do things properly you need to
understand monads so here, learn about the List monad and the Maybe
monad first, understand how this interface abstracts from both, come
back when you've finished that, and then I'll tell you how to read and
write files".
I thought your blog post about the IO monad for people who don't care
about monads (yet) was a pretty good start.
As it happens, the IO monad was one of the things that attracted me to
Haskell. When I was learning SML in college, I wondered how one could do
I/O in a functional style. SML provides I/O via functions with
side-effects, which struck me as crude and contrary to the functional
style.
Years later, I encountered Haskell and learned that it handled I/O tasks
using something called the "IO monad". I had no idea what a monad was,
but I understood the implications: Haskell could be referentially
transparent *and* do I/O. This was what inspired me to learn the language.
As I learned more Haskell, I discovered the other monads and the Monad
class and the full generality of the "do" notation. Eventually, a light
came on and monads suddenly made sense.
I don't know if it's best to learn the IO monad before or after other
monads. I suspect no choice is right for everyone. An experienced
programmer who is new to Haskell is going to have different questions
than a beginning programmer with no preconceived notions.
--
Dave Menendez <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
<http://www.eyrie.org/~zednenem/ <http://www.eyrie.org/~zednenem/>>
------------------------------------------------------------------------
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
