[Haskell-cafe] Re: Writing "Haskell For Dummies Or At Least For
People Who Feel Like Dummies When They See The Word 'Monad'"
kurt.schelfthout at gmail.com
Thu Dec 14 05:20:58 EST 2006
On Wed, 13 Dec 2006 17:18:31 +0100, Justin Bailey <jgbailey at gmail.com>
> On 12/12/06, Joachim Durchholz <jo at durchholz.org> wrote:
>> 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
> Functional Data Structures" would have that, but it was little too
> on proving properties of algorithms. As someone in industry, that wasn't
> 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?
More information about the Haskell-Cafe