In Retrospect: QCon NYC 2013 (and a conversation with Rich Hickey on languages)

QCon NYC was the most refreshing conference I’ve been to in a very long time. Perhaps it’s partially because I’ve lingered too long in Microsoft circles, or maybe it’s just been too long since I went to a large conference. In any case, the speaker lineup was just chock full of brilliant minds from all over the world. I am honored to be counted among such an illustrious lineup.

Click for a video recording of the talk.

Click for a video recording of my talk.

My talk was well received, but the title wasn’t as descriptive of the content as I would have liked. It’s quite a challenge titling a talk six months in advance. Perhaps I should have called it something like “One language to rule them all”, or “Language de jour” but I’m not sure either of those would have gone over quite as well on the polyglot track.

Runar, Rich, and Rick

Left to right: Runar, Rick and Rich.
Paul Snively is behind the camera.

While the average quality of the talks was far and above what I’m used to at most of the conference I’ve attended, both in entertainment value and content, as usual the interspersed deep conversations were far and away the most rewarding. Of all of those deep conversations the one that stands out most in my mind was when Rich Hickey sat down with Runar Bjarnesson, Paul Snively and I for dinner. We talked quite a bit about his Datomic project, agreed on the power of immutability, and eventually discussed our differing philosophies on types.

I have immense respect for Rich Hickey. He’s a brilliant man and is almost solely responsible for kindling my interest in functional programming. He’s had a huge influence in creating the programmer that I am today, and I count him among my heroes. Now, the only case I’ve ever found myself disagreeing with him is his opinion on types and so I couldn’t help myself. With a bit of trepidation, I broached the subject. It’s funny that something so technical can be so difficult to talk about, but because we are all so passionate about our viewpoints I know we all had to be quite careful to phrase things so as not to inflame the tension.

What I learned is that Rich Hickey and I don’t disagree nearly as much as I thought. His main point was that the glue of a program shouldn’t know anything about what it’s gluing, much like a Fedex truck wasn’t designed with the contents of the boxes it carries in mind. I also tend to design programs in this way, but lean heavily on reflection to do it instead of using a dynamic language.

Even a month later, Runar’s main point of contention still seems unanswered: do generic types count as the truck being designed with the contents of the box in mind? You can argue either way here. On one hand, the code certainly knows about some of the properties of what’s in the box (for example, does it fit on the truck?), how tightly these properties constrain depends quite a bit on the language in question and its type features of course. This is actually quite useful because it keeps you from attempting to do something like putting a steamboat into your Fedex truck. The properties of the Fedex truck and the boxes it can hold must be respected.

On the other hand, you may often find yourself in a situation where your abstraction is overly limiting and the only recourse is to make changes to the type structure of the existing program in order to extend it. I think this is what Rich was getting at, and it’s true. For a true decoupled program (that is, no extra shared dependencies between sub-components) you need one of three things: 1) a meta reflection layer, 2) a dynamic language or 3) a very liberally defined type structure. In the third case it’s just extra work, with perhaps a negligible tangible benefit in terms of program safety.

In either case, the post-compilation/interpretation program eventually knows what’s in the box, it’s more of a question of when: at compile time, or when the box is first touched. Perhaps this is where the metaphor breaks down, or perhaps I’m just over thinking it. In any case it’s been a while since I reevaluated my hard-line views on types, and I’m grateful to Rich for sitting down with us and providing the impetus. After all, in my own words right from my QCon talk, it’s all about context.

Enjoy this post? Continue the conversation with me on twitter.

Tags: , , , , , ,


  1. Vasily Kirichenko

    What’s the benefits in making a program “true decoupled”? I find the clojure way of passing maps everywhere is just too dynamic to be maintainable.

    • It seems to me that the primary benefit is in fixing/swapping out components on the fly without recompilation/restarting the entire system.

      • And a big reason to want that is during development. Clojure is highly REPL focused, and especially wants that to work without ever restarting the system — you attach REPLs to running services all of the time.

        If you don’t like maps, there is a really good protocol system, which completely maps to my idea of what OO is about. Really miss it in the languages I actually use.

        • You can write F# very similarly with the REPL and fsx files, and I often so. The downside is if you change one early dependency you need to re-evaluate everything that depends on it. I see the appeal here.

  2. Arturo Hernandez

    Maybe, I don’t understand it. But I’m not sure the truck is the right analogy. Because clojure is typed after all. I do like clojure a lot, I also think Rick did a great job.

    There are clear use cases for both approaches. OS components that need to be secure, are likely easier to make secure by using a static type system. A domain were rapid innovation is more important than correctness, may benefit from dynamic types.

    Is there value in having a more general purpose language that allows for both use cases in a controlled fashion? I think part of the answer lies in how often do we cross that boundary within organizations? That may be a difficult question to answer.

    The other way to look at it is from the programmer perspective. Would I want to have to switch languages in order to get the benefits of each approach? I personally don’t even like having to switch from server to client.

    Then the idea of plug-able type systems starts to make sense to me.

  3. […] Richard Minerich blogged “In Retrospect: QCon NYC 2013 (and a conversation with Rich Hickey on languages)“. […]

Leave a comment