Probably one should understand how to use monads before worrying about the do-notation. Here are some references:

I don't totally agree. You can teach monads to beginners just fine using the do-notation. Unsuprisingly its very much like teaching monads using bind. You describe a two line do-block as the basic building block for combining two actions into a single action: do { result1 <- act1 expr involving result1 building an act } show that you can nest them (expr can be another do block) do { result1 <- act1 do { result2 <- act2 expr involving result1 and result2 building an act } } and how the do-notation doesn't require you to start a new do-block for nesting of do's and let's do { result1 <- act1 let val1 <- expr resulting in a pure value result2 <- act2 expr involving result1 and result2 building an act } Then you can describe pattern matching and fail... I've had debates about what should be taught, and obviously not everyone agrees, but at the least, its possible and reasonable and understandable to teach do-notation first.

Denis

Tim Newsham http://www.thenewsh.com/~newsham/

On Dec 3, 2007 1:09 PM, Denis Bueno wrote:

I don't think I can conclude that there are *no* reasons to teach the do-notation first. I just think that it is more instructive to teach it later.

It's standard in mathematics teaching, when introducing a mathematical structure X, to ensure that students have the knowledge to understand an example of X before they see the definition of X. So students won't study groups before they've met the integers, they won't study fields before they've met the rationals, and they won't study topology until they're familiar with the real line. Not just met them either, usually they've usually completely internalised the examples before moving onto the general structure. The problem with monads is that students have never knowingly met an example of a monad before. If you teach them do-notation for IO without monads, and they get completely familiar with it (which (1) I claim is easy: http://sigfpe.blogspot.com/2007/11/io-monad-for-people-who-simply-dont.html and (2) is inevitable if they want to see the output of their programs) then when they come to learning about monads in general they'll have an example they don't even have to think about. The more adventurous ones may even discover some of the monad laws for themselves if they experiment with nested do's like in Tim Newsham's examples (and think them so obvious they hardly need to be graced with the name "law"). -- Dan

On Dec 3, 2007 3:54 PM, Ben Franksen wrote:

I don't buy this. As has been noted by others before, IO is a very special case, in that it can't be defined in Haskell itself, and there is no evaluation function runIO :: IO a -> a.

I'm not sure what a function of type m a -> a has to do with the concept of a monad. And I don't really see what the problem is with the IO monad not being definable in (pure) Haskell. IO exposes the same interface as every other Monad, and you need to use that interface to get visible results. So people have to learn it whatever. And the whole point of the Monad is that it's an interface, not a specific implementation.

I'd rather use a simple example like Maybe (modeling failure as an effect).

And I'd like to see more people getting off the ground doing interesting stuff with Haskell before their attention spans for pointless-seeming new stuff run out. I'm not talking about the smartest people in computer science courses here. I'm talking about the millions of people writing everyday Python and Ruby scripts, say, who might benefit from a more expressive, type-safe, well-thought out, fast and compiled language. -- Dan

Dan Piponi wrote:

On Dec 3, 2007 3:54 PM, Ben Franksen wrote:

...

I don't buy this. As has been noted by others before, IO is a very special case, in that it can't be defined in Haskell itself, and there is no evaluation function runIO :: IO a -> a.

I'm not sure what a function of type m a -> a has to do with the concept of a monad. And I don't really see what the problem is with the IO monad not being definable in (pure) Haskell.

Funny you say that because this is exactly my point! Both have nothing to do with monads per se. But if IO is not only the first monad one learns about, but also used as the first example to explain monads in general, then the special features of IO will remain associated with monads in general, leading to a whole jumble of completely wrong ideas about them. For example, since IO can't be defined in Haskell, Monads get associated with the idea that there is some 'magic' to make them work going on. (The OP's question about 'the do construct' nicely illustrates this.) Another common fallacy is to think of monads as 'sequencing effects', when in fact this is not necessarily the case. Again, IO is a bad example, because it is too special to generalize from, its effect base too complex to study comprehensively, and its implementation not accessible and therefore obscure. With a simple monad it is easy to see that, if any sequencing of effects happens at all, then this is due to data dependencies alone, period. (I fell afoul of both of the above mistakes and it wasn't easy to get them out of my head.)

IO exposes the same interface as every other Monad, and you need to use that interface to get visible results. So people have to learn it whatever. And the whole point of the Monad is that it's an interface, not a specific implementation.

Indeed, it is an interface, and a /very/ general one. It is in fact so general that in itself alone it is completely useless. You always need an effect base to get useful things done. This is yet another problem with IO as the standard example for monads: its effect base is huge and poorly structured. This again makes it difficult to see exactly which intuitions about IO can be generalized to arbitrary monads and which not. People (and especially those who start learning Haskell, coming form imperative languages) keep asking the question: all very nice, but what exactly /is/ a monad? As with the concept of a group in algebra ('a set with an operation bla bla satisfying the laws ...)', you can of course say 'a type constructor of kind bla bla with functions bla bla satisfying the laws...'. However this won't really help the newcomer. What helps is examples. And looking into the implementation of a simple monad greatly helps to dispell many kinds of wrong ideas one might have (due to exclusive exposure to IO as the prime example for a Monad).

...

I'd rather use a simple example like Maybe (modeling failure as an effect).

And I'd like to see more people getting off the ground doing interesting stuff with Haskell before their attention spans for pointless-seeming new stuff run out. I'm not talking about the smartest people in computer science courses here. I'm talking about the millions of people writing everyday Python and Ruby scripts, say, who might benefit from a more expressive, type-safe, well-thought out, fast and compiled language.

What is pointless about failure and how to handle it? IMO this is the /most/ immediate practical problem one encounters whenever the Python or Ruby (or, for that matter, Haskell) script starts to exceed a few lines. Cheers Ben

I agree with Dan here. IO is important because you can't write any real program without using it. So why not teach enough of it to get people off the ground straight away? People who hang around long enough to do some more Haskell programming will run into the other monads sooner or later. But IO is an unavoidable step to writing Haskell programs. On Dec 4, 2007 5:11 AM, Dan Piponi wrote:

On Dec 3, 2007 6:36 PM, Ben Franksen wrote:

...

then the special features of IO will remain associated with monads in general, leading to a whole jumble of completely wrong ideas about them.

As I only learnt about monads a couple of years ago, the process is still fresh in my mind. I wasted quite a bit of time labouring under the impression that monads were primarily about sequencing. But that wasn't because I incorrectly generalised from IO. It was because countless people out there explicitly said they were about sequencing. I suspect that if courses started with the List monad there'd be countless blogs telling people that monads are a way to eliminate loops from your code like the way list comprehensions are used in Python.

...

This is yet another problem with IO as the standard example for monads: its effect base is huge and poorly structured.

You don't teach *all* of IO to students in one go!

...

This again makes it difficult to see exactly which intuitions about IO can be generalized to arbitrary monads and which not.

That's true of any monad. IO is unique. [] is unique. Cont is unique. All of them can lead you down the garden path. You need to see multiple monads, and it helps if you can sneak an example under a student's nose so they can already reason about monads before they even know what a monad is.

...

What is pointless about failure and how to handle it?

It's pointless when you're still trying to make your first tweaks to "Hello, World!" work. -- Dan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Am Sonntag, 9. Dezember 2007 18:31 schrieb Conal Elliott:

...

IO is important because you can't write any real program without using it.

Ouch! I get awfully discouraged when I read statements like this one. The more people who believe it, the more true it becomes. If you want to do functional programming, instead of imperative programming in a functional language, you can. For instance, write real, interactive programs in FRP, phooey, or TV. And if you do, you'll get semantic simplicity, powerful & simpler reasoning, safety and composability.

- Conal

Interactive programmes without using IO? Cool :) I think you misunderstood Lennart. Would you deny that any useful programme has to do at least some of the following: -accept programme arguments at invocation -get input, be it from a keyboard, mouse, reading files, pipes... -output a result or state info, to the monitor, a file, a pipe... I think Lennart was referring to that, you HAVE to know a little IO to write programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile, appendFile. And therefore some use of the IO monad has to be taught relatively early. Another thing is that you should use IO only where it's necessary, which is admittedly rare. Cheers, Daniel

Am Sonntag, 9. Dezember 2007 23:35 schrieb Ketil Malde:

Daniel Fischer writes:

...

...

...

IO is important because you can't write any real program without using it.

Ouch! I get awfully discouraged when I read statements like this one.

I think Lennart was referring to that, you HAVE to know a little IO to write programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile, appendFile. And therefore some use of the IO monad has to be taught relatively early.

Emphasis on *use*, introduce the concept of monads not before lists, Maybe and Either.

Well, I guess you could get pretty far using 'interact' - far enough in an educational setting to do lists and Maybe, and then monads, before introducing monadic IO.

-k

Pretty far, yes, and in an educational setting, at a university, it is quite common, I believe, to use an interpreter for a while, not producing executables (that's how I met Haskell, write pure functions and type expressions at the Hugs prompt). But what about a tutorial for programmers? How would you do main = do putStrLn "Please enter your name." name <- getLine putStrLn $ "Hello " ++ name ++ ", nice to meet you." in that setting? I doubt you could keep many interested without telling them how to create standalone programmes, including reading input from stdin and printing output to stdout. Cheers, Daniel

Am Montag, 10. Dezember 2007 10:36 schrieb Ketil Malde:

Daniel Fischer writes:

...

...

Well, I guess you could get pretty far using 'interact' - far enough in an educational setting to do lists and Maybe, and then monads, before introducing monadic IO.

Pretty far, yes, and in an educational setting, at a university, it is quite common, I believe, to use an interpreter for a while, not producing executables (that's how I met Haskell, write pure functions and type expressions at the Hugs prompt). But what about a tutorial for programmers? How would you do

Well, yes, some things do get complicated, and I'm not suggesting that "interact" will suffice for real programs. I still agree with the faction that thinks monadic IO should be taught after non-IO monadics - which, especially for programmers, can be quite early in the curriculum. After all, lists and algebraic data types are central and simple concepts.

I have no teaching experience, and I have not thought a great deal about how to teach monads, but I think it would be good to have some familiarity with a couple of monads - most notably lists - when the monad 'interface' is explained to give examples of how different data types share some concepts. I think, having IO as one example among others isn't necessarily bad, but could be convinced otherwise.

I don't think you *need* to teach input-print sequential programs, though. This is functional programming after all, why not build a compiler instead?

By all means, building a compiler for a simple enough language would be an interesting task in the course of which many concepts can be introduced. But would Joe Programmer, who heard about this exciting language called Haskell and then grabbed a tutorial to see whether it's something for him be content to type expressions to the interpreter prompt until the compiler is complete, monads have been explained and only after that he is told how to read/write files, stdin, stdout?

...

I doubt you could keep many interested without telling them how to create standalone programmes, including reading input from stdin and printing output to stdout.

Well, my first "real", standalone haskell program was reading my telephone log from stdin, matching against an internal database, and outputting calls with time and name to stdout. I used standard features like shell IO redirection in and 'tee' to integrate with the rest of the system.

I then moved on to monadic IO, but wish I'd done monads in general first. YMMV.

-k

Cheers, Daniel

On Mon, 10 Dec 2007, Dan Piponi 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". And I definitely want a better answer than "Haskell I/O is performed using the IO monad but everyone thinks this is bad so just wait a few years and someone may write a fancy new nice combinator library that does exactly what you want". There are thousands of competing programming languages out there, and there are dozens that are viable choices for the task I just mentioned. If my response to their question takes longer than the time it would take to find another language and implement a solution, then Haskell will remain a niche language.

I raise my question once again: Must Haskell's tutorials be tailored to impatient programmers? Does Haskell need quick&dirty hackers?

On Dec 10, 2007 11:00 AM, Henning Thielemann wrote:

Does Haskell need quick&dirty hackers?

The question isn't "Does Haskell need quick&dirty hackers?" It's "would we get better software (using your favourite metric) if we put Haskell into the hands of quick and dirty hackers?". I think the answer might be yes. Note also that there are many classes of people who fit the "quick and dirty" category. There are people who have busy full time jobs and who might benefit greatly from Haskell if they could get started relatively quickly. There are people whose primary job is not programming but who still need to program (eg. to script their applications). And of course there are people who who are just quick and dirty hackers by nature. -- Dan

On Dec 10, 2007, at 12:40 PM, Dan Piponi wrote:

On Dec 10, 2007 11:00 AM, Henning Thielemann wrote:

...

Does Haskell need quick&dirty hackers?

The question isn't "Does Haskell need quick&dirty hackers?" It's "would we get better software (using your favourite metric) if we put Haskell into the hands of quick and dirty hackers?". I think the answer might be yes.

You are so right - at least, to the extent that Haskell has any potential to exert a positive influence on anyone in that category. A lot of these wretched hackers are people who cared more about some end than the means to it, and have accordingly accomplished things that are now important ... and need to be maintained. To the despair of all concerned. I think you'll get a better Haskell, too. Don't let it turn into some weird Gnostic cult where pneumatics liberate themselves from the tainted bonds of earth by feasting on air and sunlight only. Donn Cave

On 10/12/2007, Henning Thielemann wrote:

On Mon, 10 Dec 2007, Dan Piponi 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". And I definitely want a better answer than "Haskell I/O is performed using the IO monad but everyone thinks this is bad so just wait a few years and someone may write a fancy new nice combinator library that does exactly what you want". There are thousands of competing programming languages out there, and there are dozens that are viable choices for the task I just mentioned. If my response to their question takes longer than the time it would take to find another language and implement a solution, then Haskell will remain a niche language.

I raise my question once again: Must Haskell's tutorials be tailored to impatient programmers? Does Haskell need quick&dirty hackers?

Sigh. I've seen this type of comment on this list so many times, and I still feel insulted by it. Must the Haskell community (and yes, I know it's not everyone, it's quite probably only a few members, but it feels like a lot) treat anyone who just wants to get a job done, while being open minded enough to consider a new and very unconventional language, as being "impatient" and a "quick and dirty hacker"? I'm sorry. I left it quite a while before I responded, so that my initial annoyed feeling could subside, but it didn't. I've hit all of Dan's barriers (apart from fear of recursion :-)) and yet I would not characterise myself as you describe (OK, maybe somewhat impatient :-)). Also, I have a fair bit of experience with non-imperative styles - I have, over the years, learnt a number of languages including Lisp, Prolog, Scheme and many others with functional or non-imperative aspects (I even recall looking a little at Hope and Miranda a long while ago). Haskell is the most practical functional language I have encountered, but I still feel that IO (in the most general sense of interaction with the outside world) is hard in Haskell[1]. Maybe it *can* be easy, but it isn't yet. And ignoring that fact isn't helping anyone. Paul. [1] Certainly you can toss out examples of easy IO in Haskell. Things like interact help a lot. But ultimately, you hit something hard - maybe it's handling errors robustly while using IO, or interacting with a database rather than a screen, or whatever. But at some point, you run out of clean off-the-shelf encapsulations, and get to genuinely hard stuff - and that happens in a huge step change, rather than a gradual increase of complexity that you can take as slowly as you need to.

On Mon, 10 Dec 2007, Paul Moore wrote:

On 10/12/2007, Henning Thielemann wrote:

...

I raise my question once again: Must Haskell's tutorials be tailored to impatient programmers? Does Haskell need quick&dirty hackers?

Haskell is the most practical functional language I have encountered, but I still feel that IO (in the most general sense of interaction with the outside world) is hard in Haskell[1]. Maybe it *can* be easy, but it isn't yet. And ignoring that fact isn't helping anyone.

I myself didn't start with IO in Haskell, because I could do this in imperative languages. I didn't learnt Haskell in order to be able to implement something, that I couldn't program before. I used Haskell for implementing things more cleaner, more elegant than before. Things that I couldn't implement more elegant in Haskell, I didn't implement in Haskell. I started in Haskell with what is especially easy to do in Haskell, for me this was solving mathematical problems. GHCi was the way I interacted with Haskell. I didn't do IO for more than half a year. My first programs with IO only contained writing data to files, then reading from files. No interaction with the user or argument parsing. Due to Hal Daume's tutorial I found the State monad useful early. Later I did IO, Reader, List monad and then monad transformers. In retrospective, the List monad should have been earlier on my plan because it is the right tool for solving problems by systematic search. I think that getting a job done (maybe even with time constraint) is not a good way to really learn a language. You will try to solve the problems in the way you solved them in other languages, because that is the way you are used to, and this promises to be the fastest one.

Am Dienstag, 11. Dezember 2007 14:46 schrieb Hans van Thiel:

On Mon, 2007-12-10 at 20:00 +0100, Henning Thielemann wrote: [snip]

...

I raise my question once again: Must Haskell's tutorials be tailored to impatient programmers? Does Haskell need quick&dirty hackers?

IMO yes, because it exposes the language to the outside world and that's a form of testing. In the end, anything that's not usable is useless. Paraphrasing a quote about science in general, "There is nothing about Haskell that cannot be grasped by a second rate mind through persistence." Let's not exaggerate how difficult and special it all is. And the purpose of a tutorial is not to make the writer look smart and important, but to ease things for the reader. I wouldn't want to exclude the scurrilous unwashed from the Haskell experience, this close to Christmas, too. :-)

Regards,

Hans van Thiel

Maybe there are also patient people in the outside world so that we can still expose Haskell to the outside world while not trying to attract quick-and-dirty hackers. ;-) Haskell is not a quick-and-dirty language but quite the opposite. Haskell’s unique selling propositions are features like type classes, higher order functions and lazy evaluation which make life easier in the long term. The downside of these features is that they might make life harder in the short term. That said, I definitely think that we should make learning the language as easy as possible. But our ultimate goal should be to primarily show newcomers the Haskell way of problem solving, not how to emulate Python or Java programming in Haskell. Best wishes, Wolfgang

Hans van Thiel wrote:

...

Maybe there are also patient people in the outside world so that we can still expose Haskell to the outside world while not trying to attract quick-and-dirty hackers. ;-) But who are those people? And what harm can they possibly do, assuming

