Dynamic type systems are not inherently more open
Six notable things I took away from this post:<p>- Structural typing, i.e. instead of &quot;you eagerly write a schema for the whole universe&quot;, just limit to what you need (basically, encode only the same kinds of assumptions you would make in a dynamically-typed language).<p>- <i>It’s easy to discover the assumptions of the Haskell program [...] In the dynamically-typed program, we’d have to audit every code path</i> — Left implicit in many debates about these topics are the &quot;weights&quot; that one attaches to these things, the importance and frequency of attempting such activities. Surely they vary, depending on everything from the application (Is it &quot;code once and throw it away&quot;, or does it need to be maintained when the original programmers have left?) and down to the individual programmer&#x27;s approach to life (What is the cost of an error: how bad would it be to have a bug? Etc).<p>- <i>&quot;This is a case of improper data modeling, but the static type system is not at fault—it has simply been misused.&quot;</i> — To me this shows that bugs can exist in either the data modeling or the code: in a dynamically-typed language the two tend to coincide (with much less of the former) and in a statically-typed language they tend to be separate. (Is this good or bad? On the one hand you can think about them separately, on the other hand you have to look for bugs in two places &#x2F; switch between two modes of thought, but then again maybe you need to do that anyway?)<p>- Structural versus nominal typing, where the latter involves giving a name to each new type (<i>&quot;If you wish to take a subselection of a struct’s fields, you must define an entirely new struct; doing this often creates an explosion of awkward boilerplate&quot;</i>).<p>- <i>&quot;consider Python classes, which are quite nominal despite being dynamic, and TypeScript interfaces, which are structural despite being static.&quot;</i> — This is highly illuminating, and just this bit (and the next) elaborated with some examples would make for a useful blog post on its own.<p>- <i>&quot;If you are interested in exploring static type systems with strong support for structural typing, I would recommend taking a look at any of TypeScript, Flow, PureScript, Elm, OCaml, or Reason [...] What I would</i> not <i>recommend for this purpose is Haskell, which [is] aggressively nominal&quot;</i><p>For what it&#x27;s worth, my opinion is that posts like this, on hotly debated topics, would do well to start with concrete examples and be written in the mode of conveying interesting information&#x2F;ideas (of which there are a lot here) rather than being phrased as an argument for some position, which seems to elicit different sorts of responses — already most of the HN comments here are about static versus dynamic type systems in general, rather than about any specific ideas advanced by this post.