[Haskell-cafe] Re: When to teach IO (was Tutorial uploaded)

Bayley, Alistair Alistair_Bayley at ldn.invesco.com
Wed Dec 21 10:47:14 EST 2005

> From: haskell-cafe-bounces at haskell.org 
> [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Robin Green
> No, that's not what I meant at all. I meant that for *many* 
> but not all 
> practical programming tasks, IO is important. Games, GUI office 
> applications, database applications, web applications, etc.
> Compilers are atypical in this regard. Something that is perceived as 
> being only useful for a compilers and a few other academic-ish things 
> isn't going to be perceived as very practically useful.
> -- 
> Robin

Hear, hear. Compilers, and computationally complex programs in general,
are atypical. IMO, a lot of programming these days is integration work
i.e. shuffling and transforming data from one system to another, or
transforming data for reports, etc. Not many programmers write compilers
these days :-(  (apologies to the Simons, and John Meacham, and anyone
else who *has* written a compiler, Haskell or otherwise...)


It's good to start with IO. Reading and writing files, parsing and
printing (show and read), talking to databases, GUIs, and networking are
more-or-less essential activities, and people want to know early on how
to do these things. You don't have to introduce the IO monad; just tell
people that we separate IO functions from "pure" functions with this
special IO type, and, with the "imperative" do-notation, IO code in
Haskell looks a lot like IO code in C/Java/.Net. The Really Good Stuff
(real monadic programming) can come later.

Perhaps there are two different worlds to consider. Teaching Haskell to
tertiary students might well be better suited to a style where purely
functional programming is explored in some detail before IO and monads
are introduced. However, a jobbing programmer evaluating Haskell wants
to know how they do the things they're used to doing in other langauges,
and if they see the volume of stuff that must be covered before topics
like IO, GUIs, and networking, they'll start to look elsewhere... How
hard should it be to shove a window on the screen, or select some data
from a database?

Part of the problem is that we're not just introducing a new language,
we're introducing a new paradigm. I can see that a noob would choke if
you tried to ram it down their throat all at once. As a comparison, I
have some .Net books in front of me, and although they also introduce
the language first (declarations, choice, iteration, classes and
interfaces), it's pretty trivial stuff and can be skimmed over fairly
quickly, and then you quickly get into introspection (reflection), GUIs,
IO, databases, and networking. Indeed, the bulk of the book covers these

Confidentiality Note: The information contained in this message,
and any attachments, may contain confidential and/or privileged
material. It is intended solely for the person(s) or entity to
which it is addressed. Any review, retransmission, dissemination,
or taking of any action in reliance upon this information by
persons or entities other than the intended recipient(s) is
prohibited. If you received this in error, please contact the
sender and delete the material from any computer.

More information about the Haskell-Cafe mailing list