This seems like one of those "Zen" things, where you eventually realize you are more effective when you use both kinds (compile time types and runtime-only type

This seems like one of those "Zen" things, where you eventually realize you are more effective when you use both kinds (compile time types and runtime-only types/tags) of programming together, rather than trying to pick only one and label the other as evil. Now I must "reflect" upon the wisdom of all the strong typing in my Java programs, and how a simple refactor always safely finds all the use cases of a class/method/variable for me. (NOT -- although IntelliJ is pretty good at finding many common hiding places in various texts for program identifiers) I really want one language that combines optional (dynamic) and mandatory (static) compile-time type info, with some pragmas at the top of a module warning me that the module uses or supports dynamic types, rather than having to resort to XML DSL monstrosities. One final rant: The author mentions an FP language (Haskell), and then talks about data flow analysis. Strangely, however, he seems more concerned with types than immutability and explicit data passing / folding. Favoring explicit input/output values over side effects, is a huge factor in seeing data flow (and orthogonal to compile vs runtime types). Alas, the "enterprise" development squad seems to actively resists learning FP, preferring to cling to "COBOL with namespaces and compilation units" as state of the art programming methodology. I think this problem is the real (productivity) killer. (OTOH, he could tacitly assume pure functions, etc, are a good thing, and should be the norm. Hard to say)