Effective Programs: 10 Years of Clojure
I love this talk, but it does throw out a lot of complicated ideas somewhat loosely, so I get why reactions and interpretations are all over the place.<p>I think a good companion to understanding this better is Rich&#x27;s talk on &quot;The Language of the System&quot; (<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ROor6_NGIWU&amp;t=2810s" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ROor6_NGIWU&amp;t=2810s</a>).<p>I interpret his overarching thesis as this:<p>Most &quot;situated&quot; programs are in the business of processing information according to complex and changing rules, in cooperation with other programs (i.e., a system). Many languages, though, are overly-concerned with how they represent data internally: classes, algebraic types, etc. This &quot;parochialism&quot;, he calls it and &quot;concretion&quot; about how data aggregates should work, make them hard to adapt when the rules, data, or other parts of the system change, and make it hard for their programs to work in systems. At some point your Java class or Haskell ADT has to communicate its data to other programs that have no notion of these things. So you end up w&#x2F; a ton of surface area in your code with mappers and marshallers totally unrelated to the content of the data and purpose of the program.<p>The idea behind Clojure is to provide easy access to simple, safe, and relatively universal structures for holding data, and a library of functions to manipulate those structures. Its &quot;big picture&quot; design bits are about providing semantics for multiple &quot;programs&quot; (from threads to services) in a system to operate on data robustly and reasonably (concurrency semantics, time and identity models, pervasive unadorned data, etc.) At some point you&#x27;re going to be sending this program&#x27;s data over a wire to another program, and things like &quot;a map of strings and numbers&quot; is pretty straightforward to transport, while a sum type implementing functor with a record data constructor that contains a Maybe SSN is not. It overly couples the underlying data to the language&#x27;s representation.<p>The plus side of doing this is that the language can check internal consistency for you. The downside is that you&#x27;re carrying a lot of baggage that you can&#x27;t take with you over the wire anyway. Communication in systems is also why Rich thinks making &quot;names&quot; for data first class is important. Existing strongly typed languages can sort of accommodate this, but don&#x27;t really privilege names.<p>So I think a lot of strong typing advocates are upset because they think Rich is saying types don&#x27;t have value within programs. I don&#x27;t think that&#x27;s right. I think he&#x27;s saying they have very limited value in <i>open</i> systems, which makes their costs often overwhelm their benefits in the individual programs within those systems.<p>In general, I feel like the debate has been about examining Rich&#x27;s claims in the context of programs (is Maybe String good or bad, etc.), whereas he&#x27;s really interested in what works in systems. I think that&#x27;s indicated by his focus on the term &quot;parochialism&quot; which I have not seen a lot of folks address.