This is a summary of the defn podcast interview with Zach Tellman.
It was a wonderful 30th episode of the defn podcast where they interviewed Zach Tellman. As is so often the case with Zach’s talks, it’s a great discussion full of insights.
I usually take personal notes for many podcasts that I listen to (see Busy (Clojure) Developer Guide to Podcasts). The reasons are to help me remember more and sometimes be able to do a quick review without a need to re-listen the whole thing.
Most of the podcasts that I listen to have only very brief show notes. And it’s very true for defn podcast too. Therefore, I decided to put together a somewhat longer version. Beware that these are my own interpretations and because I wrote them down while walking and listening they may also be slightly incorrect. I encourage you to listen to the whole episode, take your own notes and draw your conclusions.
You can also expect more podcasts' summaries on this blog in the future.
This is Zach’s new self-published book that has already been available for some time.
There’s also a discussion forum dedicated to the book.
He started the first serious work on this topic two years ago.
He didn’t anticipate how much work it would be and spent a lot of time reading many resources on the topic.
Lot of code we (programmers) write is a *throw-away code*
More frequent in LISP community.
It’s okay many times.
Writing reusable code is hard.
Correctness & proofs
1972 paper: Proof of correctness of data representations
People should stop talking about software being correct and talk about software being *self-consistent.*
The hardest problem is to write software that’s useful when it’s outside of its usual environment.
Dynamic vs. static typing
Having some dynamism at the edges of your system is useful.
The real world doesn’t have schemas.
Clojure’s unique feature is that it brings immutability into the ecosystem of dynamic languages.
Clojure is a very good language for writing glue between more "rigid" components in your system. Those components might be written in other, more static languages (often in the form of Java library used directly from Clojure).
One thing that Zach considers less than ideal in Clojure is that you can end up with *nil* propagating through half of the code only to eventually fail with NPE
The usual idiom (when fn-arg (do stuff)) is terrible
A lot of things in Clojure are designed to be concise. In some situations, it could be better to be explicit: e.g., requiring a default value for clojure.core/get
Clojure concurrency features
Why STM hasn’t been as successful as expected
STM makes things much more complicated (compared to a simple atom) while it gives us only small benefits (mostly under heavy contention).
We usually don’t write systems with that heavy concurrency - we instead scale them by distributing load over multiple machines.
core.async is mostly useful on the client side (ClojureScript)
People often use it on the server side even if there’s no compelling reason to do so.
It can be tricky because there’s no clear distinction between data in the process and outside the process (file, network, etc.)
Here’s further discussion about push & pull concepts: Question: Not able to understand function pull, push and transform
If Rich had known about transducers before Clojure 1.0 release, he would have made the laziness much less a default option in Clojure.
Venture capitalists aim at billion dollar businesses which is problematic for developer tools like Light Table - it’s a pretty decent editor but it’s not clear how much money this area can bring to investors
Light Table is a nice demonstration of Bret Victor’s ideas
The great aspect of American culture is that it allows you to fail in your business => it encourages experimentation.
He studied computer science at college.
He originally wanted to do games development, but later realized that it’s not for him.
He spent some time at C# shop - working on low-level Windows graphics stuff.
He joined Google for a short period of time
Eventually, he started working for Clojure startup and has been with Clojure ever since
Spec is perhaps the first addition to Clojure in the last five years that can really change the way how programmers think about the language.
Spec error reporting is rather weak, though
Cognitect’s approach to leave this as an exercise to a reader is less than ideal.
Spec is a clever technical solution to what is a fundamentally human problem.
To have a really good human-readable error messages you’d have to have a possibility to specify error message generator with every spec.
Mean-time-to-accomplish-something is an important criterion for new people starting with a programming language
For Zach, Clojure has been great in this aspect because it allowed him to do rapid experiments with OpenGL library
Community has to step in