It's not an introduction, but this page collects a lot of nice info for Haskell: http://dev.stephendiehl.com/hask/ http://dev.stephendiehl.com/hask/ As for "b

It's not an introduction, but this page collects a lot of nice info for Haskell: http://dev.stephendiehl.com/hask/ http://dev.stephendiehl.com/hask/ As for "best practices", there are some interesting answers on http://stackoverflow.com/questions/842026/principles-best-practices-and-design-patterns-for-functional-programming http://stackoverflow.com/questions/842026/principles-best-pr... There certainly aren't as many 'design patterns' style things in functional programming as there are in OO. In general, it seems to be because: - FP systems are much smaller than OO systems (due to conciseness and not as much large-scale use) - FP favours immutability over encapsulation, so you can re-use existing map/fold/filter/etc. functions rather than having to rewrite them in small pieces spread throughout your app. Hence you don't need to decide how they're implemented. - Pure functions take everything in via arguments and give everything out via return values. There aren't many ways to get that wrong. In OO any method can affect the application in all kinds of ways, so there are all kinds of ways to get it wrong, requiring best-practices to avoid them. - In FP, we're generally turning some input into some output. If we're writing code that doesn't seem to get anything from our input closer to something in our output, we should stop and think for a minute. In OO we're encouraged not to think in terms of solving a problem: instead we try to define ontologies and hierarchies, implement models of the domain, etc. only then, once we've bootstrapped a simulation of our business entities and their interactions, do we write the actual code for the problem we have: `Order::newFromFile('input.csv').ship()`