Thanks for this...

[cscalfani]

I learned so much from your 2 Effectful articles. I wish you'd write a Haskell book :-)

Thanks again.

[sirlensalot]

You're very welcome! How long have you been working with Haskell?

I'd be interested to know what other Haskell articles you've found helpful, or if you've worked with "Haskell from first priniciples" book. Teaching haskell is always hard and would be great to find out where these articles fit in.

Cheers,
Stuart

[cscalfani]

I've been learning Haskell for the last month or so (after many half-hearted, failed attempts). Wrote in Elm for the last year and am moving to Haskell.

"Haskell from first principles" isn't a bad book but it's too verbose and takes too many tangents.

Also, they tend to present the abstraction BEFORE the concrete which leaves the student in the dark reading, sometimes pages, before understanding anything. One of my rules of teaching is that "Concrete Models are far superior to Abstract Models for students. Don't teach the Abstraction first." And they break this rule almost without exception.

I found first part of the book fine since I knew enough Haskell to skim that part. But the minute it started getting into stuff I didn't understand, I felt like I was wasting a lot of time to find the needle in each haystack.

I really got a good feeling for Monads after implementing a simple Monadic Parser from Graham Hutton's book, Programming in Haskell Second Edition. That chapter is far superior to the First Principle's section on Monadic Parsers. In fact, I read Hutton's first and still that section makes little or no sense to me. I've given up on that book.

I have the feeling that the authors were fatigued by that point and just wanted to be done with the whole thing. They even mention that they were going to start moving faster around 800 or so pages before either of them had grandchildren.

I really liked your articles because they followed another of my rules of teaching. "Never give a student a solution to a problem they don't have." You take the reader through a real world problem and create solutions along the way. So many people teach a technique without the motivation behind it.

At this point, I've just learned about Monad Transformers and am learning about Free Monads. This is a difficult subject to learn because no enough is written and what is written, as usual, is poorly written. I suspect the authors don't fully understand the subject which always translates to hand waving which loses the reader/student.

After reading your articles I wrote one on Monads of Functions which I thought would've been a good thing to grasp BEFORE your articles. I reference your articles at the bottom of the GIST.

I don't really have a huge number of articles that I've found good. My typical approach to learning is find out that something exists usually by accident or in trying to understand something else that's based on it. Then find articles. Read as much as I can understand. Then find another article and repeat. Sometimes YouTube is helpful. Sometimes not.

This process allows me to wallow in the subject even if I'm lost most of the time. Then after some unpredictable period of time, the picture starts to form. I've heard the concepts explained multiple ways. I've seen multiple implementations. Eventually, I find an article that fills in those blanks and my understanding is somewhat complete but made up of pieces from many different puzzles.

It's rare that an article can take me from start to finish. That's why I appreciated yours. I try to write that way but don't always. Here's an article on Monad Transformers that I think comes close. It reminds me of how yours was written.

Many times, I don't want to just KNOW. I want to UNDERSTAND. Many articles are just giving me a bunch of rules on how to use a library. I want to know how it works. This is why your articles and the one on Monad Transformers is so useful since the concept is explained by developing our own solutions. This is another of my rules for Teaching. "Simulate Discovery when at all possible".

No one understands a technology better than those who developed it. Just knowing how to use something isn't good enough for me. I want to know how it works and I want to know how to develop it from the ground up if I had to.

I've been programming for 36 years and can truly appreciate the difficulty people feel when trying to get into this field now that I'm trying to catch up to decades of Haskell development. It's far easier to learn something in 20 years than in months. You also have time to try out the "state of the art" solutions and when new solutions arise, you're very familiar with the downsides of the old, e.g. Monad Transformers to Free Monads.