Empirical evidence. Studies indicating that software developed in statically-typed languages has fewer defects. Research into the speed of development and the ability to accommodate major changes in requirements and functionality would be useful as well.

Last I looked, there isn't a great deal of literature on this, and what there is is fairly old (dealing with '80s-'90s languages) and inconclusive.

Is the presentation not good enough?

> Research into the speed of development and the ability to accommodate major changes in requirements and functionality would be useful as well.

You kind of slipped those in, we were talking about correctness.

No we weren't. We were talking about "being less bug prone" and "easier to read."

Though, I'm not entirely sure that really changes much. :(

Look, I'm not against static typing. I confess to being somewhat in love with lisp at the moment. And, I'm trying to learn MIXAL for some unholy reason. At the same time, I try to type my systems as well as I can. I am far from convinced that typing will be the way to go.

Especially if you consider auxiliary tools. Having used Coverity some, it is down right impressive the stability you can bring to a C codebase with proper discipline and the appropriate tooling. Compared to using something such as a Scala codebase, where right now your only recourse is the compiler.

That is, static analysis does not begin and end with the compiler. Sadly, in moving to "newer" statically typed languages, you through out many of the tools that currently exist in the older languages.

And this is not just for "correctness". Having finally added "-march=native" to my flags for a build of software, I'm literally amazed at how well optimized a compile can be versus just using "-O3". Optimizations in the modern world are quite amazing without necessarily needing "better types."

Remind me, what's the typing discipline of the languages supported by Coverity?

Isn't that a touch of a diversion? With the large target area of code covered by C, it makes the most sense that that is the heaviest targetted area. This list[1] shows that there are plenty of options to go around. Even Perl gets some love. :)

[1] http://en.wikipedia.org/wiki/List_of_tools_for_static_code_a...

You do realize that all those tools for dynamic languages are code formatters right? That they won't catch any real bugs. You do realize that right? Why do you think that they can't catch any real bugs? Hint: it has to do with static typing or lack thereof.

That is like claiming a tool like lint can't be used to catch bugs. And... not all of them are. Did you read all of the tools in the "mixed languages" section? Quite a few of the really good tools can find mistakes in dynamic languages.

Shit, this is no different than the article making the rounds talking about the many "gotchas" in bash scripting. Just making a tool that spots those is likely to catch and help correct errors.

The presentation was interesting, but if there were any studies cited I didn't see them. I'm looking for deductive research into the proposal that using a modern statically-typed language results in a better outcome than a modern dynamically-typed one.

The related research I mentioned is useful because if development in a given language improves correctness but also increases development time by an order of magnitude it might still be more effective to develop software in the "worse" language and spend the additional available time mitigating the risk or building additional features.

No, googling those results doesn't really work. :) You get a ton of dogma with a lot of logical arguments. All of which are very appealing. Appealing arguments worry me, though.

What I have not seen, is evidence that any of your claims are true. I have seen easy to read programs in both dynamic and static languages. So far, I've seen very little correlation between the two as to which is desirable. The static languages are typically a bear on some algorithms because you have to provide so much more to the compiler for it to trust you. This does feel like it would lead to less bugs, but it goes against the "readable" and possibly the "more productive" ideas.

How do you determine the return value of a C function? You look at the function prototype. How do you determine the return value of a Python function? You have to read the whole thing. If you are working with large code bases, reading the whole thing is not really possible.

You are just trying to make an appealing argument. This literally adds nothing to the debate. A simple survey of open source software would be more convincing. And even that wouldn't be definitive.

Where's the appeal in my argument? It was an example.

It is an appeal to how logical the example seems. That is, it sounds like it would be applicable "at large." However, evidence seems to show that, "at large," it is mostly a non sequitor.

That is, you get better systems the more programmers you have that do have a good grasp on the whole system. Ironically, you have better arguments against knowing specifics of the system -- that is, at the individual function level -- than you do the high level picture. Consider, Linus knows the linux kernel better than I can really comprehend. I doubt he knows every function's return value.