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.
(Trees, general map and fold) > Zippers > (Maps? Arrays?) > ... I also think it would be great having some visually rich way of presenting
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 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