Dynamic type systems are not inherently more open

This is so predictable.

1. Author attacks premise of dynamic type systems argument.

2. Author presents premise for static type system (which is practically confluent/equivalent/equifinal to premise he just undermined).

>static type systems allow specifying exactly how much a component needs to know about the structure of its inputs, and conversely, how much it doesn’t. Indeed, in practice static type systems excel at processing data with only a partially-known structure, as they can be used to ensure application logic doesn’t accidentally assume too much.

Chances are you are wrong about 'how much you need to know' irrespective of your type system. Nobody gets it right the first time.

When we figure out that we were wrong about how much we need to know about the structure of our inputs (e.g we assumed too little) we do this thing we call... "extending our code" [1].

The question then is simply: which type-system is better at extensibility?

And I have no idea how to define "better".

[1] https://en.wikipedia.org/wiki/Extensibility

It's called a data type. Dynamic typing is not a type system at all, it's the lack of one. And no, it's not a type system because you're typing it (to any node developers out there).

Ok, but this works just fine in Haskell. If you have a well-formed JSON string and you want to parse it as a generic value, you can parse it into the Value type. If you have a typed record (something less general than a Value) and a JSON string that has enough of the structure to be parsed into that typed record, you can parse it into that typed record. If the JSON string has extra structure/data/fields your parser didn't expect, it's fine. Your JSON parser in Haskell can ignore those extra things. Just like any dynamic language.

All of this was demonstrated in the article.

This is so predictable.

1. HN commenter misses the point of the article.

2. HN commenter even misgenders the article's author.

Six notable things I took away from this post:

- Structural typing, i.e. instead of "you eagerly write a schema for the whole universe", just limit to what you need (basically, encode only the same kinds of assumptions you would make in a dynamically-typed language).

- It’s easy to discover the assumptions of the Haskell program [...] In the dynamically-typed program, we’d have to audit every code path — Left implicit in many debates about these topics are the "weights" 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 "code once and throw it away", or does it need to be maintained when the original programmers have left?) and down to the individual programmer's approach to life (What is the cost of an error: how bad would it be to have a bug? Etc).

- "This is a case of improper data modeling, but the static type system is not at fault—it has simply been misused." — 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 / switch between two modes of thought, but then again maybe you need to do that anyway?)

- Structural versus nominal typing, where the latter involves giving a name to each new type ("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").

- "consider Python classes, which are quite nominal despite being dynamic, and TypeScript interfaces, which are structural despite being static." — 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.

- "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 not recommend for this purpose is Haskell, which [is] aggressively nominal"

For what it'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/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.