Having so few constraints on implementation (e.g. duck typing) was an interesting concept, but time has proven it to be a nightmare maintainability.
Citation needed. Just because static typing is has been more fashionable for the past 10 years, doesn't mean it's a closed case. Before that people were extolling the virtues of dynamic languages.
Some people deciding they prefer static typing doesn't constitute some kind of consensus or fact.
Yes, I can't prove it. There's no quantitative way of doing so.
I've worked with very big duck typed codebases for quite a few years now (and largely statically typed in C# before that) and the above is my opinion. Duck typing is convenient early on, but it makes understanding code (especially where it gets complicated or you didn't write it) quite difficult, and any kind of refactoring downright scary. After a point you (1) start getting hugely defensive with tests because without close to 100% coverage you just can't know if anything works, and (2) stop making big changes and instead accept that small incremental deployments towards a greater end is the only safe way towards making progress.
I suspect that how much you agree with this statement is strongly correlated to the size of your codebase. I'd be surprised to meet people with codebases on the order of 100k lines or greater that don't largely share this sentiment.
I don't understand how (1) isn't a positive in your eyes. (2) is true for pretty much every large statically typed codebase I've worked on.
I'll admit, my commercial experience has all been in statically typed languages. But there are a lot of complex, well written pieces of software written using dynamic types. Maybe you don't meet their proponents, but they do exist.
FWIW, I quite like static typing, but I consider it a feature, not a religion.
> I don't understand how (1) isn't a positive in your eyes.
I like testing as much as the next person and consider it very important, but your tests should be testing business logic rather than whether your syntax is correct. The problem with dynamic languages is that while you're certainly doing the former, you're also doing way too much of the latter. Until you hit runtime, you have no idea whether you misreferenced a variable or invoked a method that doesn't exist, so you end up writing an exaggerated number of tests that are repetitive, slow things down, and end up requiring considerable maintenance.
> (2) is true for pretty much every large statically typed codebase I've worked on.
Yes, incremental deployment is always a good idea, but it's a matter of degree.
Take for example a case where I need to rename a method that's widespread throughout the codebase. In a static language, I wouldn't give this a second thought. If there's a problem my compiler will catch it, and that's the end of the story.
In a dynamic one, this is a dangerous operation: the old method name may still be getting invoked dynamically in a non-obvious way, or another branch may have been merged _after_ I branched but _before_ I deployed that still has an invocation of the old name. Hopefully you have tests on these paths that will reveal the problem, but you might not, and to hedge against that possibility, you have to roll the change out to production carefully and slowly (because even there, it might be some time before some unwitting user inadvertently triggers the bad flow).
Patrick Logan on Lobste.rs comes to mind. He talks a lot about using Smalltalk for robust applications. Here's one paper he shared where Smalltalk team killed the others in productivity. Unfortunately, I didn't get defect rates on all the teams where Ada or C++ were usually winning in those kinds of comparisons.
He said they mostly just test everything at the interfaces. However, it's simplicity also allowed for powerful tools in code generation, refactoring especially, and so on.
Citation needed. Just because static typing is has been more fashionable for the past 10 years, doesn't mean it's a closed case. Before that people were extolling the virtues of dynamic languages.
Some people deciding they prefer static typing doesn't constitute some kind of consensus or fact.