On Tue, 2007-12-11 at 16:56 +0100, Wolfgang Jeltsch wrote: they fit the derogatory description?

I fear those people can do vast amounts of damage. :( When inept programming yields the wrong result, it is clear (even to the inept) that the program is bad. When the result is correct but there are egregious time or space leaks, it is "clear" to everyone but the Haskell guru that it "must" be the programming language that is deficient, and will be duly flamed far and wide. This perception will be impossible to reverse when it gains traction (and nothing ever goes away on the Internet). Seeming "deus ex machina" code changes (perhaps helpfully offered on haskell-cafe) to minimize or correct the undesirable runtime behavior appear even to many Haskellites to be black magic, accompanied by the runes of profile dumps (like knowing what generation 0 and generation 1 garbage collection is).

...

Haskell is not a quick-and-dirty language but quite the opposite. Haskell’s unique selling propositions are features like type classes, higher order functions and lazy evaluation which make life easier in the long term. The downside of these features is that they might make life harder in the short term. I don't know. In a sense Haskell is easier than, for example, C, because the concept of a function definition is more natural that that of assignments and loops. The idea that x = 5; x = x + 7 makes sense requires a complete new way of thinking. OK, once you've been doing it for a few years switching back to x = 5 + 7 is hard.

I would limit that to say that *denotational* semantic intuition is easy to wield in Haskell. Operational semantic intuition is Haskell is very non-obvious to the imperative (and many functional) programmers. Making matters worse, the first is an advantage well-hyped by functionistas, the second hurdle is rarely admitted to.

...

That said, I definitely think that we should make learning the language as easy as possible. But our ultimate goal should be to primarily show newcomers the Haskell way of problem solving, not how to emulate Python or Java programming in Haskell. Again, is there a danger of that happening?

Yes. Those absent the necessary humility to approach haskell-cafe with open mind and flame-retardant dialog will fall back on what they know: transliterated Java/Python with a morass of do blocks and IO monads, then (rightly) bash how "ugly" Haskell syntax is when used in this way. This type of programmer looking to use Haskell casually should sign a "benefit of the doubt" contract whereby they assume that any runtime suboptimalities derive from their own coding and not from Haskell's defects. This is the innate assumption of the curious, the self-motivated, the clever. This is not typically the starting assumption of the "I'm an expert at Joe-imperative language" hacker who took 10 years to perfect his Java skills and expects thereby to jump to at least year 5 of Haskell without effort. I do strongly believe in stimulating the curiosity of all comers, just not in giving the false impression that a quick read-through of a few tutorials will let you write lightning-fast code, or know when to abandon [Char] for something more clever, or where to insert those bangs and fold left instead of right, and how ad hoc and parametric polymorphism differ, and what Rank-n and existential means (and why you can just pickle any object in Python but need to know a half dozen abstract things including who Peano was to do the same in Haskell), and what the heck an infinite type is, and on and on. Haskell has definitely been teaching me some serious humility! Possibly it is best that those not ready for that lesson might better stick with Python.

It might help to point out that its easy to end up with memory/space leaks in Java/python/ruby/perl too. Also stack overflow is really easy. Also, you can get into really deep badness if you do anything interesting with concurrency because of the global interpreter lock etc. As far as pickling goes, HAppS-Data makes it trivial to pickle most anything into XML or name/value pairs so that is no longer a valid complaint. -Alex- Dan Weston wrote:

Hans van Thiel wrote:

...

...

Maybe there are also patient people in the outside world so that we can still expose Haskell to the outside world while not trying to attract quick-and-dirty hackers. ;-) But who are those people? And what harm can they possibly do, assuming

