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 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.
 I'm still ignorant of mixed FP/OO languages like F#, OCaml, ReasonML, and Scala.
So, my suggestions:
I wouldn't lead off with the problem of
nil. Although static FP people frequently make a big deal about
niland then introduce
Maybeas a solution, that's really backward. (A historical hangover, I believe.) What's interesting to static FP people are sum types, of which
Maybeis one special case that's useful for the
nilproblem. Yes, Kotlin handles
nilbetter, but its mechanism is only about
nil. The static FP people are going for something more general. (
Maybeis 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
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
Maybecase but not in the Kotlin or
nilcase. 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
Maybethat wouldn't work for
Color? Or other enumerated types? And that would prevent
Maybetypes from participating in all the polymorphic functions you can "inherit" from "type classes" like
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.
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
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.