Something I missed in Rich Hickey's last keynote (Clojure/conj 2017)

I wrote my interpretation of Rich Hickey's keynote. I called it "Clojure vs the Static Typing World". However, I missed something very big. I missed that he talked about how common it was to have lots of sub-solutions and partial data. I expand on that idea here.

Transcript

Eric Normand: There was one thing I missed in Rich Hickey's most recent keynote that I want to talk about today. Hi, my name is Eric Normand. These are my thoughts on functional programming.

In 2017, at the Clojure Conj, Rich Hickey gave a talk called Effective Programs. Mostly, it was explaining the design decisions behind Clojure, what problems he was trying to solve, and the decisions that he didn't even realize he was making until 10 years in, just being able to reflect on what he was doing at the time.

It had to do with these programs that have to react to stuff happening in the world and make decisions in the world. Also, be changing over time as the world changes over time. There's all this motion. Everything's changing. Clojure was designed to address this.

The talk needed a little bit of context

In the talk, there was something I missed. I wrote a response. In the presentation, there was a lot of talk about static types and how they weren't helping with that particular problem. They were great if you had a static problem. You wanted to model it in a type-safe way. You could do that.

When you have this idea of the world is changing, your program has to adapt. The code has to change. You have this timeline of your types changing over time. There isn't a model of that. Anyway, he brought up types a lot. I wrote an article with my interpretations of it. A lot of it was oblique. It wasn't the topic of the talk. This was tangential to it.

I felt like the talk needed a little bit of context. Now, I don't know if I did a great job of adding any context to it. It only deepened the divide between static and dynamic types, which was not my intention.

We need to be more unified

My intention was to share my personal experience working in Haskell comparing it to how I felt working in Clojure. Why I thought some of the statements he made made a lot of sense to me on a personal, experiential level, not any objective level or anything.

https://twitter.com/ericnormand/status/1067146401568747520

Anyway, the response I got for my article was people who liked Clojure and dynamic types liked my article. People who liked static types had a lot of objection. I don't think it clarified anything. I haven't found the key yet. I think that we are too divided. We need to be more unified.

I re-watched the talk recently. I actually missed a lot of stuff. I think I'd seen it live. Then I watched it one time after that before I wrote my article just as research to make sure I was remembering stuff correctly. Then I re-watched it recently. There was something I missed. Something very important that I didn't pick up on.

sub-problems

It was that when you're working on a problem, there's often a lot of sub-problems. You have a partially solved problem. You're halfway through the steps that will finally solve the problem. You're only halfway. You have a partial solution. You have say, partial data. You haven't finished making the data yet.

https://twitter.com/ericnormand/status/1038804703927324673?ref_src=twsrc%5Etfw

You can't use the type that you will eventually have at the end, which contains the entire solution. What you have is a piece of that. What piece is it? You want the flexibility to be able to choose the piece that you want. Are you going to make a new type for that half solution?

This is something he brings up where you say a person has a name, it has an address, it has an employee status, and a salary. It has all these things. As a whole, that makes sense. Very often, all you have is the first name and the employee status.

why Spec is the way it is

You're in some part of the code that only needs those two things. Are you going to make a new type just for that piece? What do you even call that type? Then another part needs the first name and the address because it's going to mail them something. They're going to need this other piece. You need to name that type.

He was using this as an example of one of the reasons why Spec is the way it is. In Spec you define what the keys mean independent of what day the structure they are in. Person/first name is always going to be a string with certain characteristics, however you define it in Spec, regardless of what else is around it.

That lets you put the pieces together as you need them in a way that they might not even be a part of this bigger entity. They're a part of some sub-entity or some other thing. How do you join them? You have the whole set library, Clojure.set, that contains all these relational algebra things. Is there a type for each join? For each kind of join to do?

A data model is an abstraction

This is what he was talking about. That you need a data model. Not just a bunch of concrete types. A data model is an abstraction. Concrete types like a person has a first name that's a string. It has a last name that's a string, an address that's an address type that has a street, a number, and a zip code. Those are concretions, not abstractions.

https://twitter.com/ericnormand/status/1038140627354087430?ref_src=twsrc%5Etfw

You need a program to have abstractions. That's been clear for a long time. That's something I missed. It's true in type languages you have this problem where the solution always seems to be more types. You need more types.

When you look at the recommended stuff...I don't know, maybe it's an extreme faction of Haskellers. They say, "We can't use strings except at the bottom. We always wrap them in a type. We know what that string represents. That's where you need to go."

In the same way that you would say person/first name is a string. It's not empty. I don't know what you would say for a first name. It seems like you don't want to restrict that too much.

We're speccing every key

Instead of using strings, you would want to define a first name type, a last name type, an address type, and a zip code type. Everything would be typed in the way that we're now starting to do with Spec. We're speccing every key. Then you get to put them together in combinations.

https://twitter.com/ericnormand/status/1038079876367040512?ref_src=twsrc%5Etfw

Anyway, that was something that I'd missed the first time. I just wanted to talk about it. All right. Thank you so much.

If you want to get in touch with me, I want to hear your thoughts on this, especially on my article. I would love to have a very clear treatise on it. I don't know if one article could ever do it. It's just a complex issue. I don't even want to talk about the issue. It's something for another episode.

If you have complaints about my article, I really want to hear them. I want to know. This article is called "Clojure vs. the Static Typing World." I want to know what could make this article stronger, what are your objections to it. This is important to me. I think that we're too divided. I'm sitting there on the inside. I'm like, "What's unclear?" To me, it's clear that we're too divided.

When I make a statement, I'm not meaning to divide us more. I'm just not able to express it. I just want some help here. I want to know what's going on. Please, I'm @ericnormand on Twitter. You can also email me. See you later.