Re: When to teach IO (was Tutorial uploaded)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: When to teach IO (was Tutorial uploaded)

Bayley, Alistair
> From: [hidden email]
> [mailto:[hidden email]] 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...)

  http://www.mcs.vuw.ac.nz/~kjx/papers/nopp.pdf

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
topics.

Alistair
*****************************************************************
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.
*****************************************************************
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: When to teach IO (was Tutorial uploaded)

David Roundy
On Wed, Dec 21, 2005 at 03:47:14PM -0000, Bayley, Alistair wrote:
> 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.

I'd just add that in my opinion its handling of IO is actually one of the
*strengths* of Haskell.  The primary advantage Haskell has (in my mind) is
that it is strongly typed, and the monadic handling of IO is an impressive
display of how much that typing can clarify one's code.  I'd far rather
write IO code in Haskell than in any other language.  Pure code can be
written in any language pretty easily (albeit more easily in a functional
language), since pure code doesn't have the complexities present in IO
code, and it's in handling those complexities that the type-safety of
Haskell really helps.
--
David Roundy
http://www.darcs.net
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: When to teach IO

Ketil Malde-2
In reply to this post by Bayley, Alistair
"Bayley, Alistair" <[hidden email]> writes:

> 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 :-(  

I'm sorry, but, if we define "compiler" as a input->process->output
pipeline, then:

  "shuffling and transforming data" = compiler
  "transforming data for reports" = compiler

I actually think a lot of useful programs fit into that category.
(I certainly hesitate to accept the alternative, i.e. to admit that
all my programs are useless :-)

-k
--
If I haven't seen further, it is by standing in the footprints of giants

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: When to teach IO

jerzy.karczmarczuk
Ketil Malde writes:

> I'm sorry, but, if we define "compiler" as a input->process->output
> pipeline, then:
>
>   "shuffling and transforming data" = compiler
>   "transforming data for reports" = compiler
>
> I actually think a lot of useful programs fit into that category.

Ketil, calling "compiler" all this stuff you mention, simply
desintegrates the very definition of compilation. ALL is compiler...
An image synthesis program (say, a ray-tracer like POV-Ray) is a
compiler. TeX is a compiler. Etc. ... Perhaps, if you wish. But still,
most people *USE* TeX or POV-Ray to make images or formatted documents.

So, I think that your opponent (was it Alistair Bayley?) is mostly
right claiming that people *write compilers* rarely. Even if I accept
your philosophy that all/most data processing activities is a *kind*
of compilation, in order to keep some minimum of discipline, I believe
that it is good to assume that

+ Compilers are *universal*; they should handle a large set of sources,
 transforming them in something digested, reformatted, rendered visually
 etc.
+ The output of the compiler *should, at least conceptually* preserve the
 semantics - as we see it - of the source. Thus, say, a game is not
 a compiler.
+ They are more or less autonomous. TeX is a compiler. An add-on, say,
 a LaTeX macro-package (or an #included script to POV-Ray) are not, they
 just enrich the grammar of processed documents.
+ Compilers must respect some criteria of decency. (This is my idée
 fixe, I used to insist on that during all my compilation courses...)
 They are not allowed to break on erroneous data. They MUST terminate
 (gracefully). Etc.

What is the percentage of programs written by average Norwegian salmon
eaters which respect that? Concerning local French snail-eaters ... well,
I lost all illusions quite a time ago.

Jerzy Karczmarczuk

PS. About the subject (when to teach IO): don't be sectarians. If
   a programming course insists on algorithmics, the IO issues can be
   postponed a bit. If it insists on practical data processing, IO
   should come in immediately. A programming course should be
   harmonious, homogeneous, well assembled, interesting, and easy to
   put into practice (...sorry for triviality, you ALL know that...),
   and the details depend on the language and on the teacher. In Scheme
   it is easier than in Haskell.


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: When to teach IO

Bayley, Alistair
In reply to this post by Ketil Malde-2
> [mailto:[hidden email]] On Behalf Of
> [hidden email]
>
> PS. About the subject (when to teach IO): don't be sectarians. If
>    a programming course insists on algorithmics, the IO issues can be
>    postponed a bit. If it insists on practical data processing, IO
>    should come in immediately. A programming course should be
>    harmonious, homogeneous, well assembled, interesting, and easy to
>    put into practice (...sorry for triviality, you ALL know that...),
>    and the details depend on the language and on the teacher.
>    In Scheme it is easier than in Haskell.


_What_ is easier in Scheme than in Haskell? IO, or teaching (IO)?
*****************************************************************
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.
*****************************************************************
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: When to teach IO

jerzy.karczmarczuk
Bayley, Alistair asks (commenting my statement):

> _What_ is easier in Scheme than in Haskell? IO, or teaching (IO)?

In my humble opinion, both. Mainly for psychological reasons,
we (well, "we", students more than "we", old Haskell cowboys...)
are used to the sequentiality of I/O. As people mentioned here,
even for a newbie there is no special hindrance to write a
do { ... putSomething ...}, especially if this "newbie" is a
<<faux-débutant>>, as the French say; if he/she has already some
acquaintance with other languages.

But, mind you, the teacher may want to convey the static nature of
functional programs first. The teacher may wish to *avoid* the
sequentiality issues, he may insist on expression-centered programming,
and then the IO in Haskell becames *another language*, different
from typical interactively tested recursive functions, all the stuff
you know.

That's it. In Scheme the integration of IO with the rest of the program
is more natural, you just have expressions with some side-effects, and
you accept that side-effects are natural.


Jerzy Karczmarczuk


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe