Re: When to teach IO (was Tutorial uploaded)

From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@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...) 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. *****************************************************************

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

"Bayley, Alistair"
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

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.
participants (4)
-
Bayley, Alistair
-
David Roundy
-
jerzy.karczmarczuk@info.unicaen.fr
-
Ketil Malde