Hello everybody, I joined this list after spending a good while learning Haskell basics with the Wikibook and at the same time trying to do some refactoring on the book itself. Consider this a test message: I am looking for other people interested in discussing ways to improve the contents, and I'm polling the reactions/activity of the subscribers of this list. I am particularly interested in the Beginner Modules - not only because it's the area I, as a newbie haskeller, feel more comfortable in contributing to right now, but also because it naturally would tend to be kind of overlooked by veterans willing to add interesting stuff in the advanced chapters (as far as I can be aware of, only one Wikibook regular has seen some of my contributions there so far, namely Apfelmus). Waiting for your replies ;-) Daniel Mlot P.S.: Forgive me for any etiquette mistakes, it is the first time I'm using a conventional mailing list as opposed to a phpBB forum or something in that vein.
On Thu, May 06, 2010 at 14:50:06 -0700, Daniel David wrote:
Waiting for your replies ;-)
Please don't be discouraged if nobody replies. You could be responsible for breathing new life into this list. Where does the Haskell Wikibook fit it in a LYAH and RWH age? What can we contribute? -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9
Hello, Anything I can do? Paul
On Thu, May 06, 2010 at 14:50:06 -0700, Daniel David wrote:
Waiting for your replies ;-)
Please don't be discouraged if nobody replies. You could be responsible for breathing new life into this list.
Where does the Haskell Wikibook fit it in a LYAH and RWH age? What can we contribute?
-- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9
_______________________________________________ Wikibook mailing list Wikibook@haskell.org http://www.haskell.org/mailman/listinfo/wikibook
Eric Y. Kow wrote:
Daniel David wrote:
Waiting for your replies ;-)
Please don't be discouraged if nobody replies. You could be responsible for breathing new life into this list.
Indeed, thanks for your contributions, Daniel! :)
Where does the Haskell Wikibook fit it in a LYAH and RWH age? What can we contribute?
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. Daniel David wrote:
I am particularly interested in the Beginner Modules - not only because it's the area I, as a newbie haskeller, feel more comfortable in contributing to right now, but also because it naturally would tend to be kind of overlooked by veterans willing to add interesting stuff in the advanced chapters
I admit being mainly interested in the advanced chapters. :D Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com
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
On Fri, May 07, 2010 at 09:50:50 -0300, Daniel Mlot wrote:
To Eric and Paul, who asked what they can do to help.
Whoops,
Where does the Haskell Wikibook fit it in a LYAH and RWH age? What can we contribute?
I meant more generally what Wikibooks can contribute to the Haskell learning world. Personally, I'll be watching from the sidelines and cheering you on :-) -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9
On 05/07/2010 09:58 AM, Eric Kow wrote:
On Fri, May 07, 2010 at 09:50:50 -0300, Daniel Mlot wrote:
To Eric and Paul, who asked what they can do to help.
Whoops,
Where does the Haskell Wikibook fit it in a LYAH and RWH age? What can we contribute?
I meant more generally what Wikibooks can contribute to the Haskell learning world.
Personally, I'll be watching from the sidelines and cheering you on :-)
That's fine, you already did quite a lot, as clearly demonstrated by the many side notes of yours I've met, Kowey :-)
Daniel Mlot wrote:
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.
Yep. In particular, people are likely to read the advanced material after having learned Haskell from other tutorials and so on. We can as well embrace modularity.
(Trees, general map and fold) > Zippers > (Maps? Arrays?) > ... I also
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 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 ).
Indeed, the main drawback of modularity is the loss of clear navigation. Tracking prerequisites and study guides can alleviate that. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com
participants (6)
-
Daniel David -
Daniel Mlot
-
Eric Kow -
Eric Y. Kow
-
Heinrich Apfelmus -
PR Stanley