Re: Re: Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Please note that it may be hard to make a print out of a wikibook. You might want to use Docbook/XML or Latex in a darcs repo- sitory instead. On Mon, Dec 11, 2006 at 03:23:13PM -0500, Matt Revelle wrote: Sorry, wasn't sure I had clearly expressed that it's possible to have an open book end up as a dead-tree book. Either way, I'm interested in helping. On 12/11/06, Kirsten Chevalier [EMAIL PROTECTED] wrote: It matters to me; if I'm going to put work into this, then that's what I want the result to be. I'm happy, of course, for projects that I am not involved in to use whatever publishing mechanisms that the people involved in those projects prefer. ___ 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] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Paul Hudak wrote: Maybe some of you can do better, but it's really tough to show someone how an /advanced/ Haskell programmer would solve /advanced /problems that arise in the real world. As a simple example, I love this recent quote by Garrett Morris: I'm personally fond of framing most non-trivial Haskell problems as defining domain specific languages; as a result, everything over about 200 lines that I've written in the past 3 years has used the mtl [Monad Transformer Library] in some form or fashion. It's great. So how do we teach Garrett's way of programming (which I like very much) to the masses? I don't know either, but I would really like to have that book. I started out with Haskell using resources like SOE, Thomson's Craft of, and the Gentle Introduction. Apart from reading the Structure and Interpretation of Computer Programs, this was my first exposure to functional programming. Some things took a bit of effort to wrap my head around, but it generally wasn't too hard to get to a level where I could write useful programs. Now there is a plethora of introductions, tutorials and guides, and I wonder if we really need yet another 'for dummies' resource? The challenge for me is to learn more advanced practices. This is much harder to do - at least for me - for several reasons: * there is less material describing the advanced stuff * a lot of the existing material is in the form of research papers or similar communications between the cognoscenti. This (often) implies - it is hard to understand for us laymen - it isn't tied to practical problems * I'm already productive with what I know, so I don't have the direct motivation I generally manage to absorb just enough to get by, but I think there is a niche for a book (coupled to practical problems and complete with excercises etc) that is waiting to be filled. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Paul Hudak wrote: Hi Sebastian. As a writer of one of those academic Haskell textbooks, I've been following this thread with some interest. BTW, I found your textbook very helpful. The first time I tried to learn Haskell, I got the Bird and Wadler textbook, and got bogged down about halfway through. It just wasn't the sort of approach that was good for someone in my position, i.e., trying to pick up the language in my spare time without the structure of a college class to check my work and give me the occasional kick in the rear. But with SOE--ooh! pretty pictures! (The only problem was figuring out the magic incantation to make Hugs on my system talk to the SOEGraphics library.) Maybe some of you can do better, but it's really tough to show someone how an /advanced/ Haskell programmer would solve /advanced /problems that arise in the real world. As a simple example, I love this recent quote by Garrett Morris: I'm personally fond of framing most non-trivial Haskell problems as defining domain specific languages; as a result, everything over about 200 lines that I've written in the past 3 years has used the mtl [Monad Transformer Library] in some form or fashion. It's great. So how do we teach Garrett's way of programming (which I like very much) to the masses? One would guess that we'd need to explain not only monads, but also monad transformers, first. My first thought would be to develop some kind of cheap-ass NLP system, starting with simple VERB NOUN constructions or some kind of text filter, and building up to the kind of parser that the Infocom Z-machine uses. (N.B.: applications that are too reminiscent of math class, like arithmetic-expression evaluators or symbolic differentiators, are turn-offs. If the rest of us were that thoroughly comfortable with math, we'd be expert Haskell programmers already. :-) Sebastian Sylvan wrote: There must be some way of teaching Haskell breadth first, so to speak. In the ed biz they call this a spiral curriculum. As applied to a Haskell textbook, what I would suggest is something like this: In chapter 1, introduce the IO monad, and point out a few key features (e.g., explain why a function with type IO a - a would be unsafe). In chapter 2, introduce the Maybe monad, and point out that constructions like (Just 5) = putStrLn won't compile. In the next few chapters, introduce other common and useful monads, so the student has some hope of getting an intuitive sense of what's going on with them; at the same time, dribble in a few useful facts about monads or useful operators for manipulating them. *Then*, no earlier than chapter 5, provide the formal definition of a monad and explain how you can roll your own. (I'm not sure whether it would be helpful to give some examples of monad transformers before the formal definition of a monad, or whether those should come afterward.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Hello everyone, On 12/12/06, Ketil Malde [EMAIL PROTECTED] wrote: snip Some things took a bit of effort to wrap my head around, but it generally wasn't too hard to get to a level where I could write useful programs. snip * I'm already productive with what I know, so I don't have the direct motivation I think this is the major obstacle. I've had similar experiences with programmers of all skill levels. For one example, when I was TA'ing an introduction to FP course in college, we regularly had students who, once they had learned primitive recursion, would write every assignment (that didn't specifically exclude primitive recursion) recursively for the remainder of the quarter, no matter how much easier it would have been in terms of (for example) map and filter. For another examples, I've spent more time than I want to admit reinventing (or failing to reinvent) various wheels in Haskell (including arrows and COM's IUnknown) because I was fairly convinced that I knew everything I needed to solve whatever problem I was working on. From my experience, I'd suggest a couple of things: first, I think starting from simple ideas -- like primitive recursion -- is deadly. Instead, I'd rather earlier sections focused on less complex applications of rich ideas. For example, in a discussion of rewriting the aforementioned FP class, I rewrote the first project of the quarter from relying on primitive recursion over the integers to using function and Kleisli composition. I'm not necessarily suggesting that freshmen will understand Kleisli composition, but in this case the development of the composition operator was fairly natural for the problem, and when they came back to Kleisli composition later, they would have already seen it (as opposed to having seen a less useful variation). Second, I think that introducing at least monadic programming as early as possible is a good idea. My experience with people who've learned Haskell for jobs or courses (as opposed to for love of the game, so to speak) is that monadic programming frequently ends up regarded as a separate set of mysteries that's perhaps convenient for wizards but not necessary for normal programmers. This leads to another boundary when people who have learned a certain amount of Haskell and even written large amounts of Haskell look at code from more monad-happy projects and find it written in what looks like a foreign tongue. Finally, count me among those who would be happy to contribute as soon as there's a wiki or similar available! /g -- It is myself I have never met, whose face is pasted on the underside of my mind. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On 12/11/06, Andrew Wagner [EMAIL PROTECTED] wrote:
I think there are some great ideas here, and it would be a fantastic
project to do as a community, via a wikibook.
..
On 12/11/06, Kirsten Chevalier [EMAIL PROTECTED] wrote:
there's not really a way to get a publisher to publish something that's
already released under a free documentation license --
but correct me if I'm wrong.)
I have on my shelf, copies of SICP, Thinking Forth, The Icon
Programming Language, and Programming with Unicon, just to name the
ones that I can think of and all of them are available on line. I
like someone at the beginning of the thread, said I just like the
feel of paper...no ink. I read what I have to in online docs, but I
do like to have to sit back with a book. There is, I believe a book
publishing entity on the net that will publish, on demand, so to
speak, any book submitted to them. I can't for the life of me
remember the name of that resource, but it makes the idea of turning a
wikibook into a hard copy feasible... no matter what the topic. I
would surmise that due to the somewhat limited audience of even the
already TOP Haskell books, such as Craft and Hudak's book {title
has slipped my mind}, that most high volume publishers would have
never picked even those up. Getting rich by publishing any book on
Haskell is probably not a good motivation for writing it. But I do
believe that people like myself are out there, and ready to buy a good
book, especially about an at time dense subject, in hard copy. I for
one just like to get away from the whine of the box fan, that is the
cooling device right now on my computing machine, sitting 22 from my
ear canal, and read a good book that is potentially this useful.
happy computing,
gene
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
It's not as if this is the first time that this has been suggested, but some people have suggested that a practical book about Haskell would be a good idea. I agree. Some people have also suggested that the right moment for this hasn't arrived yet, and I see that as a challenge. I'm willing to take the lead in at least thinking about what such a book might look like. I'm potentially about to have some free time for such things, and am still young and foolish enough to think that writing a book would be a good idea. Of course, there are many good Haskell books out there already, but many of them are intended as class textbooks or are aimed at more theoretical-minded people. There's nothing wrong with that, but I think that it would be nice if a friendly, conversational, informal book about Haskell existed, since after all this is such a friendly and informal community. (If there already is a book like this, point it out, but I get the impression there's not.) There's also excellent Haskell documentation available on the web already, but people like to buy books and they like to have an artifact that they can hold in their hands without getting laser printer toner all over themselves. But if I were going to do this, I'd need all the help I could get, so if you're interested in working with me on this, email me off-list and we'll talk. Don't feel like you need to be named Simon for this; I don't think you need to be a Haskell guru to contribute to a book like this (I know I'm not one), though it wouldn't hurt. Being interested in good writing and explaining things to a wider audience is more important. And, the more people who are interested in working on this, the more we can all pool our various talents to create something awesome. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Everyone's too stupid. -- _Ghost World_ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
In my opinion it would be important to increase the understanding about semantics and processes. And it would be good to introduce the concepts in a similar way as Profokiev introduces the sound of classical music in Peter and the Wolf. If my suspicion is correct, functional programming would be very close to composing classical music (or concurrent algorithms and processes). Has anyone of you similar thoughts on music and programming ? What are the basic ingredients for making abstractions (like in music rythm, keys, tempo, ...) ? It would be useful to express different ways of expression by explaining first semantics of processes and abstractions. --- Kirsten Chevalier [EMAIL PROTECTED] schrieb: It's not as if this is the first time that this has been suggested, but some people have suggested that a practical book about Haskell would be a good idea. I agree. Some people have also suggested that the right moment for this hasn't arrived yet, and I see that as a challenge. I'm willing to take the lead in at least thinking about what such a book might look like. I'm potentially about to have some free time for such things, and am still young and foolish enough to think that writing a book would be a good idea. Of course, there are many good Haskell books out there already, but many of them are intended as class textbooks or are aimed at more theoretical-minded people. There's nothing wrong with that, but I think that it would be nice if a friendly, conversational, informal book about Haskell existed, since after all this is such a friendly and informal community. (If there already is a book like this, point it out, but I get the impression there's not.) There's also excellent Haskell documentation available on the web already, but people like to buy books and they like to have an artifact that they can hold in their hands without getting laser printer toner all over themselves. But if I were going to do this, I'd need all the help I could get, so if you're interested in working with me on this, email me off-list and we'll talk. Don't feel like you need to be named Simon for this; I don't think you need to be a Haskell guru to contribute to a book like this (I know I'm not one), though it wouldn't hurt. Being interested in good writing and explaining things to a wider audience is more important. And, the more people who are interested in working on this, the more we can all pool our various talents to create something awesome. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Everyone's too stupid. -- _Ghost World_ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On 12/11/06, Patrick Mulder [EMAIL PROTECTED] wrote: In my opinion it would be important to increase the understanding about semantics and processes. And it would be good to introduce the concepts in a similar way as Profokiev introduces the sound of classical music in Peter and the Wolf. If my suspicion is correct, functional programming would be very close to composing classical music (or concurrent algorithms and processes). Has anyone of you similar thoughts on music and programming ? What are the basic ingredients for making abstractions (like in music rythm, keys, tempo, ...) ? It would be useful to express different ways of expression by explaining first semantics of processes and abstractions. I love the analogy, though it's been at least eleven years since I tried to compose any music. (Coincidentally, eleven years ago was when I learned to program...) I've often thought that reading code (if it's well-written code) is a little like reading a poem, which of course is also a little like listening to classical music. There's certainly a sense of rhythm involved in how you choose variable names: that's why nobody likes variable names like theHashTableThatStoresMappingsBetweenNamesAndEmails. I'm not sure what the analogy with keys would be. Maybe writing in a point-free versus a pointed style is sort of like transposing a melody into another key. For the potential book, I definitely think a Peter-and-the-Wolf-like idea is good. (The wolf would be unsafePerformIO, obviously.) Probably any metaphors that assume any knowledge of music should be left for a different piece of writing that assumes a different audience, but pursuing it would be fun. I've been thinking a lot lately about how to present computer science (and programming languages) to a popular audience, too. I don't remember who originally posed the question of who's going to be the Carl Sagan of computer science?, but it's a question somebody should try to answer. (The answer isn't Douglas Hofstadter, because obviously somebody needs to be out there explaining why languages with static type systems are cool, too.) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Are you aware that rushing toward a goal is a sublimated death wish? It's no coincidence we call them 'deadlines'. -- Tom Robbins ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
The way to write the book, I think, would be to take something referred to as real world problems - problems a large proportion of programmers deals with and gets paid for, and then show how to solve these problems in Haskell (preferrably quicker and easier than with conventional solutions). I would divide the book into two parts. The first part would introduce Haskell via traditional small examples. Quick sort, towers of Hanoi, etc. The second part would have two or three large examples - something that people would relate to. I'd take a web application, tetris, and perhaps a chat server. Thanks, - Slava. On 12/11/06, Kirsten Chevalier [EMAIL PROTECTED] wrote: On 12/11/06, Patrick Mulder [EMAIL PROTECTED] wrote: In my opinion it would be important to increase the understanding about semantics and processes. And it would be good to introduce the concepts in a similar way as Profokiev introduces the sound of classical music in Peter and the Wolf. If my suspicion is correct, functional programming would be very close to composing classical music (or concurrent algorithms and processes). Has anyone of you similar thoughts on music and programming ? What are the basic ingredients for making abstractions (like in music rythm, keys, tempo, ...) ? It would be useful to express different ways of expression by explaining first semantics of processes and abstractions. I love the analogy, though it's been at least eleven years since I tried to compose any music. (Coincidentally, eleven years ago was when I learned to program...) I've often thought that reading code (if it's well-written code) is a little like reading a poem, which of course is also a little like listening to classical music. There's certainly a sense of rhythm involved in how you choose variable names: that's why nobody likes variable names like theHashTableThatStoresMappingsBetweenNamesAndEmails. I'm not sure what the analogy with keys would be. Maybe writing in a point-free versus a pointed style is sort of like transposing a melody into another key. For the potential book, I definitely think a Peter-and-the-Wolf-like idea is good. (The wolf would be unsafePerformIO, obviously.) Probably any metaphors that assume any knowledge of music should be left for a different piece of writing that assumes a different audience, but pursuing it would be fun. I've been thinking a lot lately about how to present computer science (and programming languages) to a popular audience, too. I don't remember who originally posed the question of who's going to be the Carl Sagan of computer science?, but it's a question somebody should try to answer. (The answer isn't Douglas Hofstadter, because obviously somebody needs to be out there explaining why languages with static type systems are cool, too.) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Are you aware that rushing toward a goal is a sublimated death wish? It's no coincidence we call them 'deadlines'. -- Tom Robbins ___ 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] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
(to Kirsten, Akhmechet, cc: Haskell-Cafe) I would divide the book into two parts. The first part would introduce Haskell via traditional small examples. Quick sort, towers of Hanoi, etc. The second part would have two or three large examples - something that people would relate to. I'd take a web application, tetris, and perhaps a chat server. Tetris could be fun, because it would allow to present your software/learning curve to people without technology background, and maybe they would look into programming then as well. Your setup also reminds me on the book by Peter Seibel on learning Lisp. He shows how to program a small database to organise your CD collection (by writing a sort of SQL replacement.) I've often thought that reading code (if it's well-written code) is a little like reading a poem, which of course is also a little like listening to classical music. Indeed, poems are another form of abstract expression, and certainly it would be interesting to think about similarities with programming. Poems can be interesting because of multiple associations in words, e.g. an obvious meaning and hidden meaning. And this involves some parallel processes. But to me, the idea of parallel processes is more clearly to see in music. Processes are rendered in the voices of instruments, and every voice transmits or contributes to a certain message. In a way, the voices of an orchestra can be seen to describe a process (experience) or function. Another idea that comes to my mind is attributing processes to protagonists in a drama. (Another quote how programming shares aspects of making music. From the preface of Structure and Interpretation of Computer Programs: A computer is like a violin. You can imagine a novice trying first a phonograph and then a violin. The latter, he says, sounds terrible. That is the argument we have heard from our humanists and most of our computer scientists. Computer programs are good, they say, for particular purposes, but they aren't flexible. Neither is a violin, or a typewriter, until you learn how to use it. Marvin Minsky, ``Why Programming Is a Good Medium for Expressing Poorly-Understood and Sloppily-Formulated Ideas'') I've been thinking a lot lately about how to present computer science (and programming languages) to a popular audience, too. Yes, this is an important topic. But there is also the common misunderstanding that computers = Von Neumann machines. I think the concept of computer is better to see as sort of telescope or translator. Computers allow to look at processes (and complexity) which would otherwise not conceivable to our limited minds. The idea of computers as telescopes is from Daniel Dennett though. I will think about these ideas, and let you know my progress. Patrick ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Kirsten Chevalier wrote: There's also excellent Haskell documentation available on the web already, but people like to buy books and they like to have an artifact that they can hold in their hands without getting laser printer toner all over themselves. It also helps to collect and edit. Wiki's collect a lot of info, but they are often poorly organized and hard to search. I've always thought this book should be called ``Haskell for Hackers''. I've been collecting guidelines for some time. Here are a few: * The introduction should have some compelling arguments and examples about why someone should bet their business on functional programming. An important focus should be the rise of dual- and quad-core processors, emphasizing the potential for good libraries and compilers to leverage these effectively. * Each and every bit of syntax should be explained in plain language and these explanations should be typeset like theorems, numbered and offset from the rest of the text. The explanations should only use words and concepts that are known to all imperative programmers, or terms that have already been carefully introduced and defined. * Each code fragment should be explained in plain language. Quite often Haskell literature explains something in terms of Haskell, which is fine if you already know Haskell, but maddening if you don't. * IO must be introduced and used in the first chapter. Experienced programmers are not willing to wait until page 327 for some hint about how to replace printf. That doesn't mean that the first chapter will be all about monads, either, just some basics of how to perform IO along with some examples. * Examples should generally be pulled from the imperative literature, not the functional. http://haskell.org/haskellwiki/Simple_unix_tools is a good example. * Alternatives to lex/yacc, shell programming, perl regular expressions and awk/perl style text processing must be covered. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
[...] I think the concept of computer is better to see as sort of telescope or translator. Computers allow to look at processes (and complexity) which would otherwise not conceivable to our limited minds. The idea of computers as telescopes is from Daniel Dennett though. Computer Science is no more about computers than astronomy is about telescopes. :p More relevantly: again Dijkstra, but now on (programming as) composing music: There are many different styles of composition. I characterize them always as Mozart versus Beethoven. When Mozart began to write at that time he had the composition ready in his mind. He wrote the manuscript and it was 'aus einem Guss' (casted as one). And it was also written very beautiful. Beethoven was an indecisive and a tinkerer and wrote down before he had the composition ready and plastered parts over to change them. There was a certain place where he plastered over nine times and one did remove that carefully to see what happened and it turned out the last version was the same as the first one. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
I think there are some great ideas here, and it would be a fantastic project to do as a community, via a wikibook. I, for one, have been studying haskell for several months, and am just starting to see a little bit of light when it comes to monads. I think it would be beneficial to work through a non-trivial construction of a new monad, and the larger examples given would be good opportunities to do that. Andrew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On Mon, 11 Dec 2006, Andrew Wagner wrote: I think there are some great ideas here, and it would be a fantastic project to do as a community, via a wikibook. I, for one, have been studying haskell for several months, and am just starting to see a little bit of light when it comes to monads. I think it would be beneficial to work through a non-trivial construction of a new monad, and the larger examples given would be good opportunities to do that. FWIW, if the book's going to use GADTs then they make building monads without the use of monad transformers much easier - much like constructing a simple virtual machine or interpreter. Which IMO reinforces an important intuition about just what we use monads for. -- [EMAIL PROTECTED] There is no magic bullet. There are, however, plenty of bullets that magically home in on feet when not used in exactly the right circumstances. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On 12/11/06, Andrew Wagner [EMAIL PROTECTED] wrote: I think there are some great ideas here, and it would be a fantastic project to do as a community, via a wikibook. I, for one, have been studying haskell for several months, and am just starting to see a little bit of light when it comes to monads. I think it would be beneficial to work through a non-trivial construction of a new monad, and the larger examples given would be good opportunities to do that. If you (or anyone else who's been participating in the discussion, or anyone else) would like to do a wikibook, that would be great. Personally, I'd like to write / be involved in organizing the writing of a dead-trees book. (In theory, it could be both, but it seems to me like short of being Larry Lessig, there's not really a way to get a publisher to publish something that's already released under a free documentation license -- but correct me if I'm wrong.) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt There's no money in poetry, but there's no poetry in money, either. --Robert Graves ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
A quick search turned up Lulu (http://www.lulu.com/). From the Lulu site: Publish and sell easily within minutes. No set-up fees. No minimum order. Keep control of the rights. Set your own price. Each product is printed as it is ordered. No excess inventory. Looks like they offer hardcover and paperback and are fine with open-source books. More info at Wikipedia: http://en.wikipedia.org/wiki/Lulu.com On 12/11/06, Kirsten Chevalier [EMAIL PROTECTED] wrote: On 12/11/06, Andrew Wagner [EMAIL PROTECTED] wrote: I think there are some great ideas here, and it would be a fantastic project to do as a community, via a wikibook. I, for one, have been studying haskell for several months, and am just starting to see a little bit of light when it comes to monads. I think it would be beneficial to work through a non-trivial construction of a new monad, and the larger examples given would be good opportunities to do that. If you (or anyone else who's been participating in the discussion, or anyone else) would like to do a wikibook, that would be great. Personally, I'd like to write / be involved in organizing the writing of a dead-trees book. (In theory, it could be both, but it seems to me like short of being Larry Lessig, there's not really a way to get a publisher to publish something that's already released under a free documentation license -- but correct me if I'm wrong.) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt There's no money in poetry, but there's no poetry in money, either. --Robert Graves ___ 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: Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On 12/11/06, Matt Revelle [EMAIL PROTECTED] wrote: A quick search turned up Lulu (http://www.lulu.com/). From the Lulu site: Publish and sell easily within minutes. No set-up fees. No minimum order. Keep control of the rights. Set your own price. Each product is printed as it is ordered. No excess inventory. Looks like they offer hardcover and paperback and are fine with open-source books. I suppose I should have clarified that I meant a dead-trees book with a real publisher, but again, if other people want to organize something different based on this thread, they should go ahead! I can only do so much :-) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt ...There is no mystery; there is only paradox, the incontrovertible union of contradictory truths. -- Edward Abbey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Well, perhaps if nothing else, we could use a wikibook to collaboratively work on the structure of such a book, and then from that you could publish a real book. I don't really know the legal issues, though. I am thinking of several books though which have been written and released both as full paper books, and as free digital books. Could we do something similar? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On 12/11/06, Andrew Wagner [EMAIL PROTECTED] wrote: Well, perhaps if nothing else, we could use a wikibook to collaboratively work on the structure of such a book, and then from that you could publish a real book. I don't really know the legal issues, though. I am thinking of several books though which have been written and released both as full paper books, and as free digital books. Could we do something similar? I definitely think using a wiki to work on the book would be a good idea. I just wouldn't want to imply that that meant it would necessarily be a public wiki or that it would be around forever. The legal issues are basically that publishers don't want to publish books that people can get for free off the web (whether or not you agree with this logic). There are exceptions to this, like Lessig's _Free Culture_, but it's my impression that they usually involve authors who have enough sway that publishers will let them get away with whatever they want. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Who needs reasons when you've got the root password?[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
What do you mean by real publisher? As long as the quality of the final product is good, does it really matter what publishing company has their name stamped on it? I'm not sure about Lulu and distribution, but there's also BookSurge (http://www.booksurge.com) which is owned by Amazon. From their distribution page: Through BookSurge, your book is given a unique ISBN (a sales distribution number) and is made available for sale through the world's largest distribution channels. Our authors receive the highest royalty rates in the industry, without smoke and mirror accounting - you receive royalties as a direct percentage of your book's list price on all retail and wholesale channels. There are plenty of details to figure out, but I wouldn't dimiss the open, electronic book - dead-tree book idea just yet. On 12/11/06, Kirsten Chevalier [EMAIL PROTECTED] wrote: On 12/11/06, Matt Revelle [EMAIL PROTECTED] wrote: A quick search turned up Lulu (http://www.lulu.com/). From the Lulu site: Publish and sell easily within minutes. No set-up fees. No minimum order. Keep control of the rights. Set your own price. Each product is printed as it is ordered. No excess inventory. Looks like they offer hardcover and paperback and are fine with open-source books. I suppose I should have clarified that I meant a dead-trees book with a real publisher, but again, if other people want to organize something different based on this thread, they should go ahead! I can only do so much :-) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt ...There is no mystery; there is only paradox, the incontrovertible union of contradictory truths. -- Edward Abbey ___ 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: Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On 12/11/06, Matt Revelle [EMAIL PROTECTED] wrote: What do you mean by real publisher? As long as the quality of the final product is good, does it really matter what publishing company has their name stamped on it? It matters to me; if I'm going to put work into this, then that's what I want the result to be. I'm happy, of course, for projects that I am not involved in to use whatever publishing mechanisms that the people involved in those projects prefer. If you want to help with the writing project that I have in mind, then discuss that on the list. If you want to start another writing project whose primary goal is to produce an open-content, electronic book, then announce that on the list too. If you want to debate the merits of open-content versus traditional publishing, well, I'd love to have that debate too, but this list probably isn't the right forum for that. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt There are many places in computer science where it's actually helpful to procrastinate. -- Eric Brewer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Well, I'm not opposed at all to a written final form. I guess I just don't see that and using a wikibook to assist in our collaboration as mutually exclusive. Anyway, I'd love to help in any such project. By the way, I seem to be messing up the threads. What is considered the correct way to reply to a particular thread? I've been copying and pasting the subject line and writing to [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On 12/11/06, Andrew Wagner [EMAIL PROTECTED] wrote: Well, I'm not opposed at all to a written final form. I guess I just don't see that and using a wikibook to assist in our collaboration as mutually exclusive. I think the confusion is my fault. I assumed that you (if it was you who originally used the word wikibook... it's been a long day) meant wikibook as in the Wikimedia Foundation Wikibooks site, but it seems you meant it as a generic term instead. Sorry. Anyway, I'd love to help in any such project. By the way, I seem to be messing up the threads. What is considered the correct way to reply to a particular thread? I've been copying and pasting the subject line and writing to [EMAIL PROTECTED] I think if you're going to do that, you also need to copy the cross-reference headers, and I don't know if Gmail lets you do that. (I gave up on trying to make that work, and got out of digest mode :-) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt If you try to solve a hard problem, the question is not whether you will use a powerful enough language, but whether you will (a) use a powerful language, (b) write a de facto interpreter for one, or (c) yourself become a human compiler for one. -- Paul Graham ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
I have taken the liberty to read into the definition of practical Haskell; if I'm off target let me know so I can tweak my claims to fit whatever it is I thought I was discussing ;). Two cents: 1) This wouldn't be the first book introducing functional programming to imperative programmers. It would seem wise to investigate existing literature and see how the good ones handled that: which examples, when to introduce what, etc. The purity issue probably will be a novelty to a Haskell book though. 2) This wouldn't be the first book introducing Haskell to functional programmers. It would seem wise to investigate existing literature... I've read (and heard) a lot of claims that the existing learn Haskell books don't teach you real Haskell. I believe it's because the existing books tackle both 1 and 2 above, leaving no room for 3) This would be the first book introducing the nuances of large systems development in Haskell to Haskell programmers. Explaining well various monads (e.g. how to use mtl), or other things necessary for practical Haskell (e.g. ByteString, database interface, web app, parsing, and many other systems libraries), requires of the audience a rather thorough understanding of Haskell's type system (MPTC and other extensions for mirth). In summary: If this is to be a reasonably sized book, then I think it must assume some working knowledge of Haskell. There are a number of good books to learn the basics, but there doesn't seem to be a standard read this book for Haskell systems development. Eschew the basics to make room for the good stuff. If this is not to be a reasonably sized book (i.e. it will go from knowing Haskell 0% all the way to writing real world programs), then I think the good existing literature should be the inspiration for the learn Haskell section. I love the analogies as much as the next programming languages researcher, but I think introducing Haskell in text has been done and done well--it doesn't need a new approach. So don't reinvent the learn Haskell text; that way you can spend time on the good stuff. Nick ps - I'd be happy to participate in varying degrees with any collaborative effort. On 12/11/06, Kirsten Chevalier [EMAIL PROTECTED] wrote: On 12/11/06, Matt Revelle [EMAIL PROTECTED] wrote: What do you mean by real publisher? As long as the quality of the final product is good, does it really matter what publishing company has their name stamped on it? It matters to me; if I'm going to put work into this, then that's what I want the result to be. I'm happy, of course, for projects that I am not involved in to use whatever publishing mechanisms that the people involved in those projects prefer. If you want to help with the writing project that I have in mind, then discuss that on the list. If you want to start another writing project whose primary goal is to produce an open-content, electronic book, then announce that on the list too. If you want to debate the merits of open-content versus traditional publishing, well, I'd love to have that debate too, but this list probably isn't the right forum for that. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt There are many places in computer science where it's actually helpful to procrastinate. -- Eric Brewer ___ 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] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On 11 Dec 2006, at 19:35, Kirsten Chevalier wrote: On 12/11/06, Andrew Wagner [EMAIL PROTECTED] wrote: Well, perhaps if nothing else, we could use a wikibook to collaboratively work on the structure of such a book, and then from that you could publish a real book. I don't really know the legal issues, though. I am thinking of several books though which have been written and released both as full paper books, and as free digital books. Could we do something similar? I definitely think using a wiki to work on the book would be a good idea. I just wouldn't want to imply that that meant it would necessarily be a public wiki or that it would be around forever. The legal issues are basically that publishers don't want to publish books that people can get for free off the web (whether or not you agree with this logic). There are exceptions to this, like Lessig's _Free Culture_, but it's my impression that they usually involve authors who have enough sway that publishers will let them get away with whatever they want. Well, I know that e.g., Cory Doctorrow puts his books online for free, and he seems to have no trouble also getting printed versions sold (see for example http://craphound.com/someone/). So I guess it should be possible to do. Especially because the demand will be quite large, IMO. A collection of real-world examples a la dive into python would certainly be on the top of my to buy list. -- Andy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Since people keep saying the word wikibook, I will make the obligatory mention of http://en.wikibooks.org/wiki/Haskell It might not yet have the style/voice/sense of direction that we're discussing here, but maybe people might be interested in shaping that book into something really interesting? -- Eric Kow http://www.loria.fr/~kow PGP Key ID: 08AC04F9 Merci de corriger mon français. pgpgVb0V5K8cV.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Sorry, wasn't sure I had clearly expressed that it's possible to have an open book end up as a dead-tree book. Either way, I'm interested in helping. On 12/11/06, Kirsten Chevalier [EMAIL PROTECTED] wrote: It matters to me; if I'm going to put work into this, then that's what I want the result to be. I'm happy, of course, for projects that I am not involved in to use whatever publishing mechanisms that the people involved in those projects prefer. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: Re: Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Ok, well I think we can all agree that such a book is a good idea. I suggest we take the discussion to some kind of collaboration tool. It's pretty hard to do just on this mailing list. There are a lot of options, such as finding a forum somewhere, creating a wiki book somewhere and having a mailing list too, using google's collaborative authoring tool, or whatever. Suggestions? Sorry, wasn't sure I had clearly expressed that it's possible to have an open book end up as a dead-tree book. Either way, I'm interested in helping. On 12/11/06, Kirsten Chevalier [EMAIL PROTECTED] wrote: It matters to me; if I'm going to put work into this, then that's what I want the result to be. I'm happy, of course, for projects that I am not involved in to use whatever publishing mechanisms that the people involved in those projects prefer. ___ 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: Re: Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On Mon, 2006-12-11 at 13:42 -0600, Nicolas Frisby wrote: Two cents: Two (Croatian) lipas, much less than two cents :-( 3) This would be the first book introducing the nuances of large systems development in Haskell to Haskell programmers. Explaining well various monads (e.g. how to use mtl), or other things necessary for practical Haskell (e.g. ByteString, database interface, web app, parsing, and many other systems libraries), requires of the audience a rather thorough understanding of Haskell's type system (MPTC and other extensions for mirth). Right. We need something practical after one is finished with e.g. Thompson's Craft or Hudak's SOE. I love the analogies as much as the next programming languages researcher, but I think introducing Haskell in text has been done and done well--it doesn't need a new approach. So don't reinvent the learn Haskell text; that way you can spend time on the good stuff. I agree and want to encourage the effort to bring 'practical Haskell' to the masses. Today one user in #haskell.hr expressed his doubt whether ...Haskell has any future out of academic circles... Sincerely, Gour signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On 12/11/06, Kirsten Chevalier [EMAIL PROTECTED] wrote: It's not as if this is the first time that this has been suggested, but some people have suggested that a practical book about Haskell would be a good idea. I agree. Some people have also suggested that the right moment for this hasn't arrived yet, and I see that as a challenge. IMO the number one problem with existing books is that they are far to structured. I.e. first we'll spend one chapter on functions, then one on types, then one on laziness, then one on data types etc. But that means you can't really show off anything useful until the last chapter! I think the problem is that most authors are academics, and used to a very systematic way of explaining things - the problem is that when Average Joe has read two chapters, he will want to try out some ideas of his own, and if you haven't given him the basic tools to do Real Stuff by then, he'll think the language isn't meant for real world usage and that impression will stick. Yes, monads are cool, but for Average Joe who doesn't give a hoot about category theory we don't need too specific. And we REALLY don't need to hold off on IO until chapter 18 because we feel that we couldn't do the subject justice until then (again, there is no need to explain it in detail right away). For example, most books on C++ include plenty of operations on various ostreams way before they actually explain how they work. As far as the newbie is concerned, cout is a keyword that lets you print stuff, and later on he'll realise that it's just a library. So my point is that the book should give examples of REAL programs, even if they're just small examples. Use IO when necessary and start off by keeping it simple (e.g. Haskell enforces that side effects are kept separate from functions, thus we have both actions and functions - you don't need much more than that to begin with, just pretend that the IO monad is imperative haskell and that the only weird thing about Haskell is that you have to keep imperative haskell separate from pure haskell). I find that many text books and tutorials hold off on this for far too long which gives an impression that IO and all the real world stuff is somehow difficult in Haskell. Ironically I think the reason is that the authors are so excited about how elegant and nice it is in Haskell that they feel the need to explore it in super high detail rather than just gloss it over (hence they put it in chapter 18 when the reader is familiar enough with Haskell to understand it). This same thing goes for type classes and data types. If your first 10 examples use only tuples and lists, then that's what people will use in their own programs. Use data types right away when it makes sense. And type classes too, and explain each usage with increasing accuracy until you get to the chapter dealing with it specifically at which point you let loose with all the gritty details. There must be some way of teaching Haskell breadth first, so to speak. -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On 12/11/06, Andrew Wagner [EMAIL PROTECTED] wrote: Ok, well I think we can all agree that such a book is a good idea. I suggest we take the discussion to some kind of collaboration tool. It's pretty hard to do just on this mailing list. There are a lot of options, such as finding a forum somewhere, creating a wiki book somewhere and having a mailing list too, using google's collaborative authoring tool, or whatever. Suggestions? Yes, I think it's quite clear now that there's enough interest in this, and we shouldn't get distracted by the licensing equivalent of bikeshed-coloring. I should have enough web hosting space to set up a wiki and a mailing list for discussion, so I'll go ahead and do that sometime over the next couple of days, and follow up here. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Science fiction is not predictive; it is descriptive.--Ursula K. Le Guin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Hi Sebastian. As a writer of one of those "academic" Haskell textbooks, I've been following this thread with some interest. In fact, I agree with pretty much everything that's been said. But I must point out that, even though Chapter 18 in SOE is titled "Higher Order Types", and that's where I introduce the Monad class, I actually introduce IO in Chapter 3 -- page 36 in a 363 page textbook to be more precise. In fact, I do exactly as you suggest -- introduce IO early in a way that most imperative programmers are familiar with, and then expose the beauty and generality of monads much later -- i.e. in Chapter 18. I don't know if you were referring to SOE when you said Chapter 18, but I thought that I should point out the coincidence, at least, if that's what it is! :-) While I'm at it, I have a couple of other general comments: I purposely wrote SOE in a style that I was hoping would be different from the standard language textbook, namely I tried to introduce language features as they were needed in solving problems, rather than just rattling off a list of language features. Granted, my toy "multimedia" examples are not well motivated by the real world, so it doesn't necessarily apply to what's now being proposed. But I wanted to point out that this was nevertheless really hard to do, and the sequencing of the material was a real challenge -- I'm not even sure that I would follow this formula again if I rewrote the book. Maybe some of you can do better, but it's really tough to show someone how an advanced Haskell programmer would solve advanced problems that arise in the real world. As a simple example, I love this recent quote by Garrett Morris: "I'm personally fond of framing most non-trivial Haskell problems as defining domain specific languages; as a result, everything over about 200 lines that I've written in the past 3 years has used the mtl [Monad Transformer Library] in some form or fashion. It's great." So how do we teach Garrett's way of programming (which I like very much) to the masses? One would guess that we'd need to explain not only monads, but also monad transformers, first. One of the things I found myself doing in SOE is saying things like, "remember that thing we did way back in Chapter 3? Using monads, we can now express it more elegantly and modularly and succinctly like this: ..." But there is danger in doing this. If we teach newbies how to do things the "beginner's" way first (recursion instead of higher-order functions, lists instead of user-defined data types, specialized functions instead of type classes, and so on), then we risk the user saying "Oh this is just typed Lisp, so I'm outa here." So, I am *all for* someone writing a textbook that tackles real, meaty problems from the real world. But it's not at all clear to me how to do it. There seems to be a need for a fine balance between elementary stuff and advanced stuff, mixed with both elementary and advanced applications. I hope that some of you are up for the challenge! -Paul Hudak Sebastian Sylvan wrote: On 12/11/06, Kirsten Chevalier [EMAIL PROTECTED] wrote: It's not as if this is the first time that this has been suggested, but some people have suggested that a practical book about Haskell would be a good idea. I agree. Some people have also suggested that the right moment for this hasn't arrived yet, and I see that as a challenge. IMO the number one problem with existing books is that they are far to structured. I.e. "first we'll spend one chapter on functions, then one on types, then one on laziness, then one on data types" etc. But that means you can't really show off anything useful until the last chapter! I think the problem is that most authors are academics, and used to a very systematic way of explaining things - the problem is that when Average Joe has read two chapters, he will want to try out some ideas of his own, and if you haven't given him the basic tools to do Real Stuff by then, he'll think the language isn't meant for real world usage and that impression will stick. Yes, monads are cool, but for Average Joe who doesn't give a hoot about category theory we don't need too specific. And we REALLY don't need to hold off on IO until chapter 18 because we feel that we couldn't do the subject "justice" until then (again, there is no need to explain it in detail right away). For example, most books on C++ include plenty of operations on various ostreams way before they actually explain how they work. As far as the newbie is concerned, "cout" is a keyword that lets you print stuff, and later on he'll realise that it's just a library. So my point is that the book should give examples of REAL programs, even if they're just small examples. Use IO when necessary and start off by keeping it simple (e.g. "Haskell enforces that side effects are kept separate from functions, thus we have
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
I think this might be a good time to step back and make some general comments of my own. I learned Haskell in the summer of 2000. I see that that's exactly when SOE was published. I didn't have a copy. (I did acquire a copy of SOE about two years later, when I didn't need it anymore :-) I did have another book whose name I won't mention that I didn't find entirely helpful (I won't mention its name since I don't remember entirely for sure which book it was). I remember sitting in a windowless office trying to figure out why I couldn't seem to find any function that had the type IO a - a. I'm thinking about that now because I hope to be able to not forget what it was like to be in that frame of mind. I'm sure SOE answers that question early on. But newbies on #haskell still ask it pretty often anyway. Obviously, there will always be people who don't know how to pick up a book, but on the other hand, I don't think that the problem of how to explain Haskell to beginners is solved yet. So the book that I want to write, hopefully with help from a few other people (maybe some of the people who've been contributing to the discussion so far, maybe others) would be aimed at a beginner (not a beginning programmer, but someone who's starting *perhaps* because they want to contribute to an open-source project that's written in Haskell, because there are such projects now that aren't Haskell compilers) who wants to get to the point where they can get real work done. And I'm not thinking of it as a textbook. Maybe this is way too ambitious. But I know that I managed to get from wondering where the IO a - a function was to writing my own monad transformers, mostly by fumbling around in the dark, and I can't help thinking that there might be a possible book that would -- if not make it that much *easier* for somebody else to do the same -- at least allow *more* people to do the same. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt and the things I'm working on are invisible to everyone--Meg Hutchinson ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On 12/11/06, Paul Hudak [EMAIL PROTECTED] wrote: Hi Sebastian. As a writer of one of those academic Haskell textbooks, I've been following this thread with some interest. In fact, I agree with pretty much everything that's been said. But I must point out that, even though Chapter 18 in SOE is titled Higher Order Types, and that's where I introduce the Monad class, I actually introduce IO in Chapter 3 -- page 36 in a 363 page textbook to be more precise. In fact, I do exactly as you suggest -- introduce IO early in a way that most imperative programmers are familiar with, and then expose the beauty and generality of monads much later -- i.e. in Chapter 18. I don't know if you were referring to SOE when you said Chapter 18, but I thought that I should point out the coincidence, at least, if that's what it is! :-) Heh, that really was a coincidence. Honest! I must confess I've only briefly leafed through your book at the library (the motivation to buy beginner's text books disappears after you've gone through one or two of them), but I always did like the concept in it of teaching through something more fun like multimedia. I wonder if a similar theme is apropriate for proposed book. Graphics and sounds give a very direct feedback to the programmer, and I expect that helps with the motivation. Perhaps a single largish application could be the end product of the book. Like a game or something. You'd start off with some examples early on, and then as quickly as possible start working on the low level utility functions for the game, moving on to more and more complex things as the book progresses. You'd inevitably have to deal with things like performance and other real world tasks. It might be difficult to find something which would work well, though. -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
G'day all. Quoting Kirsten Chevalier [EMAIL PROTECTED]: I suppose I should have clarified that I meant a dead-trees book with a real publisher, [...] Something more like this, then: http://phptr.com/perens Maybe we should come up with an outline and a sample chapter or two, then talk to Bruce? Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On 12/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: G'day all. Quoting Kirsten Chevalier [EMAIL PROTECTED]: I suppose I should have clarified that I meant a dead-trees book with a real publisher, [...] Something more like this, then: http://phptr.com/perens Maybe we should come up with an outline and a sample chapter or two, then talk to Bruce? That looks interesting. I'm not sure we fit in, but then, I'm not sure whether this idea fits in, as such, anywhere. I think there are a few things to figure out before we get to the point of writing an outline, but it's a reasonable thing to write in any case. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt in a recent future, this is past -- James Keelaghan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Hi, I wonder if a similar theme is apropriate for proposed book. Graphics and sounds give a very direct feedback to the programmer, and I expect that helps with the motivation. Perhaps a single largish application could be the end product of the book. Like a game or something. You'd start off with some examples early on, and then as quickly as possible start working on the low level utility functions for the game, moving on to more and more complex things as the book progresses. You'd inevitably have to deal with things like performance and other real world tasks. It might be difficult to find something which would work well, though. Maybe this idea (ok, isJust) comes to mind because I'm looking around at cakephp, which is a rails like framework for PHP, but a real-life example could be something like rails. It need not be as extensive or fully fledged, but enough such that people can get the hang of things and take it from there. That would include DB interaction, web interaction, logging, XML and what have you. It might just require enough of the more exotic Haskell stuff to get newbies up to speed. Details can be tackled either when they arise or deferred to an appendix, if they bloat the actual issues that is being explained. Just my €.02 -- Andy PS. I still belong somewhat to the latter category of the subject. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