On Tue, 2007-12-11 at 16:56 +0100, Wolfgang Jeltsch wrote: they fit the derogatory description?

I fear those people can do vast amounts of damage. :(

When inept programming yields the wrong result, it is clear (even to the inept) that the program is bad.

When the result is correct but there are egregious time or space leaks, it is "clear" to everyone but the Haskell guru that it "must" be the programming language that is deficient, and will be duly flamed far and wide. This perception will be impossible to reverse when it gains traction (and nothing ever goes away on the Internet).

Seeming "deus ex machina" code changes (perhaps helpfully offered on haskell-cafe) to minimize or correct the undesirable runtime behavior appear even to many Haskellites to be black magic, accompanied by the runes of profile dumps (like knowing what generation 0 and generation 1 garbage collection is).

...

...

Haskell is not a quick-and-dirty language but quite the opposite. Haskell’s unique selling propositions are features like type classes, higher order functions and lazy evaluation which make life easier in the long term. The downside of these features is that they might make life harder in the short term. I don't know. In a sense Haskell is easier than, for example, C, because the concept of a function definition is more natural that that of assignments and loops. The idea that x = 5; x = x + 7 makes sense requires a complete new way of thinking. OK, once you've been doing it for a few years switching back to x = 5 + 7 is hard.

I would limit that to say that *denotational* semantic intuition is easy to wield in Haskell. Operational semantic intuition is Haskell is very non-obvious to the imperative (and many functional) programmers.

Making matters worse, the first is an advantage well-hyped by functionistas, the second hurdle is rarely admitted to.

...

...

That said, I definitely think that we should make learning the language as easy as possible. But our ultimate goal should be to primarily show newcomers the Haskell way of problem solving, not how to emulate Python or Java programming in Haskell. Again, is there a danger of that happening?

Yes. Those absent the necessary humility to approach haskell-cafe with open mind and flame-retardant dialog will fall back on what they know: transliterated Java/Python with a morass of do blocks and IO monads, then (rightly) bash how "ugly" Haskell syntax is when used in this way.

This type of programmer looking to use Haskell casually should sign a "benefit of the doubt" contract whereby they assume that any runtime suboptimalities derive from their own coding and not from Haskell's defects. This is the innate assumption of the curious, the self-motivated, the clever. This is not typically the starting assumption of the "I'm an expert at Joe-imperative language" hacker who took 10 years to perfect his Java skills and expects thereby to jump to at least year 5 of Haskell without effort.

I do strongly believe in stimulating the curiosity of all comers, just not in giving the false impression that a quick read-through of a few tutorials will let you write lightning-fast code, or know when to abandon [Char] for something more clever, or where to insert those bangs and fold left instead of right, and how ad hoc and parametric polymorphism differ, and what Rank-n and existential means (and why you can just pickle any object in Python but need to know a half dozen abstract things including who Peano was to do the same in Haskell), and what the heck an infinite type is, and on and on.

Haskell has definitely been teaching me some serious humility! Possibly it is best that those not ready for that lesson might better stick with Python.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Dec 10, 2007 7:09 PM, Wolfgang Jeltsch wrote:

...

there's the fear that laziness can impact performance,

Hmm, tell them that performance isn't all and that laziness helps you to write more modular programs.

Nah, in this case I've found it's better to realistically compare the performance of Haskell to Perl/Python, because it usually blows them out of the water, despite laziness :-) Luke

