[Haskell-cafe] Re: Writing "Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'"

[Kurt]

On Wed, 13 Dec 2006 17:18:31 +0100, Justin Bailey <jgbailey at gmail.com>  
wrote:

> On 12/12/06, Joachim Durchholz <jo at durchholz.org> wrote:
>>
>> Agreed.
>> Something along the lines of "The Art of Functional Programming".
>
>
> +1 . I would love to read something that is the equivalent of 'design
> patterns',  but for functional languages. I thought Osasaki's book  
> "Purely
> Functional Data Structures" would have that, but it was little too  
> focused
> on proving properties of algorithms. As someone in industry, that wasn't  
> so
> important to me. I want to learn how to "think" functionally.

Seconded! The thing I appreciate about e.g. OO is that it is very clearly  
articulated what the principles are to make good design choices. Having  
e.g. some experience with grading fairly large OO projects from masters  
students, such a number of general rules of thumb are invaluable. It  
allows you to transform "good design" much more directly than through the  
typically Haskell way (it seems) of "code examples". OO also has a clear  
goal: to improve reuse and simplify evolution. More or less all design  
problems can be illustrated by saying: "but what happens if I want to add  
functionality y? You'll have to modify code in 200 places!"

It seems that most (all?) Haskell introduction focus on features  
(functions, pattern matching, type classes, monads,...), who seem somewhat  
interchangeable for any given problem (at least to my newbie eyes). Also,  
most idioms on the wiki and answers on questions here are based on very  
specific examples, from which I find it hard to generalise. Usually the  
argument goes along this way:

"Oh, I see you're using feature x (e.g. type classes). I prefer to use  
feature y (e.g. higher order functions) here, _because it's much more  
elegant_, and I rewrote your code as follows:"

Instead of that emphasised part, I'd like to see a more particular  
explanation, that starts from properties of the _problem_ (not of the  
solution). Along the lines of:

"Oh, I see you're having a typical representation problem where you need  
to decouple a data types structure from its content. Generally, this can  
be handled by using features x and y as follows. This will make it easy  
for you to change the type's content later with minimum changes, but will  
affect performance negatively if you' re not careful when using feature  
z." (ok, that didn't actually make sense, but you get the picture)

Design patterns are a good way to make such knowledge explicit. At the  
moment, while learning haskell, my most important difficulty is how to  
translate a given problem to an elegant solution. What is elegant? What  
are my benchmarks to weigh different solutions against each other?

Kurt