On 06/10/2010 09:37 AM, Heinrich Apfelmus wrote:
Ah, it's just that in my experience, conceptual explanations usually do not work so well for introducing someone to a new concept for the first time. Usually, a hands-on approach that simply uses the concept gives better results: the student needs to figure out the concept himself, and usually does so in order to memorize the material anyway.
I think Brent Yorgey has put it most brilliantly in his remark on the "Monad Tutorial Fallacy":
http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-...
In other words, the concept is synthesized from its particular examples, not the other way round.
On a general note, these considerations are related to an important point about the Wikibook as a whole (or at least my vision for it). One important differential of the Beginner's Trail when compared with other Haskell tutorials is leanness. The immediate consequence of that is practical: For instance, I went through most of it in about ten days, and got a reasonably good initial understanding of how Haskell works (at least for a complete newbie to functional programming). Certainly things wouldn't advance as quickly for me with, say, "Real World Haskell". Beyond mere expediteness, however, a book painted with broad strokes provide room for readers to complete the picture by acting on their curiosity, testing alternatives and developing their personal understanding and insights. This approach goes nicely with recognizing the "monad tutorial fallacy" and avoid converting analogies and running examples into straitjackets. (By the way, I would like to keep those things in mind when writing; so if you find any of my texts get bogged into excess detail and verbosity please warn me so I can fine tune my approach.) Back to "Type Basics", it seems the underlying problem (or why the text doesn't quite fit with the perspectives we are discussing) is the lack of strong examples that go beyond the mechanics and illustrate the point of having (and taking advantage of) a good type system. Of course, whether it is worth it to tackle this conceptual point upfront at such an early point (assuming readers with very little experience in functional programming) is up for debate. And finally: I still have not given up completely on that introduction :-) Maybe if all references to databases and actual computation are removed (retaining only, say, a paper phone book) an useful (or at least nice) simple analogy may be presented - one that does not try to explain anything concrete, but just provide food for thought. When I feel inspired enough I will attempt a draft for you to judge whether my point is valid.
Finally, a question about Next Steps the module. Do you see a place for it in the overall scheme of things? My question is largely motivated by the fact I am finding it rather difficult to picture a way to incorporate pattern matching into the "soft", largely conceptual modules about the type system (I am counting "Truth values" and "Lists and tuples" among these) without breaking their flow. That leads me to consider introducing piece-wise function definitions or even (x:xs) and (x,y) in a separate context.
Since the current Next Steps chapter is mainly about the alternative ("expression" vs "declaration") syntax to guards, where, and pattern matching, it should be moved to the second part of the beginners' track.
Perfect - chances are it will end up being split and redistributed between "More on Functions" and "Control Structures", except the part on function composition.
Concerning the flow, I think that thanks to the modularity of the wikibook, we don't need to worry much about it. Simply making a new chapter on pattern matching seems fine to me.
I have some ideas on how to do an early introduction to pattern matching to put in the slot currently occupied by "Next Steps", and will attempt a draft over the following few days.
The function composition operator is another potentially useful thing in "Next Steps" (because it fits well with the idea of stimulating creative usage of Prelude functions) that would be difficult to move to an earlier point of the book. That case is less serious, though, as there is the option of just moving it to "More on Functions".
Either "More on Functions" or the cheat sheet texts, I'd say.
The general concept of function composition would be key in illustrating how important is having a good vocabulary of functions, so it would make sense to have it in the cheat sheet module. The usage of the (.) operator might be delayed to "More on Functions" if need be. Regards, Daniel Mlot