4 ms·
I believe you, because that intuitively makes sense, but can anyone give me a typical real-world example where this could easily happen? So an application, say
by tripzilch 14y ago
I believe you, because that intuitively makes sense, but can anyone give me a typical real-world example where this could easily happen?
So an application, say a web application in Python using some framework, what kind of type-related coding mistakes could you make? And which ones would be subtle enough to only be caught after it's in the customer's hands? (assuming a reasonable minimum of testing before that)
I'm asking not out of disbelief, but just because I'm having a real hard time coming up with an example that makes me "yeah I'd fall for that and only realize until after I delivered".
Is it possible that maybe, just general good coding style in Python makes it so that either you don't even consider sending a `str` to a function that expects a `float`, or that if you do (something like that) it fails almost immediately with a run-time Exception, way before you think of delivering?
For most of my Python programs, once they're done, if you'd analyze them, the types sent over all code paths probably would be static :) I'd think it pretty strange if a program would suddenly call functions with different parameter types, depending on user-input, unless you actively decided that it should do so by design (like something that handles arbitrary JSON-like structures), in which case you probably intend to restrict the amount of types it will be intended to handle.
So in that sense, you end up with what is mostly a statically typed program in the end, even if written in a dynamic language, no?
One thing I do agree that if your program is written dynamically typed and intends to keep on being very dynamic about its typing even after it's done during run-time then, yes, it's probably almost impossible to make sure it does not crash or throw exceptions, given arbitrary user input. But in that case, often this is expected, and not the kind of program you'd consider an end-user application, but rather a sort of tool script thing that can indeed crash on unexpected input. Which is also useful :)
So, and correct me if I'm wrong, but I'd conclude that the difference is that with dynamic typing, there's less red tape during development. But a well written program intended for end users probably ends up with mostly static types de facto because otherwise it'd be fairly unpredictable. However, if you'd have used a statically typed language, you would not have to assume "well written" because the static typing brings guarantees with it.
- KMag 14y agoSome advantages of static typing show up in programming in the small. Errors in forgetting to check for null/nil/None are a common class of errors that are caught by many static type systems. Switch/match statements that leave out possibilities without providing a default (especially if a new value is added to an enum) are also common errors that are caught by some type checkers. One hidden (and seldom discussed) feature of static type systems is that in multi-team projects, they can enforce and document abstraction layers between teams. I've even seen static type systems act as impartial arbiters when an argument arises as to if a given change broke one side of an abstraction barrier, or if the change merely exposed a latent silent bug on the other side of the abstraction barrier.