[Haskell wikibook] Re: Anyone around?

[Daniel Mlot]

To Eric and Paul, who asked what they can do to help. The answer is 
pretty much anything, from small things to bigger ones :) From improving 
the examples on the beginners module, to filling some of the gaps in 
advanced or helping with some editorial decisions that need to be made 
(like settling on a standard style for displaying code examples), to 
simple proofreading. I will put up some particular issues in more 
specific messages later on.

On 05/07/2010 06:27 AM, Heinrich Apfelmus wrote:
> Eric Y. Kow wrote:
>> Daniel David wrote:
>> Where does the Haskell Wikibook fit it in a LYAH and RWH
>> age?  What can we contribute?
>

I must admit I was having enough fun with the Wikibook to allow myself 
to remain in blissful ignorance of other tutorials (well, at least until 
I attempted to read the more complicated stuff in Advanced). Both of the 
resources you mentioned really seem to be excellent, indeed. But I find 
the Wiki concept appealing for programming students because it allows 
some unique and appealing possibilities of enriching the contents, such 
as people adding their notebook annotations or exercises based on 
real-life experience. And then there are Apfelmus' considerations...

> Good question, but I have a good answer, or rather, a plan.
>
> One of the main differences of the wikibook compared to a paper book is
> that it's *modular*: you don't have to read the whole wikibook in order
> to understand and profit from a single chapter. Well, the wikibook is
> not really structured like that at the moment, but I would like to see
> this happen.
>
> In particular, I'd like to keep track of dependencies, for example by
> adding a small infobox to each chapter along the lines of
>
> "Before reading this chapter, you have to understand: Basic Haskell,
> Lazy Evaluation."
>
> For instance, this would greatly improve the introduction to monads;
> it's not uncommon for Haskell beginners to skip over the "easy" stuff
> and get stuck at monads because they don't have a good grasp on concepts
> like type constructors and higher order functions. By making
> dependencies explicit, they can backtrack and patch up their
> understanding without having to read the whole book.
>
> Of course, the key point is the skill of the authors to make chapters
> fairly independent; i.e. to make dependencies substantially smaller than
> "read the whole book". But I already have a structure for the Haskell
> wikibook in mind that can do this.
>


Actually that has a lot to do with some of my ideas about the book. 
Going through all of the beginner lessons in a very short amount of time 
and then at least skimming through most of advanced made me realize a 
couple things about its overall structure, the main point being that the 
learning curve is not smooth and predictable, and it would be very 
difficult to make it so without dumbing down the contents.

For instance, after a beginner gets a good grasp of the elementary 
concepts in the first two chapters (Basics/Elementary) Intermediate 
Haskell is no more difficult than what came before. Then of course there 
are the monads. Understanding Monads is quite a bit harder than the 
preceding material, but a newbie with some patience will get a good 
grasp of the key concepts because that module is exceedingly well 
written (it presents monads as so powerful you just *have* to understand 
them). From them on, the difficulty quickly ramps up through the 
advanced monad stuff (transformers, etc. - I still have to really 
understand how that works) and hitting a peak at the arrows chapters at 
the very beginning of advanced. But then, right in the middle of 
advanced, there is that wonderful module on zippers, which is much more 
accessible than what comes just before it (well, at least the first, 
more practical part is). And then most of the material in the Fun with 
Types chapter can be understood and prove useful independently of the 
really difficult stuff about I mentioned.

That leads to the conclusion that following the book linearly is 
probably not the optimal way to do it, specially when one gets to the 
more advanced topics. I thought about having a study guide, which 
presented the dependency tree (as Apfelmus suggested) as well as trails 
on a particular topic, as in Data structures: Lists and tuples > More 
about lists > List processing > (Type declarations) > More on datatypes 
 > (Trees, general map and fold) > Zippers > (Maps? Arrays?) > ... I 
also think it would be great having some visually rich way of presenting 
the relationships, like using conceptual maps (for instance, have a look 
at this nifty tool: http://cmap.ihmc.us/conceptmap.html ).

---

Thanks for the feedback, see you all later :)

Daniel Mlot