5 ms·
Where is the evidence that static typing results in a net benefit? There's some evidence that points in the opposite direction: http://games.greggman.com/game/
by orgomon 10y ago
Where is the evidence that static typing results in a net benefit? There's some evidence that points in the opposite direction:
http://games.greggman.com/game/dynamic-typing-static-typing/ http://games.greggman.com/game/dynamic-typing-static-typing/
When a language imposes static types, it also imposes a development cost, possibly negating all the value it brings.
Typescript is a little in the middle in that static typing is optional, but then you also don't reap the supposed benefits wherever you don't use it. Any "tool-based" refactoring is now less reliable than a simple text search.
As for catching type errors, those are usually caught very early. If they aren't, that points to a lack of test coverage.
As for the "documenting" aspect: The article claims that by static typing, the documentation need not be consulted, which is rather irresponsible. If you use a function, you had better read the documentation. I know that's a bit much to ask from actual developers, but it's true.
- PeCaN 10y agoMaybe it's because I'm lazy and sloppy, but I'd rather the language catch type mistakes than having to write tests for that. Plus, domain modelling with types is nice in ML dialects.
- orgomon 10y agoYou're not writing tests to catch type errors. You write tests that actually use your code, where a type error will almost certainly be picked up. Chances are however, your type error will already occur the first time you run your code.
- crypto5 10y ago> it also imposes a development cost, Very very small cost.
- rtpg 10y agoHistorically this cost was a lot higher though. It's only fairly recently that mainstream languages had type inferencing. Before it could be quite costly (and affect code legibility too)
- dang 10y ago> Very very small cost. I've gone back and forth a few times in my career (currently preferring dynamic languages) and would say that the cost is considerable, even with type inference. The trouble is, we don't notice the costs of approaches we're habituated to or prefer, so it feels like they're much smaller than they are. And we don't account for the costs we don't notice, so our cost/benefit analyses (on both sides of the question) are skewed. We all unconsciously put a finger on the scale. This doesn't stop everyone from making grand, confident claims about static vs. dynamic typing. Such studies as there are don't support these claims, but the studies are weak in so many ways that it's easy to dismiss the ones you don't like and stick to your previous opinion, so that's what we all do. For these reasons, the debate is pure tribalism and cargo cult. We should stop pretending that our views have any objective support and just talk about them in terms of taste. That's unsatisfying to the technical mind, though, so none of us will!
- crypto5 10y agoWhere does considerable cost come from? There is a small overhead in number of characters in your program. I think that's it.
- domlebo70 10y agoWhat is the cost? I mean, you are already working through the types in your head when writing code in a dynamically typed language. It's not like you get to just forget what type things are when you program.
- pixie_ 10y agoDevelopment cost? I've had huge development savings using typescript. The support for fast refactoring plus constant intellisense of any type errors has sped up my up my development significantly.
- pixie_ 10y agoDevelopment cost? I've had huge development savings using typescript. The support for fast refactoring plus constant intellisense of any type errors has sped up my up my development significantly.
- adamnemecek 10y agoNot this thing again :-/
- swift 10y agoI notice in your comments that you express concern about the development cost imposed by static typing, but then you later on state that you expect type errors to be caught by tests. Here's the thing: test coverage is crucial on any large project, and we (hopefully) all agree that they're worth it, but tests can be very hard to write and impose a huge development cost. Static typing helps reduce that cost by reducing the number of tests you need to write. Generally, the more powerful the type system, the more the number of tests you need to write is reduced. It's been my experience that the development cost of static typing is infinitesimal compared to the savings of having to write and maintain fewer tests. YMMV.
- mcphage 10y ago> Static typing helps reduce that cost by reducing the number of tests you need to write. Those type annotations are the tests, they're just run by the compiler. And once you realize that, you can start to ask: are these the most valuable tests to write? If I have a fixed amount of time to write & maintain tests, would that time be better spent testing things more likely to be incorrect?
- tracker1 10y agoIn the case of TS, they go out the window at runtime... anything outside of your project that comes in (json via rpc or rest) or outside-in calls/callbacks don't enforce the type safety.
- mcphage 10y agoYeah, and that's frustrating because it also eliminates the performance gains that come when you can determine what exact function will be called, rather than having to determine it at runtime. I guess that's the consequence of TS being a superset of JS.
- lomnakkus 10y ago> Those type annotations are the tests, Disagree slightly. Type annotations are logical propositions and the compiler proves them for you. That is to say: Tests can only prove the presence of bugs, not absence. Types prove the absence of (type-related) bugs. They essentially give you theoretically perfect test coverage (modulo bugs in the compiler).
- Cpoll 10y agoThe article itself throws some self-doubt with a link to http://danluu.com/empirical-pl/ http://danluu.com/empirical-pl/ It's also a bit of a pain that it's just a summary of a video, and there's no citation to any text anyway. From what I can tell, the first bit of evidence is from a researcher's toy language. The second was a scan of GitHub for issues that included type errors. There's no mention of actual methodology, but I'm imagining that means 3% of Python issues in GitHub have a copy-and-pasted stacktrace that contains a type error? This is clearly not a great indicator, since it won't count issues with less description, or any bugs related to, say, a bad type coercion. On the other hand, you're right, I've not read any research that points to static typing being a net-gain. Every static-type advocate probably remembers being burned by a dynamic-type issue, but that doesn't mean the advantages might not outweigh disadvantages - experience and intuition don't cut it here.
- orgomon 10y agoIn the absence of evidence, what else do you have besides experience and intuition? I'm not actually making a claim one way or the other, I'm rather questioning one argument in favor of static typing. There are other arguments for static typing which I agree with, but which are too domain-specific.
- namelezz 10y agoI remember TypeScript creator(forgot his name) mentioned that it's extremely difficult to do refactoring right in JS. Edit: https://youtu.be/lT07c3OREL8?t=713 https://youtu.be/lT07c3OREL8?t=713
- protomyth 10y agoI would find it interesting to know why refactoring tools are successful in Smalltalk but not JS.
- hota_mazi 10y agoThey're not successful in Smalltalk: the absence of type makes automatic refactorings unpredictable because the compiler simply can't guarantee you that it's not breaking anything. Today's automatic refactoring IDE's are light years ahead what the Smalltalk Refactoring browser ever did.
- protomyth 10y agoSaying they are not successful in Smalltalk doesn't jive with the history of refactoring browsers in Smalltalk. I doubt the widespread use of a tool in a language if it didn't work.
- zastrowm 10y agoAnders Hejlsberg is who you're thinking of. > He was the original author of Turbo Pascal and the chief architect of Delphi... the lead architect of C# and core developer on TypeScript. (from wikipedia)