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

On Wed, 13 Dec 2006 17:18:31 +0100, Justin Bailey wrote:

On 12/12/06, Joachim Durchholz 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