On 14 jun 2010, at 07:42, Aran Donohue wrote:

Hi Cafe,

I've been doing Haskell for a few months, and I've written some mid-sized programs and many small ones. I've read lots of documentation and many papers, but I'm having difficulty making the jump into some of the advanced concepts I've read about.

How do people build intuitions for things like RankNTypes and arrows? (Is the answer "Get a PhD in type theory?") Normally I learn by coding up little exercise programs, but for these I don't have good intuitions about the kinds of toy problems I ought to try to solve that would lead me to understand these tools better.

I learned my advanced stuff in two ways: 1. I followed excellent courses at Utrecht University, where they teach (among other things) advanced functional programming. 2. I just read a lot, which is a lot slower than 1. 3. By building my own programs, I inevitably find my self stuck and while searching for a solution, sometimes these concepts are the answer. For example, once I had a monadic program and I wanted to serialize/inspect the program, which turned out to be impossible in my case. The solution was to write it down using arrows (thus I had to learn arrows and also arrow-notatation). I think (for me) this is the most powerful way to learn new advanced concepts. I need practical problems to keep myself motivated.

For systems like Template Haskell and SYB, I have difficulty judging when I should use Haskell's simpler built-in semantic abstractions like functions and typeclasses and when I should look to these other mechanisms.

Sometimes Template Haskell or SYB is the answer, and it's a matter of style, but I try to avoid them as much as possible. I find that generic programming in the style of regular [1] or emgm [2] is often much simpler. Some more tips: subscribe to planet haskell, if you haven't done that already. Try to find ICFP/JFP/etc papers online that interest you. -chris [1]: http://hackage.haskell.org/package/regular [2]: http://hackage.haskell.org/package/emgm

On 14/06/10 06:42, Aran Donohue wrote:

Hi Cafe,

I've been doing Haskell for a few months, and I've written some mid-sized programs and many small ones. I've read lots of documentation and many papers, but I'm having difficulty making the jump into some of the advanced concepts I've read about.

How do people build intuitions for things like RankNTypes and arrows? (Is the answer "Get a PhD in type theory?") Normally I learn by coding up little exercise programs, but for these I don't have good intuitions about the kinds of toy problems I ought to try to solve that would lead me to understand these tools better.

For systems like Template Haskell and SYB, I have difficulty judging when I should use Haskell's simpler built-in semantic abstractions like functions and typeclasses and when I should look to these other mechanisms.

I'd second Ivan's suggestion to "learn-by-need". For SYB and Template Haskell, and probably for most other fancy abstractions, you can get on happily without them in most cases. When you start to think "there must be a better way!" while coding, that's when you should start looking for advanced features. For example, if you find yourself writing the Nth boilerplate function that pattern-matches all cases in your ADT just to apply a function in its sub-types, that's when you'll want some form of generic programming like SYB. And by that point you'll understand one of the problems that generic programming solves, which is halfway towards understanding the techniques themselves. Hope that helps, Neil.

Hi all, On Mon, Jun 14, 2010 at 1:42 AM, Aran Donohue wrote:

resources. John Lato's recent Iteratee article is a notable exception*.

Can anyone provide a link to the article (if it's available online)? Thanks, Patrick -- ===================== Patrick LeBoutillier Rosemère, Québec, Canada

On Mon, Jun 14, 2010 at 7:42 AM, Aran Donohue wrote:

Hints? Tips?

One thing that isn't mentioned yet is to read other peoples programs. I'm subscribed to the Hackage RSS feed[1]. I tend to read (at least) the package page of every package that gets uploaded to hackage. Whenever an interesting package comes a long I dig a little deeper. First I try to understand what problem the package is trying to solve. Then I see how the package is structured into modules. Finally when I notice some interesting module or function I read its documentation (which unfortunately almost never exists) and source code and try to understand how and why it is being implemented like it is. Regards, Bas [1] http://hackage.haskell.org/packages/archive/recent.rss