[colin_jack]

> But if I'm going to take over an adequately maintained code base, I'd rather it be in a static language, because more of the intent is explicit

Out of interest would you feel the same if both codebases had adequate test coverage?

In the post one of the reasons given was that with a static language you can pretty much guarantee that a dataflow is going to work, that you won't be caught out by getting the wrong type. I'd see this being most useful at the edges of the system, and in those cases incoming data would normally go through some validation anyway (including through a schema in many cases) which would normally make clear the types involved.

Having said that I do think in those cases being able to specify types can makes things slightly easier for newcomers, I'm just surprised its seen as a big enough advantage to be one of the key motivators to switching language.

[prodigal_erik]

A decent static type system ensures every object will be compatible with the types of all its references, no matter how the program may manipulate them. Only 100% path coverage could replace that guarantee, and that's generally regarded as infeasible.

No project I've worked on in twenty years had test coverage I could call "adequate", though I realize this is partly my fault. Hard-core TDD from day one might get you as far as "mediocre", and the industry average is much worse than that.

[colin_jack]

Sure thing but I was really thinking more of the "more of the intent is explicit" issue (and its affect on developer productivity) not guarantees regarding compatibility.