On Wed, 13 Dec 2006 17:18:31 +0100, Justin Bailey <[EMAIL PROTECTED]>
wrote:
On 12/12/06, Joachim Durchholz <[EMAIL PROTECTED]> 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
