Unlikely. Maybe if you are using a language with a complete type system (let's face it, you are not), but otherwise you are necessarily going to have to encode all the type information into your tests anyway, so you haven't gained anything on this front. A partial type system cannot replace these tests.
I didn't say it catches all bugs. I said it catches lots of bugs, which it absolutely does.
It's literally impossible to write tests to find all bugs. Most tests don't come remotely close to that, so there's always going to be bugs that static type checks find that tests don't.
Also the fact static typing eliminates entire classes of bugs means you need to write far fewer tests. I've seen Python tests that literally fed different types into functions and verified that they accepted them. What a misguided waste of effort!
It is always telling when someone starts getting worked up about something, especially when that something wasn't even said or implied.
> Also the fact static typing eliminates entire classes of bugs means you need to write far fewer tests.
You don't need to write any more tests in the absence of static types. The purpose of testing is not to act as a replacement for static types and if you find yourself writing tests just for the sake of testing types, you know you're doing something horribly wrong. But, you necessarily have to encode type information into the tests in order of them to execute. After all, if that wasn't the case, you wouldn't even be able to catch bugs with a type system. As such, you gain that indirectly.
> I've seen Python tests that literally fed different types into functions and verified that they accepted them. What a misguided waste of effort!
Sure, I've seen developers do all kinds of stupid things too. In fact, give them Typescript and they will just litter the code with `any` everywhere – something I've witnessed far too often. There is no technical solution to bad developers. Was there supposed to be some meaningful takeaway here?
> You don't need to write any more tests in the absence of types.
To achieve the same level of quality, yes you absolutely do. This is actually a fairly fundamental fact about static typing. Static typing is a weak form of formal verification, or equivalently formal verification is just really really strong static typing. Clearly you don't need to write as many tests for formally verified code. The same is true (to a lesser extent) for "ordinary" static typing.
> Sure, I've seen developers do all kinds of stupid things too.
It's not stupid if you have a static typing system available! The stupidity was relying on tests to verify types, instead of ... you know, the thing whose whole purpose is to verify types.
> This is actually a fairly fundamental fact about static typing.
If you have a complete type system. But as we are specifically talking about partial type systems, you have to already cover all your bases for where the type system is lacking, and by virtue of that you are going to overlap with what the type system also covers.
> It's not stupid if you have a static typing system available!
There is no reason for it, static type system or not.
Complete, not Turing complete. How on earth did you manage to add an entire new meaning into the discussion that wasn't there before? I'm getting flashbacks of the earlier comment that started randomly going off on some weird tangent about how tests don't catch all bugs.
Anything to avoid the actual topic at hand, I guess?
Except you need to write the test first, else there is no way to ensure that your tests actually work and aren't passing because your tests have bugs. So what have you won, exactly?
It's much faster to find bugs because an IDE instantly underlines the exact line where the mistake is as you write it, than it is to write a load of code and then debug failing tests.
And as I said in the other comment, tests won't catch all of the mistakes that static typing will catch anyway.
If you have a complete type system, sure. Then you have constraint on the subtle mistakes one is likely to make.
The partial type systems found in languages people actually use, though, only constrain the most glaring of mistakes that you are almost never going to make. Not impossible that you could make one, but highly unlikely. Certainly not on the order of "lots". More like once in a blue moon.
Refactoring is a different story. Having an editor that lights up like a Christmas tree when code changes breaks existing relationships is a huge boon, and with good refactoring tools you almost never have to break the relationships in the first place. This is where (partial) static typing truly shines.
> the most glaring of mistakes that you are almost never going to make. Not impossible that you could make one, but highly unlikely. Certainly not on the order of "lots".
Not true. People make these mistakes all the time.
I was literally reviewing code today where someone write Python code to write a field that didn't exist. They didn't realise because they hadn't written a test. They asked me to check if it fixed my issue, which wasted 5 minutes of my time checking, when an IDE with static types would have told them their mistake instantly.
You can pull the "well I don't make mistakes" classic, but it doesn't matter. People do make these mistakes.
I linked an empirical study showing that 15% of bugs are precisely these mistakes. If you don't think it's worth eliminating 15% of bugs then frankly I just think you have crazy priorities and I can't really fix that.
> They didn't realise because they hadn't written a test.
If someone hates future developers so much that they wouldn't write a test, why would they suddenly take care to write proper types? I've worked with those kind of people before. The reality is that they won't define any specific types either, relying on `any` (or whatever the language's equivalent is) to minimize the social footprint.
> They asked me to check if it fixed my issue
I get you work with an asshole who hates other developers, but why would they need to ask if it solves your issue when they can just run the tests you wrote to assert the issue you discovered? Well, okay, being an asshole they maybe just wanted to see what meaningless busywork they could force you to do, but then why didn't you at least run your tests rather than spending minutes hunting up and down for something that your test would have found instantly? Something doesn't quite add up here.
> when an IDE with static types would have told them their mistake instantly.
And most likely even an IDE with type inference, a la the original article. Did you even apply a type checker when faced with this problem? It would be quite ironic if you didn't.
> when an IDE with static types would have told them their mistake instantly.
As would the test, at least for any developers who don't have an intense hatred for other developers.
Unlikely. Maybe if you are using a language with a complete type system (let's face it, you are not), but otherwise you are necessarily going to have to encode all the type information into your tests anyway, so you haven't gained anything on this front. A partial type system cannot replace these tests.
Your other points are the real wins, though.