Yeah but typing related bugs which is what static type checkers catch only account for 3% of bugs.
You are always going to get more bang for buck by simply writing more unit tests.
Static typing is done primarily for performance and that requires a statically typed language. Hacking it into a scripting language is plain looking for trouble.
Tell me more as I want to grok the dynamic typists viewpoint as I’m sure I’ll learn something. So are you doing type check assertions at runtime and throwing errors? Or are we talking about something else?
What I like most about static typing is tooling support for refactoring and how much easier it can be to change a name or significantly change internal apis and jig stuff around with confidence.
If i got a weird typing issue and i have no clue about it, then i know my design is mostly wrong. That's one of usefulness of a static type checker for me.
It addresses similar problems as static typing, yes, but it's not a compile time check. Instead, it's an optional runtime check. The idea is to use it during testing and development, and have it be disabled during production.
Oh ok. So it's not really static at all, they're just calling it that because it sounds better. It's simply dynamic type-checking that checks the types immediately prior to calling the function instead of checking them at the top of the function body. Offhand, it seems that the only benefit to this approach (checking prior to calling the function instead of checking inside the function) is the ability to cache the results and skip checking the same callsite in the future if nothing's changed.
Being able to significantly optimize type-checking for scripting languages like this to the point where you can actually run this in production seems quite valuable. But calling it "static type-checking" is simply wrong. Granted, they're calling it "just-in-time static", but that phrase is contradictory, it would be like saying "dynamic static type checking".
Static typing is considered unpythonic, but the typecheck library is closer to a sanity-checking model (like using assert). The advantage is that instead of the checks being in the body, they can be moved to the function header. It supports things such as checking ranges or regex matches, rather than just object types.
Even if people are only using it as a shim for what could be static typechecking, I think there's something to say about the practicality of it existing, if only for the reason that their ecosystem might already be Python-based.
You're arguing with a strawman. I'm just saying static typechecking is usually sufficient this day in age. Your language itself doesn't have to be static. Actually I'll go even further: It wasn't enough three years ago when language server protocol wasn't a thing.
I've grown to hate the phrase "static typing". It's almost as meaningless as "strong typing". While checking types compile-time certainly has it's benefits, the issue presented here is almost entirely orthogonal to that. The problem here is that strings are handled essentially as untyped opaque blobs as far as the type system is concerned. If the strings were typed properly, then both static and dynamic type systems (if otherwise equivalent) would catch the errors.
Yeah, there's this notion that with static typing, you have to "get your types right first". In my experience, when I'm prototyping it's often very effective to sketch out my current understanding in the types, and then as I learn - quickly and slowly - where I was mistaken and update the types, the type checker helps me update the code that needs updating to match.
reply