I’m always curious about how people think, and these days I’m most interested in how functional programmers think about programming problems. Along those lines I found a good blog post (tutorial) titled, “Thinking Functionally with Haskell”, and these are my notes from that post:
- FP is all about data. Put data first.
- “Most of it is about deciding which data structures you need, then coding up various transformations”
- The Unix pipes example shows how we think in data, and massage that data with small, good, tools. Data in, massage the data, data out.
zip, think of zippers in clothes; the zipper merges the two elements/streams.
- Creating data types is important. (Like OOP developers build classes.)
- In Haskell, “it’s very quick and easy to add the data type that fits your problem domain well.”
- With pattern matching you don’t need
ifstatements so much.
- When we have a collection of things to process, most of the transformations fall into two main patterns: mapping and folding.
- Mapping is about applying the same operation to everything in a collection, but keeping the shape the same.
- Folding: “Another way to think of folding is to replace the ’nodes’ of some data structure with functions (or constants)”; “collapsing or folding the data into a different type”,
- “The dot deserves special mention. It is functional composition in Haskell, and basically means joining the output of one function to the input of another, so forming a bigger function.” (Sounds like a Unix pipe, or method chaining.)
- “deforestation” - FP compilers optimize away some of the intermediate data structures in a chain of functions and so save on memory and time.
The Haskell notation for the types looks like this:
A -> B
indicating a conversion from some type
A to some other type
B. Tests on color values will have type:
RGB -> Bool
or determining the max of two colours will look like this:
RGB -> RGB -> RGB