[conanbatt]

> ...We now have to hunt and peck across the codebase, and change all our policies so that it handles this possibility well.

A stellar case about Object design, not strong typing. I don't find type solves this issue, in fact, it even might be the opposite. Its way looser and more flexible to be able to say how things actually behave than to define the exact type they are to see how they behave.

The static analysis is definitely a huge plus, but it's a bit tangential: if a static analysis tool were able to point to the same issues, the reason would evaporate. (It's like saying a language is better because it has a better community, which is practical but not intrinsic).

[jasim]

Objects don't solve this. Untyped programming is more flexible, but are able to express less things about the domain explicitly than typed languages (not Java/C#, but rather OCaml/Haskell etc.).

> if a static analysis tool were able to point to the same issues, the reason would evaporate.

This static analysis tool is called the type checker. The experience of using a type checker is best when the underlying language has sound types. Sorbet, TypeScript, Typed Racket etc. bolt a type system on top of an existing language, and so don't have a choice but to be unsound, and so their qualitative experience isn't as nice as it could be. Even so, they're highly recommended for large codebases.

> It's like saying a language is better because it has a better community, which is practical but not intrinsic

Not at all. This is an intrinsic feature of programming languages and has a huge effect on how we think of programs.

It is however not a silver bullet and when building web applications, practicality - tooling, ecosystem etc. trumps everything else. However if you run into difficult problems which require deep attention to data modelling, and wish for a better tool to help frame the problem, then Typed Functional Programming might be a good try.