[Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Kirsten Chevalier wrote: It's not as if this is the first time that this has been suggested, but some people have suggested that a practical book about Haskell would be a good idea. I agree. Some people have also suggested that the right moment for this hasn't arrived yet, and I see that as a challenge. I know this is a late reply, but some of us tried to get something like this off the ground a little while back. darcs get --partial http://software.complete.org/haskell-v8/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
John Goerzen wrote: I know this is a late reply, but some of us tried to get something like this off the ground a little while back. darcs get --partial http://software.complete.org/haskell-v8/ My brain is fried. Make that: darcs get --partial http://darcs.complete.org/haskell-v8 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Hello John, Tuesday, December 19, 2006, 7:16:48 PM, you wrote: It's not as if this is the first time that this has been suggested, but some people have suggested that a practical book about Haskell would be a good idea. I agree. Some people have also suggested that the right moment for this hasn't arrived yet, and I see that as a challenge. I know this is a late reply, but some of us tried to get something like this off the ground a little while back. Haskell book? it can't be too late, it's invaluable thing! -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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 [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
Re: [Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On 12/13/06, 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. Check out this paper by Jeremy Gibbons, Design Patterns as Higher-Order Datatype-Generic Programs: http://web.comlab.ox.ac.uk/oucl/work/jeremy.gibbons/publications/index.html#hodgp If you want to learn how to think functionally, forget you ever heard the words design pattern. There shouldn't be patterns in your programs. If there are, that means that either your language isn't providing you with enough abstractions or that you aren't using the abstractions that are available (or possibly both). Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Anyone who spends their life on a computer is pretty unusual. -- Bill Gates ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
ke, 2006-12-13 kello 08:18 -0800, Justin Bailey kirjoitti: 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 Hi, Would the following fit the need? http://www.cs.vu.nl/Strafunski/ http://www.cs.vu.nl/Strafunski/dp-sf/ br, Isto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Those are some great resources, thanks everyone! Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On Thu, 14 Dec 2006, Kirsten Chevalier wrote: ... If you want to learn how to think functionally, forget you ever heard the words design pattern. There shouldn't be patterns in your programs. If there are, that means that either your language isn't providing you with enough abstractions or that you aren't using the abstractions that are available (or possibly both). Well, maybe not Patterns, but wouldn't there be important skills relating to patterns in a more general sense? Like fold, for example, seems to be a pattern, with several standard implementations and no doubt countless others to suit particular applications. Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
G'day all. Quoting Donn Cave [EMAIL PROTECTED]: Well, maybe not Patterns, but wouldn't there be important skills relating to patterns in a more general sense? Like fold, for example, seems to be a pattern, with several standard implementations and no doubt countless others to suit particular applications. This is actually an excellent illustration of what patterns actually are. Patterns are a form of engineering experience. When we see the same form of code or data turning up multiple times, we abstract it and give it a name so we can reason about it independently of any application that we find it in. This is exactly the same as category theory. The point of category theory is to spot patterns in mathematical structures, and then abstract them away from those structures, and give them names so we can reason about them independently. The only real problem with patterns (apart from the hype) is that some people have the mistaken impression that Design Patterns == Gang of Four Book. The patterns that GoF documented were not meant to be an exhaustive list, nor were they meant to apply to non-OO languages. (The plethora of modern C++-style headers which encapsulate a lot of the GoF patterns are good examples.) Some patterns have different names in other languages. What GoF calls factory method, for example, a Haskell programmer would call smart constructor. What they call flyweight we call memoing or hash consing. And some patterns are trivial in some languages but hard in others. In Haskell, forward iteration is trivial (we call it a lazy list), but it has to be manually added in Java. In C, global mutable state is trivial, but has to be manually simulated in Haskell. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
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. HSoE is great as a starting textbook. However, it just scratches the I picked this one up after learning Haskell for about 2 months. I really opened my eyes to the possibilities that functional programming offers. Seeing something in the same spirit but extended would be awesome. Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Arie Peterson schrieb: He wrote the manuscript and it was 'aus einem Guss' (casted as one). The literal meaning of aus einem Guss is cast all at once. This has overtones of it is seamless, has no internal structural bounds which may cause the final product to fracture under stress. This is one of the highest praises that you can sing for software in German, so it's not an uncommon idiom in the field over here. Regards, Jo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Ketil Malde schrieb: I generally manage to absorb just enough to get by, but I think there is a niche for a book (coupled to practical problems and complete with excercises etc) that is waiting to be filled. Agreed. Something along the lines of The Art of Functional Programming. HSoE is great as a starting textbook. However, it just scratches the surfaces - and after that, trying to grok monads keeps you occupied for a year or longer, keeping you distracted from developing other skills (such as writing and reading point-free code, or developing an intuition for curried code, or digging into a combinator library). Regards, Jo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Sebastian Sylvan wrote: Perhaps a single largish application could be the end product of the book. Like a game or something. You'd start off with some examples early on, and then as quickly as possible start working on the low level utility functions for the game, moving on to more and more complex things as the book progresses. You'd inevitably have to deal with things like performance and other real world tasks. It might be difficult to find something which would work well, though. This again reminds me of 'Write yourself a scheme in 48 hours'. It is exactly this approach, albeit on a far less ambitious level (tutorial, not book). You end up with a working scheme implementation; ok, a partial implementation missing most of the more advanced features, anyway, you get something which /really works/. I have spent quite some time adding stuff that was left out for simplicity (e.g. non-integral numbers), rewriting parts I found could be done better, added useful functionality (readline lib for input), improved the parser to be standard conform, added quasiquotation, etc. pp. Had lots of fun and learned a lot (and not only about Haskell). Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