Maybe hardened Haskell programmers don't notice these things, but there's a wall that goes up when Haskell is presented to non-functional programmers. There are significant barriers for them to cross (some of them imaginary): there's the infamous type system, there's the mystique around monads, there's the fear that laziness can impact performance, the general fear that many ordinary programmers have about recursion, and so on. Giving people even the slightest reason to think that there's something weird about opening files or printing a result is just another brick in that wall, and it's probably the biggest brick of all.

this discussion could fall off the cliff at both ends. as far as i can tell, the problem is that with the haskell community so big, subcommunities only have different needs, different tools, different ways of thinking. and even if some of the subcommunities live and work at the cutting edge and expect everyone to follow, that won't necessarily happen anytime soon. one one side are the rocket engineers who feel genuinely displeased if people keep trying to sell horseless carriages as the best form of transport. and they are right, in a way: not only is this view rather limiting, but it keeps people form seeing not only that rockets exist, but that there are places where horseless carriages cannot take us, that we have actually been to the moon using rockets, a very long time ago, and that there are other places, and other technologies that might take us there. these people see "past" technology promoted everywhere at the expense of support for and interest in their own or similar advanced work. on the other side are the people who need to get from A to B, and are used to the tools of the horse&carriage industry. they feel genuinely unsure about those horseless carriage things, and they tend to lose it completely if all the manuals and sales brochures talk about different types of "automobiles", with not a word being said about horses and carriages. that talk about rocket engines goes right over their head, but that doesn't worry them as they don't expect to have to get to the moon anytime soon. of course, there is that question of satellites, which turn out to be awfully useful even if you don't otherwise want to leave the earth, and which are a real pain to put in place with carriages, horseless or otherwise. claus

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 mailto:dpiponi@gmail.com> 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 mailto:dave@zednenem.com> <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

