>
The problem about the whole "it's faster (productivity wise) than static typing" has, as far as I know, never actually been proven (certainly not through repeated studies).Neither has the opposite, so there's that.
There's an ACM paper too ("An Experiment About Static and Dynamic Type Systems", 2010) which found higher productivity for the same code quality with dynamic typing. Of course a few papers here and there, pro or against, are as good as none. It's hardly a well studied area.
Besides, one or the other proven better doesn't mean much, just like you liking eggs over easy vs scrambled eggs doesn't depend on some study. If it works for you, and you're more productive with dynamic typing or static typing, use that.
Even if a study "proved" that one kind is "more productive" based on some statistics from measuring some group, or that it has "less bugs" most people when given a choice would still use what they prefer and makes them, as individuals, more productive and happy coding.
>Having worked with both dynamically and statically typed languages extensively, I never felt I was _more_ productive in a dynamically (or gradually) typed language compared to one that was just statically typed.
Depends on the type of program, the type of programming (e.g. imperative/declarive/functional/logical/OO or some combination and so on), the program's scale, the team size, and other aspects, including individual aptitude and preference, not to mention the language and its semantics beyond dynamic/static (and the ecosystem too). I'd certainly be way more producting using dynamic numpy than some C equivalent, even if as a lib it had feature parity.
>In addition, that work you need to (potentially) pay upfront will help you a lot in the long term, so I suspect that for anything but the most basic programs static typing leads to better productivity over time.
There are problems where upfront work is not a benefit, e.g. if it means getting behind in building your MVP or getting behind a competitor adding new features faster while you "perfect it", and your early stage startup loses steam. Also for things where the overhead of upfront might put you off from even attempting them. It can also be a problem to have big upfront costs for exploratory programming and searching into the problem space for your design/solution.