[foldr]

The point is that a dynamic language will in some cases enable code that is simpler and more readable (and hence probably more reliable) because sometimes the simplest code is code that wouldn’t type check. Even if statically typed languages are more readable on average, this fact invalidates your claim that statically typed languages are strictly better in terms of reliability. This can only be true if you artificially restrict attention to the subset of programs in the dynamic language that could have been statically typed.

By the way, could you tone down the rhetoric a notch?

[threethirtytwo]

My claim is not invalid. It’s just being evaluated against a different question.

The original post says that claims like “static typing improves reliability” are unfalsifiable and therefore just vibes. That’s false, because the claim being made is not empirical to begin with. It’s a statement about language semantics.

Holding everything else constant, static typing eliminates a class of runtime failures by construction. Programs that would fail at runtime with type errors in a dynamic language are rejected before execution in a statically typed one. That is not a hypothesis about the real world, teams, or productivity. It’s a direct consequence of what static typing is. No evidence or falsification is required.

When you argue that dynamic languages can sometimes enable simpler or more readable code that may be more reliable in practice, you’ve changed the claim. That’s a discussion about human factors and development process. It may be true, but it does not invalidate the original claim, because it addresses a different level of analysis.

Additionally in practice it isn’t true. Your entire argument flips context and is trying to point out a niche corner case to show that my overall correct argument is not absolute. You’re already wrong practically, and you’re also wrong absolutely.

So the correct framing is:

- At the language level, static typing is strictly more reliable with respect to runtime type errors.

- At the human/process level, tradeoffs exist, and outcomes can vary.

Calling the first claim “invalid” only works if you silently replace it with the second. That’s the source of the disagreement.

[foldr]

You can't "hold everything else constant" because the set of programs that satisfy whatever type system is a proper subset of the set of valid programs.

[threethirtytwo]

That’s a very long and indirect jump to make.

The claim that admitting a larger set of programs improves reliability goes through several speculative steps: that the extra programs are correct, that they are simpler, that simplicity leads to fewer mistakes, and that those mistakes would not have been caught elsewhere. None of that follows from the language semantics. It’s a human-factor argument layered on top of assumptions.

By contrast, static typing removing a class of runtime failures is immediate and unconditional. Programs that would fail at runtime with type errors simply cannot execute. No assumptions about developer skill, code style, review quality, or time pressure are needed.

Even in practice, this is why dynamic languages tend to reintroduce types via linters, contracts, or optional typing systems. The extra expressiveness doesn’t translate into higher reliability; it increases the error surface and then has to be constrained again.

So the expressiveness argument doesn’t invalidate the claim. It changes the topic. One side is a direct property of the language. The other is a speculative, multi-step causal story about human behavior. That’s why the original claim is neither unfalsifiable nor “just vibes.”

So regardless of speculative human factors, the claim stands: holding the language semantics constant, static typing strictly reduces the set of possible runtime failures, and therefore strictly increases reliability in the only direct, non-contingent sense available.