[nlitened]

> You end up rebuilding semantics over and over again (validation, mapping, enrichment), and a lot of failures only show up at runtime.

I think die-hard fans of static typing mostly fail to acknowledge this objective reality and its implications. Every time they encounter this problem again and again, they approach it as if nobody thought of this before, and didn’t develop reliable abstractions to productively work in these environments.

[aGHz]

I'm genuinely interested in examples of these reliable abstractions, or at least in some keywords I can look up.

[nlitened]

The way I see it, Clojure was created to address most of the philosophical problems highlighted in the article, and its ecosystem has developed under the influence of such ideas.

It embraces the dynamic nature of things. Every program that must do I/O is dynamically typed at the edges - so statically-typed languages must have both the facilities for dealing with dynamic types and static types, and use those differently for "inner" and "outer" parts of the program. The Clojure ecosystem makes it more approachable to work with dynamic data, and as a result, program's parts (modules, even functions) use the same machinery as the program as a whole. What helps, off the top of my head:

1. Immutability of values, persistent data structures, explicit state management - it turns out most of the "problems" with dynamic types are not due to the fact that types are unknown, but the fact that they may change over time. Most of concurrency problems also become irrelevant with immutable values.

2. Powerful data specs/schemas allowing to express full business requirements and constraints on expressible values (not possible with static typing anyway) — making invalid states unrepresentable and actually meaning it.

3. Concise unified model for working with different logical data structures, also nested data structures.

4. Simple asynchronous communication mechanisms and patterns between independent modules of a programs.

5. Rich extensible aggregates of data with namespaced keys as the object model.

6. An ethos of extreme backward compatibility (and tools for achieving and maintaining it) through accretion of novel values/parameters/features, enabling reloadable workflows, which makes it easy not only to redefine functions in code while program is running, but also updating individual programs while interconnected system is running, without breaking things.

The downside is that tools that reduce complexity are not very easy to use for people with less experience, so they cannot be too popular. People tend to overcomplicate, and to be quick to dismiss well-thought-out solutions.