• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

LispCast

Making the world safe for Functional Programming

  • Hire Eric
  • Podcast
  • Essays
  • About

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

Eric Normand · Updated September 23, 2019

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.






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

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



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.

Eric Normand profile image

Eric Normand
@ericnormand
twitter logo

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.

ed.gr/zu73

Mon Nov 26 20:01:43 +0000 2018
Twitter reply actionTwitter retweet action1Twitter like action5

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.

Eric Normand profile image

Eric Normand
@ericnormand
twitter logo

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.

ed.gr/zu75

Sun Sep 09 15:01:56 +0000 2018
Twitter reply actionTwitter retweet action0Twitter like action1

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.

Eric Normand profile image

Eric Normand
@ericnormand
twitter logo

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.

ed.gr/zu77

Fri Sep 07 19:03:07 +0000 2018
Twitter reply actionTwitter retweet action1Twitter like action9

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.

Eric Normand profile image

Eric Normand
@ericnormand
twitter logo

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. Then you put them together in combinations.

ed.gr/zu78

Fri Sep 07 15:01:43 +0000 2018
Twitter reply actionTwitter retweet action3Twitter like action10

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, eric@lispcast.com. See you later.

Published August 27, 2018 · Filed Under: Thoughts on Functional Programming Podcast by Eric Normand ·

Eric Normand

Eric Normand is an experienced functional programmer, trainer, speaker, writer, and consultant on all things FP. He started writing Lisp in 2000 and is now a Clojure expert, producing the most comprehensive suite of Clojure training material at PurelyFunctional.tv. He has a popular Clojure newsletter and blog. He also consults with companies to use functional programming to better serve business objectives. You can find him speaking internationally at programming conferences.

Related Posts

  • Computing Then and Now
    In this episode, we read excerpts of Maurice Wilke's 19...
    Read more
  • The Synthesis of Algorithmic Systems
    In this episode, I read excerpts from Alan Perlis's Tur...
    Read more
  • Is Clojure a language for hipsters?
    In this episode, I contemplate whether I am an early ad...
    Read more
  • Lambda: The Ultimate GOTO
    In this episode, I read from Lambda: The Ultimate GOTO....
    Read more

 

Receive a weekly email to inspire functional programmers.

Subscribe for Free

Primary Sidebar

Please leave a review on iTunes.

Subscribe

RSS
iTunes
Google Play
Overcast

PROFESSIONAL SERVICES

                  Hire Eric

  • Speaking
  • Consulting
  • Training

KEEP IN TOUCH WITH ERIC NORMAND

  • Email
  • GitHub
  • LinkedIn
  • Phone
  • RSS
  • Twitter
  • YouTube

Footer

  • Email
  • GitHub
  • LinkedIn
  • Phone
  • RSS
  • Twitter
  • YouTube

Professional Services

  • Speaking
  • Consulting
  • Training

Content

  • Essays
  • Podcast
  • Presentations

Copyright © 2021 Eric Normand