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.
Post by Heinrich ApfelmusPost by Eric Y. KowWhere 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...
Post by Heinrich ApfelmusGood 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
Post by Heinrich Apfelmus(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