On Tue, 11 Dec 2007, ChrisK wrote:

I look at it this way: Every person who adds Haskell, however shallowly, to their repertoire acts as an example that may spur others to learn Haskell, perhaps deeply. And that is a win not because of language chauvinism, but because of concept chauvinism. I hope that a future "Next Big Popular Language" has most of the concepts that make Haskell interesting.

I'm sure this will happen, I even suspect, this already happened, but a language can become popular only if enough legacy of several languages and the problematic parts of Haskell 98 are included. :-)

This is at odds with the notion, popular on this list and other haskell forums, that pure functional programming is the future.

Perhaps a nit-pick, but I don't think we're talking about *pure* functional programming. I think we're talking about a mixture of functional and imperative programming in a functional language. Haskell offers a cleaner separation between the two than, say, Scheme or ML. The idea of pure functional programming (no explicit IO) for getting real things done is much more of a lunatic fringe vision, and I'm not sure there are many of us left pursuing that vision. - Conal On Dec 11, 2007 9:34 AM, Tim Newsham wrote:

...

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

I haven't been following this thread closely, but would it be rude to suggest purely

...

functional languages and who are willing to learn new concepts if it enables them to program in that style.

This is at odds with the notion, popular on this list and other haskell forums, that pure functional programming is the future.

Why is it that every time the topic of teaching basic concepts in an easier way comes up there are always two or three replies that say "should we bother? lets filter out the idiots?" These are pointless and counterproductive. Whether or not you like the idea of lesser entities sullying your private, pure, functional programming language, there are going to be a lot more people learning this language, and there will be people trying to make it easier for them to learn it.

