1. 15

  2. 19

    I was expecting to read a war story about a nightmarish memory corruption bug brought on by C or C++, or—acknowledging the possibility that the author might just be using “weak typing” as a derogatory term for dynamic typing—about either a nightmarish bug in their Ruby code or a sort of generalized slowdown and unpredictable problems in their development process due to dynamic typing. Indeed, the article starts out promising just that:

    it has become abundantly clear that the neglect and misuse of type-systems has had a sharply negative impact on our codebases

    However, in the following three thousand words of polemic, there is nothing at all to support this assertion, and indeed nothing more than a bunch of vague advocacy about how the author’s favorite way of programming is the One True Way.

    If you’ve already written code in a Hindley-Milner language and a dynamically-typed language, you will learn nothing from reading this essay except for psychological facts about the author.

    1. 10

      I do say that we should Hindley-Milner all of the things. This should be a driving meme for us.

      1. 7


        x: σ ∈ Γ

        Γ ⊢ x: σ


        1. 9

          That has such a nice ring to it, I can totally hear the picket line chanting it now “variable x has type sigma in the context so the context proves x has type sigma”. “All for x, for all x!”

    2. 1

      This article strikes me as a contrary indicator, like the hype about duck typing a few years ago.

      Implementing a precise type signature proves that the software does what it says on the tin.

      No. Typing constrains, but does not determine, semantics. And typing is orthogonal to implementation, which is all about keeping the promises on the tin.

      Names are totally useless for reasoning about software.

      That may be persuasive, if you are the sort who rejects all code documentation, but it assumes that you’ve already banned dynamic binding. So the argument circles back on itself.

      Programmers fall victim to reductionism, usually in cycles. This should not distract us from the real, but incremental, gains of languages like Scala and Haskell.