Saturday, 14 January 2017

Expressive types, not oppressive types

Uncle Bob wrote a recent post in which he warns programmers against the "dark path" some modern languages have taken - that is to "double down" on static typing. He cites Swift and Kotlin as examples, though his argument is meant to be interpreted more generally.
I share many points of view in common with Uncle Bob. I find the dynamically typed Clojure programming language beautiful and expressive - most of my personal projects are written in Clojure. I think that TDD (test-driven design) is a valuable and important discipline - I work for an agile consulting company where most of our projects include helping clients to get better at testing.

But I disagree strongly with the way Uncle Bob frames this discussion on static types.

Uncle Bob looks at advanced type systems and sees them as more oppressive rather than more expressive. Being able to describe whether or not a function can return null is an opportunity, not a constraint. Being able to use types to describe your code's intent is an opportunity, not a constraint. Being able to reason about the behaviour of a function based on its type signature is an opportunity, not a constraint.
The kicker is that this is almost exactly the fallacy about TDD that we have railed against for years. We call it "test-driven design" because we know that evolving code in response to examples is a great way to inform a design. Folks who have not learnt to listen to their unit tests see them as nagging constraints that prevents them from writing code in the way they'd like. A master of TDD uses tests as feedback for their design.

Anyone who sees unit test as mere "checks" that make changing code needlessly difficult isn't getting the most out of test-driven design. Anyone who sees static types as mere "checks" that make changing code needlessly difficult isn't getting the most out of type-driven design.
Based on his post Uncle Bob falls into the latter category. He sees types as ad hoc antidotes for specific mistakes rather than tools for thought - "Every time there’s a new kind of bug, we add a language feature to prevent that kind of bug."
If that's Uncle Bob's experience of Swift and Kotlin, he should try Elm. Or F#. Or Haskell. If his experience is anything like mine, he would find that more sophisticated types lead to less ad hockery, not more.

In a follow-up post, Uncle Bob is explicit about what he wants in a programming language - "There is a balance point after which every step down The Dark Path increases the cost over the benefit. I think Java and C# have done a reasonable job at hovering near the balance point."
I couldn't disagree more. Java and C# have two of the most onerous and least beneficial type systems. Their complexity and absence of type inference force excessive bookkeeping on the programmer. They lack of basic features like sum types, which denies the programmer an important expressive idiom.
Java and C# represent the nadir of the type system trade-off, not the zenith. Type systems are tools. Better tools help us write better code. We should welcome each and every advance in the tools we use to do our job, because frankly we could do a lot better than what we have now.

To argue that employing more expressive types is a "dark path" that leads developers away from personal responsibility isn't accurate or helpful.

8 comments:

  1. Why do you say C# lacks of type inference? It supports years ago. And by the way, don't say thing like "Java and C# " anymore since they are completely different now, they are just similar in the key C/C++ syntax.

    ReplyDelete
    Replies
    1. Java and C# are still quite similar, paradigm-wise. Garbage-collected, object-oriented, class-based, simple polymorphism, managed runtime. When talking about the type systems you can consider them to be one and the same.

      Delete
    2. Once you learn Haskell, you find out that C# doesn't have anything like type inference.

      Delete
  2. Try F# and you'll see what real type inference is on .Net

    C#'s inference at the level of a single expression is a toy in comparison.

    ReplyDelete
  3. I agree with you. I've read similar responses to Uncle Bob's post:

    http://blog.zdsmith.com/posts/the-dark-path-or-what-if-i-dont-want-to-quit-my-job.html

    And frankly it strikes me very strangely to have such a strong opinion about the badness of types. I certainly like to have control over how strict I want my compiler/interpreter to be with me, but I really like using types to be expressive about my intent.

    ReplyDelete
  4. It is really a great work and the way in which u r sharing the knowledge is excellent.And i hope this will be useful for many people.Again thank you so much for this article.
    java training center in chennai |
    best java institute in chennai

    ReplyDelete

  5. very useful info, and please keep updating........
    Best Online Software Training

    ReplyDelete
  6. Hi, Great.. Tutorial is just awesome..It is really helpful for a newbie like me.. I am a regular follower of your blog. Really very informative post you shared here. Kindly keep blogging. If anyone wants to become a Java developer learn from Java Training in Chennai. or learn thru Java Online Training India . Nowadays Java has tons of job opportunities on various vertical industry.

    ReplyDelete