...

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. [...] 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.

Many of the best resources for learning Haskell are still academic papers published by language researchers. We've still got a long long way to go... Sure there's no shortcut to learning difficult concepts, but right now its more of a nature hike than a freeway...

...

Mike

Tim Newsham http://www.thenewsh.com/~newsham/ http://www.thenewsh.com/%7Enewsham/ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

And more power to those who are pursuing the vision! But in the mean time I need to read and write files, start up external programs, call Excel through FFI, etc, etc. And there's no clever API for that yet, only IO. And I'd rather do IO in Haskell than in C++. I share the vision, though. I'm just not pursuing it at the moment. -- Lennart On Dec 11, 2007 6:02 PM, Conal Elliott wrote:

...

This is at odds with the notion, popular on this list and other haskell forums, that pure functional programming is the future.

Perhaps a nit-pick, but I don't think we're talking about *pure* functional programming. I think we're talking about a mixture of functional and imperative programming in a functional language. Haskell offers a cleaner separation between the two than, say, Scheme or ML. The idea of pure functional programming (no explicit IO) for getting real things done is much more of a lunatic fringe vision, and I'm not sure there are many of us left pursuing that vision.

- Conal

On Dec 11, 2007 9:34 AM, Tim Newsham wrote:

...

...

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

I haven't been following this thread closely, but would it be rude to suggest purely

