I think there are several flaws in this study, but alas, its subject is quite inflammatory and it is easy for people to gloss over the details and start drawing

I think there are several flaws in this study, but alas, its subject is quite inflammatory and it is easy for people to gloss over the details and start drawing conclusions. Here are a few things to keep in mind, IMO: - Good/capable/flexible static languages are much much harder to design than dynamic ones. Case in point is Haskell, where hundreds (thousands?) of researches have been working for years to widen the area of expression vs. area of safety. The devised language for this study seems very minimalistic to be useful. Most dynamic languages, on the other hand, pretty much let you do anything even when they have a simplistic design. - I find that people take longer to become fast/useful in static languages. While you can just throw things together and tweak until it works with a dynamic language, a static one will force you more to know what you're doing. I had a semi-technical colleague who had a much much easier time getting up to speed with Python than with any other static language. Therefore, unless the study involves a long prep time, it will naturally be skewed towards lower devel time in dynamic. - Static languages start shining as the project size/time-line grows. Key affected areas are refactoring, intra-team communication and incremental improvements on the code. To test for this, it would be interesting to stage a time lapse where developers are asked to modify their previous parsers after, say, a month of total separation. I think a more interesting study would be to hire 20 highly decorated Python devs and 20 highly decorated Haskell devs and give them a few different computational tasks, overall adding up to a large # of hours. Naturally, the study needs to limit usage of 3-rd party libs and take other normalizing measures. Then we may get a sense for what the state-of-the-art in both fronts have to offer.