[acdha]

> IMHO behavioral tests perform this function equally well.

I think a common pitfall in these discussions is to compare the worst case examples rather than reasonable quality codebases. I'd be far more interested in, say, time/cost to correct result metrics for a well-maintained Python codebase which has reasonable use of tests & linting (e.g. flake8) to an equivalently-proficient team using a statically typed language.

[dkersten]

If we're discussing well-maintained code, then I would expect that the public interface is documented, at least in docstrings. Then I also know what the parameters are.

[acdha]

Agreed — I'm just wondering about how to quantify the impact of various changes. A dynamic language project with no tests, etc. is going to look like a selling point for static typing but I suspect the real-world bug counts for, say, a Python project using mypy (or even flake8 + tests + coverage) is going to be a lot closer than you might think from how heated these discussions get.

[crdoconnor]

There was a study that did a line by line translation of 4 python projects to haskell and caught some bugs (between 0 and 4 per project): http://evanfarrer.blogspot.co.uk/2012/06/unit-testing-isnt-e...

I got the impression that the bugs found were either not at all serious (e.g. throwing a typeerror on malformed input instead of some other nicer kind of error) or were in areas of the code not covered by tests.

Unfortunately the author does not rate them by severity.

[acdha]

Thanks - that's a lot like what I had in mind!

My gut feeling is that dynamic typing + tests & static analysis is faster than very heavyweight languages (e.g. Java) but probably near or less than languages with more advanced typing systems like Haskell or Rust, but I'd really like to see something more comprehensive than a subjective opinion.