Defn Podcast Episode 30 – Zach Tellman

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.

Show notes

  • Elements of Clojure
    • 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).
  • nil handling
    • 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.
  • Laziness
    • It can be tricky because there’s no clear distinction between data in the process and outside the process (file, network, etc.)
    • If Rich had known about transducers before Clojure 1.0 release, he would have made the laziness much less a default option in Clojure.
  • Light Table
    • 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.
  • Zach’s history
    • 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
  • Zach’s successful open-source projects: Aleph and Manifold
  • Spec
    • 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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.