I don't even know why you need a study for this anyway. Working in a language where it's impossible to mix up strings and numbers, impossible to call a function with the wrong number of arguments etc. leads to less bugs by definition. Do you really need a study to prove you're more productive and your code is more secure in a language where mixing up types is impossible compared to using a language that lets you make that mistake? You can write secure code in assembly if you want but you're just making life hard for yourself.
This is my point really. A misleading study is worse than no study as people use it to back up their points with a false air of legitimacy.
Types are a trade off. Sometimes, by explicitly defining interfaces and types ad nauseam, you spend more time defining those types and managing those types than you ever would in fixing minor type errors that after all, generally only come from incorrectly calling a function.
I think JS code tends to be simpler than equivalent Java code and in my opinion, the simplicity of JS offsets its lack of explicit types.
"Simplicity is prerequisite for reliability." -Dijkstra
> Types are a trade off. Sometimes, by explicitly defining interfaces and types ad nauseam, you spend more time defining those types and managing those types than you ever would in fixing minor type errors that after all, generally only come from incorrectly calling a function.
I wouldn't agree with that. Issues with string/number conversions, strings being treated like arrays and unexpected undefined/null (these are particularly bad) are common in my experience in JavaScript. Even if they're not particularly common, you really think having to define a few interfaces takes so much time it nullifies the benefit of automatic error checking? Writing an interface is way less effort than writing a test as well, plus you get automatic refactoring tools, autocomplete and automatic error checking in return.
I really can't see why you'd want to give all that up to save a few keystrokes. I've done years of JavaScript after moving from typed languages like OCaml, C++, Java and Coq, and it's horrible trying to write large apps in plain JavaScript without types.
However, I think that in a strongly typed languages like Java, it's more than a few keystrokes. Also, because there's mutable state everywhere buried in Java classes, you get many more logic errors.
At the end of the day, I think simplicity is the best hedge against errors. However, I tend to agree that statically typed, functional languages are probably the best for preventing errors.
Type inference solves the extra typing issue and Java isn't a great example of a strongly typed language. For JavaScript, you can use TypeScript which has type inference and non-null checking. There's also BuckleScript or Reason if you want to code in OCaml so there's practical ways to get this safety in JavaScript.
> At the end of the day, I think simplicity is the best hedge against errors.
You can have static types + simplicity though which is better than just simplicity. Types and immutability constrain the behaviour of your program to make it simpler to reason about.
There is no silver bullet, though the article tries to pass off TDD as one. Also he does concede that static types can power tooling that might "feel like they make us more productive".
Disclaimer: I prefer having types but I also think JavaScript is great and don't shy away from using it.
Regarding the article you linked to, I recommend reading the discussion in the comments section (https://medium.com/@oxymor0n/eric-9f4869bb0ecb).
The UC Davis paper, for example, concludes:
"...language design does have a significant, but modest effect on software quality. Most notably, it does appear that strong typing is modestly better than weak typing, and among functional languages, static typing is also somewhat better than dynamic typing.
"This is strong evidence that functional static languages are less error prone than functional dynamic languages … In order to strengthen this assertion we recode the model as above using treatment coding and observe that the Functional-Static-Strong-Managed language class is significantly less defect prone than the Functional-Dynamic-Strong-Managed language class with p = 0.034."