headers
Daniel Mlot | 1 Jun 16:56
Picon
Favicon

Re: Re: Truth values and a couple other things

On 05/29/2010 04:58 PM, Heinrich Apfelmus wrote:
>
> Eric Kow once remarked that the wikibook is a
> "do-ocracy" which means that by doing something, like writing a chapter
> or making a change, you automatically get the right to do it.
>

I think I will quote you both in my user page :)

>
> By the way, a principle that has helped me in my writing is that I try
> to keep it really short, even minimize the number of words I use to make
> a point. Great for clarity and readability, though a bit dry at times. I
> always imagine that I'm writing for a reader whose attention is really
> low and lasts only one additional paragraph, which is probably indeed
> the case for any reader after a certain amount of time. :)
>

As you probably noticed already, I am slightly more inclined to flowery, 
colourful language. Thankfully as of late I have been able to keep 
myself under check and not get too prolix. In any case, the book would 
certainly profit from some extra conciseness - some existing passages 
grow really tiring just because the same idea is reiterated one time too 
many.

----

About the writing of "Truth Values" and the reworking of "Type Basics" 
(which I started yesterday) there are two main outstanding questions:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Heinrich Apfelmus | 3 Jun 21:31
Picon
Favicon
Gravatar

Re: Truth values and a couple other things

Daniel Mlot wrote:
> 
> About the writing of "Truth Values" and the reworking of "Type Basics"
> (which I started yesterday) there are two main outstanding questions:
> 
> 1. In "Truth Values" your outline included introducing True/False
> pattern matching when discussing the boolean operators. At first I
> thought it wasn't a good idea, as explained on the Talk page. But now,
> after having a closer look at "Type Basics" and the examples therein, I
> realize that not introducing an idiom this elementary idiom early on
> might be pedagogically problematic, as it may induce newbies to do very
> simple things in obtuse ways (like defining something like (||) with
> guards). In that case, a brief example - with (||), not, etc. could
> easily be added to the Boolean operations section, but I am not sure on
> what would be a clear, simple and not misleading way of introducing
> pattern matching at this point (discussing the general PM concept would
> likely not work, and saying "you can define functions with multiple
> definitions in terms of cases for (quasi-literal?) values of the
> arguments" could get too confusing (mainly the "quasi-literal" part -
> which really means literals and argument-less constructors, but
> obviously we can't go that far at this point of the book).

I like Graham Hutton's way of introducing pattern matching a lot.
(chapter 4.4. of Programming in Haskell). He starts with the obvious

  not False = True
  not True  = False

repeats the "complete case analysis" concept with
(Continue reading)

Permalink | Reply | 3 comments |
headers
Daniel Mlot | 8 Jun 08:38
Picon
Favicon

Re: Next steps (both literally and the module)

On 06/03/2010 04:31 PM, Heinrich Apfelmus wrote:
> Daniel Mlot wrote:
>
>> 2. I am starting to believe that "Type Basics" should be divided in two.
>> More specifically, the first part would retain the introduction, the
>> experiments of :t, the presentation of Char and String and the section
>> about functional types. The second part would have the final section
>> about type signatures in code and the new section on number types.
>> Finally, "Lists and Tuples" would be sandwiched between the two parts.
>
> Sounds good. :)
>
> Personally, I would cut a lot to make it shorter and more "digestible",
> though; which might make a split unnecessary. The more elaborate
> discussion can always be taken up again in the subsequent "Elementary
> Haskell" track.
>

I just created the proposed "Type basics II" module. The changes I did 
so far are sort of in between my approach and yours (not that they were 
really in conflict to begin with, but anyway), as I will now explain...

> In other words, I would do the following:
>
> * Cut the introduction. Make  "5<  False  does not make sense" the sole
> motivation for types.

While I agree that the introduction does need streamlining, I am not so 
sure about eliminating it completely, as it can be useful for making it 
easier for readers to amalgamate all the other discussions in this part
(Continue reading)

Permalink | Reply | 2 comments |
headers
Heinrich Apfelmus | 10 Jun 14:37
Picon
Favicon
Gravatar

Re: Next steps (both literally and the module)

Daniel Mlot wrote:
> Heinrich Apfelmus wrote:
>>
>> * Cut the introduction. Make  "5<  False  does not make sense" the sole
>> motivation for types.
> 
> While I agree that the introduction does need streamlining, I am not so
> sure about eliminating it completely, as it can be useful for making it
> easier for readers to amalgamate all the other discussions in this part
> of the book around the key conceptual issue - that types are a way of
> incorporating meaning into values. That is why I kind of like the
> abstract "real world" example, even if in its current form it is a bit
> too overcooked to drive the point home.

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.

> 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Mlot | 13 Jun 03:42
Picon
Favicon

Re: Re: Next steps (both literally and the module)

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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane