Comment by lmm | Hacker News Reader

Comment by lmm | Hacker News Reader

Parent Full thread

> I feel there should be a counter-article along the lines of "Unit testing and static code analysis conservatively prevent 80% of the bugs".

We need to talk about costs though. If a type system lets you write 15% fewer unit tests, it's worth it for that alone.

> There are static code analyzers (eg. tern.js) that provide hinting without requiring a transpiler

A static analyser is already a type system. You need a way to hint to the analyser, at which point you've got a notation for types in your language as well (maybe a limited one). You want the analyser to run on every build anyway, so a transpiler is no more effort; if you make the analyser optional developers will skip it, and will introduce bugs as a result, so it's better to simply not have the option.

> With Flow and Typescript you have transpiler overhead, but when it comes to places you might need them the most - checking and sanitizing data interchange that's so common in modular, service-oriented architecture - they fall flat.

You need to use types on the interfaces too. Use something like thrift.

Alright, costs. I think it's not well advised to use a type system as reason not to write unit tests. It seems to be a common misconception that static types are a replacement for testing. I think the real question is can you afford not to write unit tests that exercise functions with invalid arguments. I think it's still worthwhile because, like I said, you can have code where all the type constraints are satisfied but become violated by ingested data. You probably shouldn't assume that every user of your code is going to use thrift or graphql or whatever.

I think it's a stretch to say a static analyzer is "a type system". It doesn't obviate runtime type checking and implicit type conversion. But yes, absolutely you should run it on every build.

> I think it's not well advised to use a type system as reason not to write unit tests. It seems to be a common misconception that static types are a replacement for testing.

Of course they are: whatever your acceptable defect rate, both types and tests are ways to spend effort towards achieving it. The more defects you can eliminate via one, the less you need to catch via the other.

> I think it's still worthwhile because, like I said, you can have code where all the type constraints are satisfied but become violated by ingested data.

Most languages won't allow that to propagate through the system, and if you get an error at the boundary then it's obvious what the error is. (Admittedly a compile-to-Javascript language is the example here and may be the exception).

Fundamentally you decide how likely certain classes of errors are and look at the cost/benefit of the various measures available to you. In my experience types can, when you commit to them and work with them, reduce the defect rate very close to zero, and more cheaply than any other measure; I only feel the need to supplement them with tests very occasionally, and only for the very core parts of the code where defects would be most expensive.

> I think it's a stretch to say a static analyzer is "a type system". It doesn't obviate runtime type checking and implicit type conversion.

In terms of the mechanics of what it does, it's a type system. I don't see any value in having two type systems for the same code - type systems work better if they're part of the language so that all of the tools understand the same types the same way - so I prefer to use a language where the language type system covers all the use cases that a static analyzer might be helpful for.

Reply on news.ycombinator.com