Re: [Haskell-cafe] IO is a bad example for Monads
On Wed, 2007-12-12 at 16:27 +0100, Hans van Thiel wrote: [snip] 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). I see your point, but maybe there should be better analyzing tools then, as well as tutorials which explain that problem. 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. I admit I don't understand this. 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. But that person will be used to all the help he's gotten from the Java and/or Eclipse, with tutorials and reference implementations. Now he has to depend on dissertations and JFP articles for anything that's less than 10 years old, and a few helpful experts (much appreciated, I want to add) who are willing to spend the time to answer questions. 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. It's possible, IMO, that Haskell requires a higher skill level in information science that the imperative languages. Many working programmers come from different backgrounds and are not experts in computer science. But, like a skyscraper is not built just by the architects, maybe those 'lower' skills have their place too. Maybe not, or not in Haskell. Could be, though I don't think so, myself. 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. If they read this, I'm sure they will. Best Regards, Hans van Thiel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org
Re: [Haskell-cafe] IO is a bad example for Monads
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 quickdirty 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
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 quickdirty 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
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. 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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
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 [EMAIL PROTECTED] wrote: 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. 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
Re: [Haskell-cafe] IO is a bad example for Monads
I'm not sure there are many of us left pursuing that vision. P.S. I'd love to learn otherwise. On Dec 11, 2007 10:02 AM, Conal Elliott [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: 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. 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
Re: [Haskell-cafe] IO is a bad example for Monads
On Tue, 2007-12-11 at 16:56 +0100, Wolfgang Jeltsch wrote: 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 quickdirty 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. ;-) But who are those people? And what harm can they possibly do, assuming they fit the derogatory description? 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 guess I do agree with you on lazy evaluation.. 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? Regards, Hans Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: 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. 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
Hans van Thiel wrote: On Tue, 2007-12-11 at 16:56 +0100, Wolfgang Jeltsch 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 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
Re: [Haskell-cafe] IO is a bad example for Monads
It may be helpful to distinguish teaching/preaching (a) programming in Haskell from (b) *functional* programming (in Haskell or otherwise). Each focus is present in the conversation. Perhaps IO helps the former and hinders the latter.- Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
Am Dienstag, 11. Dezember 2007 18:34 schrieb Tim Newsham: […] 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? I think that two different things are mixed in this thread: (1) teaching monadic I/O in a newbie-friendly way (2) stressing monadic I/O in teaching and shying away from teaching purely functional solutions While I support (1), I don’t support (2). […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
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: On Tue, 2007-12-11 at 16:56 +0100, Wolfgang Jeltsch 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 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
Am Montag, 10. Dezember 2007 10:36 schrieb Ketil Malde: Daniel Fischer [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
On Dec 10, 2007 4:51 AM, Daniel Fischer [EMAIL PROTECTED] wrote: Am Montag, 10. Dezember 2007 10:36 schrieb Ketil Malde: Daniel Fischer [EMAIL PROTECTED] writes: Various other people write: ... lots of talk about monads and IO ... 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. 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. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
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 quickdirty hackers? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
Am Montag, 10. Dezember 2007 19:44 schrieb Dan Piponi: […] 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): That’s inavoidable if they want to learn a language which will finally be advantageous for them. If they just want another Perl or Python then there is no point in presenting Haskell to them. there's the infamous type system, You need them to get to recognize that a powerful static type system is a very good thing (which helps solving practical problems). there's the mystique around monads, We should just say: “warm fuzzy thing”. ;-) 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. the general fear that many ordinary programmers have about recursion, Then they might not be good programmers. and so on. etc. 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. You’re right, of course. However, finally they should arrive at the point where they see that sometimes there are better tools than the IO type. Dan Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
Am Montag, 10. Dezember 2007 20:00 schrieb Henning Thielemann: […] I raise my question once again: Must Haskell's tutorials be tailored to impatient programmers? Does Haskell need quickdirty hackers? Who want Haskell to be plastered with syntactic sugar? ;-) ;-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
On Dec 10, 2007 7:09 PM, Wolfgang Jeltsch [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
On Dec 10, 2007 11:00 AM, Henning Thielemann [EMAIL PROTECTED] wrote: Does Haskell need quickdirty hackers? The question isn't Does Haskell need quickdirty 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] IO is a bad example for Monads
Hello Dan, Monday, December 10, 2007, 9:44:06 PM, you wrote: When someone comes to me and says I have this Python script that just my cent or two for this discussion: sometime ago I've started an introduction to IO tutorial. it's both not in English and not finished so i'll just explain its idea: Haskell has strict distinction between procedures that may perform side-effects and pure functions; functions can't call procedures. there is special notion for procedures, with do/return/... and further explanation shows various details of building procedures. i think that such description closely mirrors thinking of imperative-language programmers and allows to overcome monad barrier in teaching real-world haskell of course, this meant only as introductory course and at some moment haskeller should read all about monads and io inside, but i consider this as intermediate-level or even advanced material btw, explanation in terms of functions vs procedures isn't my own, unfortunately i don't remember its origins, but i find it very helpful and understandable for average imperative programmers -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
Dan Piponi [EMAIL PROTECTED] writes: The question isn't Does Haskell need quickdirty 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. This is an interesting trade-off: if we suppose that the most enterprising and creative (i.e. talented) [language] hackers are most susceptible to be lured over to Haskell, this strategy will increase the average quality of software overall, while simultaneously decreasing the average quality of code in both languages! Note also that there are many classes of people who fit the quick and dirty category. Encourage them to learn Haskell and only be quick. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
If Haskell wants yo significantly widen it's audience then the tutorials have to cater for the impatient. Perhaps it's better to remain a fringe language. I truly don't know. -- Lennart On Dec 10, 2007 7:00 PM, Henning Thielemann [EMAIL PROTECTED] 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 quickdirty hackers? ___ 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
Re: [Haskell-cafe] IO is a bad example for Monads
On 10/12/2007, Henning Thielemann [EMAIL PROTECTED] 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 quickdirty 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
Paul Moore after Henning Thielemann after Dan Piponi: 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 quickdirty 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 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 think that 1. Nobody ignores that. 2. Nobody really tries to insult people who want to find fast, elegant and efficient solutions to their problems. 3. People often *are* impatient, and this is not an insult. 4. Some comments from the other side, addressed to Haskellers can sometimes also be qualified as almost insulting (if somebody wishes to adopt such personal attitude). Paul Moore has seen this type of comment many times. I have seen his reaction, and the whole of this discussion at least as many times. Will it help us, all of us?... Look, all of you. There was time, where the theory of Einstein was considered as something so high-brow, that a few guys in this world would understand it. Now it is a standard undergraduate topic. Some *formal* elements of the Special Relativity may be taught in High School. Some *qualitative* elements of the General Relativity, as well. Do you imagine the concrete application - for the impatient - of the differential calculus, at the time of Newton and Leibniz? And now? EVERYTHING here is a problem of education. It is different now than 300 years ago, and even than 60 years ago. Everything is much faster. But our physiology, the speed of assimilation did not progress much. We REALLY need time to assimilate new things. So, they should start earlier. The basic recursion schemata should be taught to 13-15 years old people. The teaching of algebra may, and often is much more abstract than 30 years ago, but still there is a reluctance of teachers to illustrate math through programming, at a sufficiently abstract level. I really think that such languages as Haskell are investing for the future. My main grief is completely different from these expressed by people who want to sell Haskell for the Humanity rrright now. I think seriously that one of the weakest points of Haskell is that it is *alone*. That there is no competition. Clean stagnates a bit, the Clean mailing list is at least 40 times less popular than this one. Pity, it is, or could be a worthy opponent, concerning IO, the relation between types and strictness, etc. Some work on functional approach to scientific programming goes along the lines far, far from Haskell, inspired rather by SISAL, etc. (for example the SAC system). So my sincere recommendation for people unhappy with the monadic IO is: propose something alternative, and implement it. If you are unhappy with the language, tell us what you concretely want, but don't try to say that you don't like our submarine, because you want to ride on it to the top of Mount Everest. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
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 horsecarriage 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
On Dec 10, 2007 1:44 PM, Dan Piponi [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] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
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
Re: [Haskell-cafe] IO is a bad example for Monads
On Dec 10, 2007, at 12:40 PM, Dan Piponi wrote: On Dec 10, 2007 11:00 AM, Henning Thielemann [EMAIL PROTECTED] wrote: Does Haskell need quickdirty hackers? The question isn't Does Haskell need quickdirty 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
On Mon, 10 Dec 2007, Paul Moore wrote: On 10/12/2007, Henning Thielemann [EMAIL PROTECTED] wrote: I raise my question once again: Must Haskell's tutorials be tailored to impatient programmers? Does Haskell need quickdirty 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads [was: do]
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Dec 3, 2007 6:36 PM, Ben Franksen [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads [was: do]
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads [was: do]
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Dec 3, 2007 6:36 PM, Ben Franksen [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads [was: do]
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Dec 3, 2007 6:36 PM, Ben Franksen [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
Daniel Fischer [EMAIL PROTECTED] 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. 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 -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
Am Sonntag, 9. Dezember 2007 23:35 schrieb Ketil Malde: Daniel Fischer [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads [was: do]
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Dec 3, 2007 6:36 PM, Ben Franksen [EMAIL PROTECTED] 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?
Re: [Haskell-cafe] IO is a bad example for Monads [was: do]
It so happens that Haskell currently insists on main :: IO (). That's simple to fix, however, and with great pay-off. Suppose instead main :: TV a (where I'm omitting the other TV type args for simplicity.) Then a program could not only be run, but also composed with other programs. They could even be composed by the end-user *while running*, as in Eros. Similarly, ghci implicitly inserts print when given a non-IO type. We could make that mechanism a little more general, and allow implicit insertions of other kinds of renderers, for purely functional images, music, 2D 3D geometry animation, interactive GUIs, etc. - Conal On Dec 9, 2007 4:38 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Dec 3, 2007 6:36 PM, Ben Franksen [EMAIL PROTECTED] 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
Re: [Haskell-cafe] IO is a bad example for Monads [was: do]
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 [EMAIL PROTECTED] wrote: On Dec 3, 2007 6:36 PM, Ben Franksen [EMAIL PROTECTED] 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
[Haskell-cafe] IO is a bad example for Monads [was: do]
Dan Piponi wrote:
On Dec 3, 2007 3:54 PM, Ben Franksen [EMAIL PROTECTED] 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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads [was: do]
On Dec 3, 2007 6:36 PM, Ben Franksen [EMAIL PROTECTED] 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
