4 ms·

That very first study, ANSI C vs K&R C seems like exactly the kind of test that's needed. Unfortunately, most languages are now heavily shaped by the typecheck

by jfoutz 12y ago

That very first study, ANSI C vs K&R C seems like exactly the kind of test that's needed. Unfortunately, most languages are now heavily shaped by the typechecker. That is, not many languages can flip the typechecker on or off with a switch - or have parallel typechecked and not implementations. That was one golden chance to get people familiar with the language to try both variations. And the effect of that? Slightly in favor of typechecked (he typed smugly). But that's not really enough. It's not clear there's even a 5% bump in productivity. I like compile time typechecking. I like static guarantees. But there's just not enough evidence to say typechecking is a must-have. And really, I'm not sure it's possible to construct an environment to test that.

jarcane 12y ago
The only one I know of that can do both typed and untyped readily (without weird third-party libraries) is Racket v. Typed Racket. It would actually be interesting to see a study done comparing the two, but the sometimes shaky documentation of the latter might even throw the results.
joseraul 12y ago
We could try TypeScript vs JavaScript. TypeScript type annotations are optional, and its semantics are by design exactly those of Javascript.
- kybernetikos 12y ago
  I've come to the conclusion that when you can get your code running and producing errors (javascript) in less time than it takes to compile to see the type errors (scala) the benefits of types seem a lot less persuasive. Anything that adds an extra step to the workflow can diminish the benefit of types, so if you were to do a TypeScript vs JavaScript comparison, you'd have to decide whether you wanted the comparison to include the extra time that TypeScript adds into your iteration flow or make a fake build step for vanilla javascript that slows things down. Maybe es6 transpiled to es5 vs TypeScript would be fair.
bmh100 12y ago
Clojure can also do this, since it has a Typed module [1]. [1] https://github.com/clojure/core.typed https://github.com/clojure/core.typed
_ZeD_ 12y ago
Well, a "solution" is a typechecker-as-lint, something like mypy[0]. I think it's also for this "pluggability" (it's an external program, not the interpreter, so you can freely choose what to run) that GvR proposed it's usage in the python devel ml[1] [0] http://www.mypy-lang.org/ http://www.mypy-lang.org/ [1] https://mail.python.org/pipermail/python-ideas/2014-August/028618.html https://mail.python.org/pipermail/python-ideas/2014-August/0...
jerf 12y ago
"Slightly in favor of typechecked (he typed smugly). But that's not really enough. It's not clear there's even a 5% bump in productivity." One question would be "does it compound?" A "5%" advantage (leaving aside how we could even define something that precisely) that compounds every 1000 lines is hard to detect in any reasonable study but could have an astounding effect by the time you've written a 50,000 line application. Even a 1% advantage compounds quickly to significant differences at scale, yet in the small will be virtually impossible to detect as it will be more than swamped by the noise floor. Part of the problem with these studies is that yes, programmer skill probably does dominate at the smaller end of the scale. I've come to really not like dynamic typing for the sort of work I do, but I still can and do crank out 500-line Perl scripts at times, because if that really is all I need, static vs. dynamic typing aren't the question. It's about how comfortable I am, how comfortable my coworkers are, what kind of library support I need, and a lot of other considerations long before I worry about typing. By contrast, putting together a multi-dozen-thousand line codebase leads me to entirely different considerations in my language choice. My summary of the summaries is that we still have virtually no hard evidence to go on that has any utility or relevance to real-world software engineering. At best we have some suggestions about how we might teach students how to do their tiny school assignments and a couple of interesting-but-inconclusive case studies on code of real size.
infraruby 12y ago
> or have parallel typechecked and not implementations InfraRuby (at http://infraruby.com/live http://infraruby.com/live), compatible with Ruby interpreters, is typechecked.

by jfoutz 12y ago

jarcane 12y ago

The only one I know of that can do both typed and untyped readily (without weird third-party libraries) is Racket v. Typed Racket. It would actually be interesting to see a study done comparing the two, but the sometimes shaky documentation of the latter might even throw the results.

joseraul 12y ago

We could try TypeScript vs JavaScript. TypeScript type annotations are optional, and its semantics are by design exactly those of Javascript.

kybernetikos 12y ago
I've come to the conclusion that when you can get your code running and producing errors (javascript) in less time than it takes to compile to see the type errors (scala) the benefits of types seem a lot less persuasive. Anything that adds an extra step to the workflow can diminish the benefit of types, so if you were to do a TypeScript vs JavaScript comparison, you'd have to decide whether you wanted the comparison to include the extra time that TypeScript adds into your iteration flow or make a fake build step for vanilla javascript that slows things down. Maybe es6 transpiled to es5 vs TypeScript would be fair.

bmh100 12y ago

Clojure can also do this, since it has a Typed module [1]. [1] https://github.com/clojure/core.typed https://github.com/clojure/core.typed

_ZeD_ 12y ago

Well, a "solution" is a typechecker-as-lint, something like mypy[0]. I think it's also for this "pluggability" (it's an external program, not the interpreter, so you can freely choose what to run) that GvR proposed it's usage in the python devel ml[1] [0] http://www.mypy-lang.org/ http://www.mypy-lang.org/ [1] https://mail.python.org/pipermail/python-ideas/2014-August/028618.html https://mail.python.org/pipermail/python-ideas/2014-August/0...

jerf 12y ago

"Slightly in favor of typechecked (he typed smugly). But that's not really enough. It's not clear there's even a 5% bump in productivity." One question would be "does it compound?" A "5%" advantage (leaving aside how we could even define something that precisely) that compounds every 1000 lines is hard to detect in any reasonable study but could have an astounding effect by the time you've written a 50,000 line application. Even a 1% advantage compounds quickly to significant differences at scale, yet in the small will be virtually impossible to detect as it will be more than swamped by the noise floor. Part of the problem with these studies is that yes, programmer skill probably does dominate at the smaller end of the scale. I've come to really not like dynamic typing for the sort of work I do, but I still can and do crank out 500-line Perl scripts at times, because if that really is all I need, static vs. dynamic typing aren't the question. It's about how comfortable I am, how comfortable my coworkers are, what kind of library support I need, and a lot of other considerations long before I worry about typing. By contrast, putting together a multi-dozen-thousand line codebase leads me to entirely different considerations in my language choice. My summary of the summaries is that we still have virtually no hard evidence to go on that has any utility or relevance to real-world software engineering. At best we have some suggestions about how we might teach students how to do their tiny school assignments and a couple of interesting-but-inconclusive case studies on code of real size.

infraruby 12y ago

> or have parallel typechecked and not implementations InfraRuby (at http://infraruby.com/live http://infraruby.com/live), compatible with Ruby interpreters, is typechecked.