...

functional languages and who are willing to learn new concepts if it enables them to program in that style.

This is at odds with the notion, popular on this list and other haskell forums, that pure functional programming is the future.

Why is it that every time the topic of teaching basic concepts in an easier way comes up there are always two or three replies that say "should we bother? lets filter out the idiots?" These are pointless and counterproductive. Whether or not you like the idea of lesser entities sullying your private, pure, functional programming language, there are going to be a lot more people learning this language, and there will be people trying to make it easier for them to learn it.

...

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. [...] 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.

Many of the best resources for learning Haskell are still academic papers published by language researchers. We've still got a long long way to go... Sure there's no shortcut to learning difficult concepts, but right now its more of a nature hike than a freeway...

...

Mike

Tim Newsham http://www.thenewsh.com/~newsham/ http://www.thenewsh.com/%7Enewsham/ _______________________________________________ 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

Conal, It's true that you can avoid using IO (except for a wrapper) for certain kinds of programs. For instance, if all you want is a String->String function, or some GUI program (you forgot to mention fudgets, which was the first wrapper of this kind) then you can ignore IO and just use a nice wrapper. But if someone asks me how to traverse a directory tree, invoking the 'file' program for each ',o' file and then renaming it if it's a text file, then what should I answer? "Sorry, you can't do that in Haskell." or "You need to use the IO monad."? I prefer the latter answer, and I think people who learn Haskell need to learn something about how you do some of the things that are easy in other languages. It's also important to teach people to stay away from IO whenever possible, but it's simply not always possible. -- Lennart On Dec 9, 2007 5:31 PM, Conal Elliott wrote:

...

IO is important because you can't write any real program without using it.

Ouch! I get awfully discouraged when I read statements like this one. The more people who believe it, the more true it becomes. If you want to do functional programming, instead of imperative programming in a functional language, you can. For instance, write real, interactive programs in FRP, phooey, or TV. And if you do, you'll get semantic simplicity, powerful & simpler reasoning, safety and composability.

- Conal

On Dec 8, 2007 1:26 AM, Lennart Augustsson wrote:

...

I agree with Dan here.

IO is important because you can't write any real program without using it. So why not teach enough of it to get people off the ground straight away?

People who hang around long enough to do some more Haskell programming will run into the other monads sooner or later. But IO is an unavoidable step to writing Haskell programs.

On Dec 4, 2007 5:11 AM, Dan Piponi < dpiponi@gmail.com> wrote:

...

On Dec 3, 2007 6:36 PM, Ben Franksen < ben.franksen@online.de> wrote:

...

then the special features of IO will remain associated with monads in general, leading to a whole jumble of completely wrong ideas about them.

As I only learnt about monads a couple of years ago, the process is still fresh in my mind. I wasted quite a bit of time labouring under the impression that monads were primarily about sequencing. But that wasn't because I incorrectly generalised from IO. It was because countless people out there explicitly said they were about sequencing. I suspect that if courses started with the List monad there'd be countless blogs telling people that monads are a way to eliminate loops from your code like the way list comprehensions are used in Python.

...

This is yet another problem with IO as the standard example for monads: its effect base is huge and poorly structured.

You don't teach *all* of IO to students in one go!

...

This again makes it difficult to see exactly which intuitions about IO can be generalized to arbitrary monads and which not.

That's true of any monad. IO is unique. [] is unique. Cont is unique. All of them can lead you down the garden path. You need to see multiple monads, and it helps if you can sneak an example under a student's nose so they can already reason about monads before they even know what a monad is.

...

What is pointless about failure and how to handle it?

