Clojure Gazette 193: Where are the good FP books?
Where are the good FP books?
Issue 193 - October 3, 2016
Hello, functional programmers,
Have you ever heard of the book Refactoring by Martin Fowler? How about the book called Design Patterns by the "Gang of Four"? The question I'd like to explore is what a similar book about functional programming might look like.
The reason I picked those two is that they define concepts for the software engineering industry and they catalog those concepts. Refactoring didn't invent refactoring, but it did introduce the concept to the software engineering world. Now it is a common word. The same is true of Design Patterns. By defining a process and catologuing its instances, they make object-oriented programming easier to talk about. Thought processes, ideas, and perceptions are named, and so a discourse is opened.
What functional programming is missing is a discourse about how we design and write programs. We talk about types and recursion and function calls. Those are the bricks and mortar of our languages. But what I've seen beginners stumped by again and again is how to decide where to build the brick wall. How do we bring someone from brick layer to architect?
Object-oriented programming has a process. It's not great---actually, it's a bag of lies ---but it's good enough to get people started. The process I'm talking about is "underline all of the nouns in the problem description and make a class for each. Then underline the verbs and make a method for each." Not a great process, but here we are talking about it . I can't even begin talking about how to start a functional program.
Even though I don't like the noun-verb process, there's something about it that makes it usable: it's mechanical. I'm not sure bout this (I don't know how to research it), but I would guess that this process originated in schools where teachers were trying to teach OO for the first time. When you're trying to teach an absolute beginner something, you need something concrete and familiar to start with. So you rely on their knowledge of nouns and verbs from primary school and Boom! they can start writing code. Then you can elaborate on it later. "Some verbs are queries, som are commands," etc.
Interestingly, a pattern like MVC has some of the same benefits. You can look at any bit of code and decide whether it belongs in a model, a view, or a controller. That one decision does half the work for you. And it's very mechanical.
I want to find or create these processes for functional programming. I've been exploring a candidate process called Denotational Design and it's practiced by Conal Elliot. It's an application of Christopher Strachey's Denotational Semantics (which is about the meaning of programming languages) to the meaning of abstractions. It's a great process in that it produces great functional code. It has been described in papers and in several talks by Conal Elliot. And he's very active in discussions about it online. But the process has not been elaborated in the way a teacher would like in order to teach it to beginners. I'm in the process of doing that, and it's going well.
I've submitted a talk proposal for Clojure/conj about my interpretation of Denotational Design. The way the talk is turning out, it's been influenced by the works of Conal Elliot, John Hughes (a student of Strachey's), Gerald Sussman, and Alan Kay. It's feeling epic.
I'll talk more about the process and the talk in future issues. I hope to make it something we can all learn, and---more importantly---discuss critically.
Rock on!
PurelyFunctional.tv is the best place to learn functional programming. At least that's what I'm trying to make it. And I need your help! I need other teachers who want to share the great ideas of the past 50 years of programming and get paid to do it. If you're interested, please watch the invitation video .
