[DanielBMarkham]

This was good. Thank you.

The part that most worried me was If we look at the history of programming, there are many portents of the future of Haskell in the C++ community, another language where no two developers (that I’ve met) agree on which subset of the language to use.

I also perked up when he talked about the difference between pipeline-paradigm coding and coding involving monadic trees.

I'd love to dive into the language, but with F# I'm happy enough that I code as little as possible and create lots of value. While I think that would be even more true in Haskell, it doesn't seem worth the switch -- yet.

Having said that, I'm definitely seeing some parallels between my own experience in F# and this author's experience in Haskell, especially the part about multiple ways to solve a problem. Are there no good books about common FP best practices? Seems like much of what you would consider a "best practice" would apply whether it's F#, OCAML, or Haskell.

[mbrock]

There might be good such books, I wouldn't really know. The Scheme-oriented How to Design Programs seems like a good candidate.

I think the Haskell world would benefit from talking a bit more about "design patterns." I've seen the concept get a fair bit of abuse because of the claim that Haskell's abstraction facilities are good enough to eliminate the need for Visitor Pattern style boilerplate—which has truth to it, but loses the baby with the bathwater.

Design patterns as in "common ways to structure programs and parts of programs" are fundamental for people who are learning to program productively. They constitute the repertoire of coding on the level above syntax. They're the principal structures of the idiomatic lexicon. The good ones seem obvious once you understand them, but a poor grasp of them causes vague confusion and big missteps.

In Haskell (and pure FP in general), there are a lot of useful design patterns that beginners pick up from the ambient culture if they're lucky:

  - the reader/state/IO monad transformer stack;
  - domain values as algebraic structures e.g. monoids;
  - functor composition;
  - free monad interpreters;
  - Xmonad-style pure core with I/O wrapper;
  - explicit ID values for representing identity;
  - recursion schemes;
  - and so on and so on.

Sure, Haskell can represent a lot of these things as formal abstractions, and that's wonderful—but people still need to learn when and how to use them and adapt them for their domains.

What I'm describing is far from a Haskell-specific problem, actually—there aren't that many resources in general that focus on these kinds of patterns.

When I was a beginner programmer, I was lucky to find Ward Cunningham's original wiki, the Portland Pattern Repository, which was all about spreading and discussing this kind of cultural conceptual knowledge.

There was a strong humanistic influence (from Christopher Alexander, through the early agile movement before it became a high-octane consultancy buzzword) and Haskell's culture has more DNA from mathematics and logic, and so treats patterns differently...

Still, I would love to see more discussion about functional patterns, at all scales from function implementation to application architecture.

[tamana]

Yes. People say "patterns are just first-class functions"but they miss the point that not all functions can be combined with each other in manageable ways, so there is still an art to it.

Also, stuff like "strictness annotation" is not a function.

[tome]

> Also, stuff like "strictness annotation" is not a function.

Ah but it should be :)

[Not a function actually, but a type constructor: http://h2.jaguarpaw.co.uk/posts/strictness-in-types/]