[Haskell wikibook] Re: Next steps (both literally and the module)

[Daniel Mlot]

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-tutorial-fallacy/
>
> 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