It's pointless when you're still trying to make your first tweaks to "Hello, World!" work. -- Dan _______________________________________________ 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

I doubt all imperative programming will be banished from Haskell anytime soon. I really, really wish we had all the nice abstractions in place already, but we just don't. You can't write any program in Haskell without using IO, because the type of main involves IO. And currently I believe that almost any real program will have to involve IO. (BTW, the only H98 IO avoiding wrapper, interact, was included in Haskell because I insisted on it.) It's just from my experience. No matter how pure your program is, here and there it will be interacting with the rest of the world. -- Lennart On Dec 9, 2007 10:16 PM, Conal Elliott wrote:

Thanks. If I'm tracking, your real point is that imperative programming in Haskell is still useful enough to keep around. I agree.

I'm still puzzled. Did you understand something I said, or maybe someone else said, as suggesting that imperative programming be removed from Haskell any time soon?

...

It's also important to teach people to stay away from IO whenever possible, but it's simply not always possible.

How can we possibly teach them to stay away from IO where possible if we're also telling them that they can't write *any* real program without using IO?

Cheers, - Conal

On Dec 9, 2007 12:02 PM, Lennart Augustsson wrote:

...

Conal,

It's true that you can avoid using IO (except for a wrapper) for certain kinds of programs. For instance, if all you want is a String->String function, or some GUI program (you forgot to mention fudgets, which was the first wrapper of this kind) then you can ignore IO and just use a nice wrapper.

But if someone asks me how to traverse a directory tree, invoking the 'file' program for each ',o' file and then renaming it if it's a text file, then what should I answer? "Sorry, you can't do that in Haskell." or "You need to use the IO monad."? I prefer the latter answer, and I think people who learn Haskell need to learn something about how you do some of the things that are easy in other languages.

It's also important to teach people to stay away from IO whenever possible, but it's simply not always possible.

-- Lennart

On Dec 9, 2007 5:31 PM, Conal Elliott wrote:

...

...

IO is important because you can't write any real program without using it.

Ouch! I get awfully discouraged when I read statements like this one. The more people who believe it, the more true it becomes. If you want to do functional programming, instead of imperative programming in a functional language, you can. For instance, write real, interactive programs in FRP, phooey, or TV. And if you do, you'll get semantic simplicity, powerful & simpler reasoning, safety and composability.

- Conal

On Dec 8, 2007 1:26 AM, Lennart Augustsson wrote:

...

I agree with Dan here.

IO is important because you can't write any real program without using it. So why not teach enough of it to get people off the ground straight away?

People who hang around long enough to do some more Haskell programming will run into the other monads sooner or later. But IO is an unavoidable step to writing Haskell programs.

On Dec 4, 2007 5:11 AM, Dan Piponi < dpiponi@gmail.com> wrote:

...

On Dec 3, 2007 6:36 PM, Ben Franksen < ben.franksen@online.de> wrote:

...

then the special features of IO will remain associated with monads in general, leading to a whole jumble of completely wrong ideas about them.

As I only learnt about monads a couple of years ago, the process is still fresh in my mind. I wasted quite a bit of time labouring under the impression that monads were primarily about sequencing. But that wasn't because I incorrectly generalised from IO. It was because countless people out there explicitly said they were about sequencing. I suspect that if courses started with the List monad there'd be countless blogs telling people that monads are a way to eliminate loops from your code like the way list comprehensions are used in Python.

...

This is yet another problem with IO as the standard example for monads: its effect base is huge and poorly structured.

You don't teach *all* of IO to students in one go!

...

This again makes it difficult to see exactly which intuitions about IO can be generalized to arbitrary monads and which not.

That's true of any monad. IO is unique. [] is unique. Cont is unique. All of them can lead you down the garden path. You need to see multiple monads, and it helps if you can sneak an example under a student's nose so they can already reason about monads before they even know what a monad is.

...

What is pointless about failure and how to handle it?

It's pointless when you're still trying to make your first tweaks to "Hello, World!" work. -- Dan _______________________________________________ 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

Ben Franksen wrote:

I don't buy this. As has been noted by others before, IO is a very special case, in that it can't be defined in Haskell itself, and there is no evaluation function runIO :: IO a -> a.

This is a straw man. Most monads will not have such a function: There is no function (State s a) -> a. There is no function (r -> a) -> a. There is no function (Random a) -> a. [assuming some random monad, often discussed] There is no function (Supply s a) -> a. [Another useful monad although not one of the standard ones] There are no (total) functions Maybe a -> a, [a] -> a, Either e a -> a. As to the topic of the thread: I agree IO is an unusual monad. I'm not sure if I agree that it shouldn't be used as a teaching basis. I think there are all kinds of ways to teach haskell; I'd be inclined to want to start with some IO, without explaining the plumbing in detail, and then come back to it later with better perspective when discussing general monads. Jules