On Rich Hickey's "Maybe Not"

Typically, there is controversy around this talk. I thought it was interesting. I like the distinction between schema and selection. I think the idea of selecting down into a tree is promising, and it'll be interesting to see how it works out in practice.

However, had I been asked, I would have suggested some improvements based on things I've absorbed as an outsider to static typing who started with, roughly, Hickey's biases. None of them would weaken the technical point of the talk, just its positioning of the work with respect to other people's. I think that positioning is misleading.

Disclaimer: After a lot of work spent learning statically-typed functional programming in the course of writing my book, I've concluded that today I'd still recommend Clojure or Elixir over any pure[1] static language for back-end work. (See the book page for more.) I'd recommend Clojure for transforming streams of data, Elixir when maintaining runtime state or error-handling is important. So I'm not coming at this issue as a static typing advocate.

[1] I'm still ignorant of mixed FP/OO languages like F#, OCaml, ReasonML, and Scala.

So, my suggestions:

  1. I wouldn't lead off with the problem of nil. Although static FP people frequently make a big deal about nil and then introduce Maybe as a solution, that's really backward. (A historical hangover, I believe.) What's interesting to static FP people are sum types, of which Maybe is one special case that's useful for the nil problem. Yes, Kotlin handles nil better, but its mechanism is only about nil. The static FP people are going for something more general. (Maybe is something of a pain, but it should be mentioned that there are mechanisms and idioms to help with that, such as pipelining that's the moral equivalent of Clojure's some->)

  2. Similarly, Hickey notes that changing a function to now accept a "nothing here" value, or to now never return such a value, requires modifying client code in the Maybe case but not in the Kotlin or nil case. That's true, but it's presented as a technical failure when it's actually a disagreement about goals.

    Hickey is saying that the idea of "missingness" is so essential that it should be a special case built into the language runtime.

    The static FP languages are saying "no it isn't, and no it shouldn't be, because other type mechanisms handle it adequately". Why should they create a mechanism just for Maybe that wouldn't work for Either? Or Color? Or other enumerated types? And that would prevent Maybe types from participating in all the polymorphic functions you can "inherit" from "type classes" like Functor and Applicative and Foldable and Monad and Whatnot?

    It's important not to, um, "complect" an opinion about how a design meets your goals with whether the goals of its actual designers are good ones.

  3. Elm's structural typing is a static typing system that fits more naturally with Clojure than Haskell's does. (Indeed, I used Elm as the inspiration for my structural-typing Clojure library, which predated public knowledge of clojure.spec, for exactly that reason.) In Elm, you can say a function accepts any record with a String field named make, no matter what other fields it has - a big "ask" of the talk.

    So I'd recommend comparing the new clojure.spec to Elm (or PureScript). That would eliminate slides about how static typing can't do X (and all the subsequent arguments starting "Oh yes it can...") leaving more room for the things that are really special about the new clojure.spec.

Given all the above, I think my best suggestion would gave been to not to mention static typing at all. Why should anyone at a Clojure conference care about it? They already picked a dynamic language. Everything of importance could have been said by speaking only about clojure.spec.