If you have a system where the developers often aren’t sure what it does, how to organize the code, aren’t designing for maintainability, etc., static type checking really isn’t going to help you pick up the pieces afterward.
I like static type checking for what it does, but it solves some little problems, not big ones. (And can cause their own little problems.)
A static type system doesn't protect you from choosing the wrong abstraction, and all the bugs that result from it. But if used properly I think it does help.
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.
Static typing is a very bad software development practice. There are a lot of other software development practices that are superior to it.
"help you in refactoring" It's a terrible way to refactor your code.
There are far better and far superior software development practices out there, which do everything static typing does and more.
"There is no way around verifying your assumptions about types" Yes, there are. There are many many ways to do this that do a lot better job than static typing. Static typing is known to be terrible at eliminating bugs from code.
The complain here is not that static typing isn't better than nothing but that static typing is such a low tier solution, that if you were doing anything proper you wouldn't be touching it.
> Static checking burdens the developer with thinking more, etc. -- for sure.
I'm not sure I agree. Most type languages as implemented in common programming languages are bad at describing abstraction. This means that if you're programming in one of these languages, you are forced to reduce your level of abstraction (which is sometimes touted as an advantage).
And just because someone's smart enough to find working out how to satisfy the type checker an enjoyable challenge, doesn't mean they're dumb enough to think that just because it's fun it is always a good use of their time.
If you don't test the behavior of your code then it is wrong. Whether the code could in theory be compiled isn't a very good test case.
Static type checking has a measured bug catch rate of <1%. So the quality of any code where the programmer depends on static typing to verify correctness rather than unit tests is very very low.
But at its best (as in Haskell), static typing just means that the compiler is enforcing the requirements of your interfaces. Why would you not want to know about these bugs immediately and fix them early in the development process when it's cheap to do? Why wouldn't you want the compiler recheck everything automatically every time you change your interfaces?
Everybody's always fixing bugs. Static typing makes it more likely that the bugs you're working on are closer to the problem domain, instead of being crap work that should have been caught at compilation time with better languages and compilers.
Static typing check is a huge boost for code refactoring. It allows you to quickly make changes and be reasonably confident that you haven’t horrendously broken something.
It doesn’t obviate the need for dynamic validation nor is it meant to do that. But it does give you a clear point of where to perform those validations rather than littering it everywhere throughout your application.
It doesn’t obviate the need for testing either. But it does eliminate an entire class of dumb programming errors such as incoming a function with the wrong arguments.
IMO adding static types is good step but it sort of misses the point of modern type systems.
The good thing about types is not that you can just annotate (or not with good inference not) and validate that some type is what you expect it to be. It's that with a proper type system you can develop better abstractions.
Static typing sounds great to Junior Software Developers, who don't properly understand what the problems the software they write needs to solve.
Static typing allows me to check the types are correct! In practice, typing related errors are a very rare bug so it isn't very useful.
Static typing allows me to check things at compile type. In practice, this means waiting around for things to compile and lots of dead time. The larger the project get the longer the compiles times.
If performance doesn't matter, dynamic typing is pretty much always the way to go. You get the code out faster, so you have time to write more tests and you can throw away the code faster. Cause in the real world, code is a churning thing that evoles with the business requirements. Not some static build once thing that static typing and Junior Software Developers assume.
From an organizational perspective, the benefits of static type checking are quite obvious. I'd go so far as to say it's a software engineering best practice to prefer languages with static types when building new software. The reason for this is because many, many, many engineering hours are saved at an organizational level by having a compiler that is able to enforce correct data structures throughout the application. Eschewing types for speed is just a form of technical debt that has to be repaid in perpetuity whenever it comes time to maintain or refactor the software, not to mention the fact that every new developer working on the application is now burdened with this debt.
While it's fair to say that a static type system adds friction which isn't suitable for some development mindsets,
I think it's worth expanding on problems people run into with types.
Bad types at runtime: with a static type system you make the effort to be sure the code does what it says. With plain ol' JS you can get that confidence from tests.
-- different trade-offs made each way.
But another benefit to static types is knowing the structure of the data you're dealing with and how to manipulate it, while you're developing/maintaining the code.
-- sure: naming, unit tests, documentation etc. can help, but I find not having the static types handy makes things tricky when there's enough indirection/complexity.
As with the stuff about runtime errors, tastes vary, of course.
I don't deny that. The problem is not with the idea, it's with the (usual) implementation, which is that if you don't appease the type-checker it won't let you run your program. I'm perfectly fine with a type checker that only gives me warnings but still allows me to run the code even if it isn't satisfied.
My experience has taught me that if static typing improves your code, it's probably hiding deeper flaws.
I won't deny there are some clever things one can do to improve code with sophisticated typing. However, the typical usage is to alleviate the mistakes of bad names and poor design. When I find type errors at runtime, I look for a way to refactor that avoids confusion without needing to add type checking. I don't always succeed, but when I do the code is more elegant.
Utilizing a type checker when you want is very different from being forced to use it. Statically typed languages create a lot of complexity from being entirely dependent on types being correct in a static sense rather than at runtime.
With type checkers for dynamic languages, a lot of the arguments in favor of static languages disappear.
Maybe, but using static types is not a panacea either. It only make it easier to assume that someone have correctly constructed the value and that all manipulation have been correct so far. The type checker helps by checking that if the assumption is true, everything down the line is also true. But only in the context of the code, not in the context of the process itself, where the assumption may be incorrect, or the chain is broken somewhere due to bad logic (that’s when off-by-one errors arise). Nothing is a silver bullet. Static types can make life easier by preventing some meaningless code, but they don’t ensure correct programs.
It depends on the situation. I've had code that absolutely benefited from static types and it helped me find bugs before they happened.
But my current job has very, very little that would benefit from static typing. Adding it into the mix would slow us down, both literally and figuratively.
I like static type checking for what it does, but it solves some little problems, not big ones. (And can cause their own little problems.)
reply