4 ms·
Lots of valid code, won't pass the type checker. That is the problem with static type checkers. You have to adapt your code to satisfy the type checker even whe
by jernfrost 9y ago
Lots of valid code, won't pass the type checker. That is the problem with static type checkers. You have to adapt your code to satisfy the type checker even when you know your logic is right.
Static type checking also significantly complicated meta programming, macros and code generation.
But hey I like statically typed languages too. A big fan of Swift which has borrowed many functional ideas. I just don't think static typing is the silver bullet that many of its proponents think.
It works well for some problems, but not all. E.g. I can't think of any statically typed language which can compete with Julia for numerical work and data science.
Haskell e.g. is just terrible at doing numerical work, as it poor at mutation. You can work effectively with lots of big matrices if you don't allow easy access to mutation.
- pyrale 9y ago> Lots of valid code, won't pass the type checker. That is the problem with static type checkers. I fail to see this as a problem. It's pretty much a feature, just as you don't expect object oriented languages to tolerate any shit you throw at them when you use the OO model. > I just don't think static typing is the silver bullet that many of its proponents think. You're the one making the case here, before answering it. > Haskell e.g. is just terrible at doing numerical work I've had good experience with https://wiki.haskell.org/Numeric_Haskell:_A_Repa_Tutorial https://wiki.haskell.org/Numeric_Haskell:_A_Repa_Tutorial
- tome 9y ago> Lots of valid code, won't pass the type checker Perhaps you could give us an example of code you want to write that doesn't pass the type checker. We already know about the case of maps, but it's been pointed out that is solved by row types. A different example would be good.