I'd be much more interested in needing less unit tests with stronger typing than avoiding needing stronger typing by writing more unit tests. The former seems like much less work.
Analysis of whether unit testing obviates static type checking (2012)
11–20 of 65 posts
Re: Analysis of whether unit testing obviates static type checking (2012)
#12Hasn't this long been settled? See e.g. https://www.destroyallsoftware.com/talks/ideology . Spoiler alert: We need both.
Re: Analysis of whether unit testing obviates static type checking (2012)
#13Original title: Unit testing isn't enough. You need static typing too. From 2012.
It goes the other way, too. There are definitely people out there that don't write tests because they think types save you from that.
Re: Analysis of whether unit testing obviates static type checking (2012)
#14The blog sets up to address the "claim by proponents of dynamically typed programming languages" that "once you have unit testing static type checking is redundant". This is a strawman and I'm fairly sure it was a strawman in 2012 as well. The more interesting claim, which this blog post doesn't address, is that dynamic typing plus unit testing lets you produce working programs faster, without having to wrestle a typ…
> The blog sets up to address the "claim by proponents of dynamically typed programming languages" that "once you have unit testing static type checking is redundant". This is a strawman and I'm fairly sure it was a strawman in 2012 as well.
In the past year I've seen at least half a dozen posts here on HN making this exact claim. Now I kind of wish I'd saved a few.
Re: Analysis of whether unit testing obviates static type checking (2012)
#15Original title: Unit testing isn't enough. You need static typing too. From 2012.
Not that unit testing is enough, but the unit testing that these projects happened to do isn't enough. I suggest that testing that's enough to have confidence that a non-trivial program is correct is going to cover just about everything static type checking could find as well (except in dead code, and how does that matter?) Or, to put it another way, if you didn't care enough about the correctness of your code to tes…
Enough unit testing will test everything the type system can. However, that is way more work than a good type system.
Re: Analysis of whether unit testing obviates static type checking (2012)
#16The answer is no.
Re: Analysis of whether unit testing obviates static type checking (2012)
#17The blog sets up to address the "claim by proponents of dynamically typed programming languages" that "once you have unit testing static type checking is redundant". This is a strawman and I'm fairly sure it was a strawman in 2012 as well. The more interesting claim, which this blog post doesn't address, is that dynamic typing plus unit testing lets you produce working programs faster, without having to wrestle a typ…
> "once you have unit testing static type checking is redundant"
I have seen literally that exact claim, word-for-word, from people who it seems reasonable to characterize as (rather zealous) "proponents of dynamically typed programming languages". It might be a weak man[0][1], but it's definitely not a straw man.
0: https://slatestarcodex.com/2014/11/03/all-in-all-another-bri...
1: https://slatestarcodex.com/2014/05/12/weak-men-are-superweap...
Re: Analysis of whether unit testing obviates static type checking (2012)
#18Yes, but is either going to save you from building the wrong features?
Paraphrasing Ed Catmull in his book Creativity Inc, the cost of preventing errors is usually much higher than the cost of fixing them.
Re: Analysis of whether unit testing obviates static type checking (2012)
#19The better the type system is, the more bugs it prevents, so one has to spend less time unit testing. Sadly, it also means the language is harder to learn, so the rest of us are stuck with horrible, unsafe languages.
This hasn't exactly been my experience, Python isn't easier to learn than e.g. Java because of the lack of static typing, it's easier because the language is more expressive.
I actually think there is literally no downside to making typing opt out rather than opt in - beginners benefit from the compiler saying they accidentally swapped two arguments around - how could they not?
I have helped beginners with untyped Python codebases and it's a lot harder to tell what function parameters are supposed to be than in Java or C++, leaving aside any other considerations.
Re: Analysis of whether unit testing obviates static type checking (2012)
#20Yes, but is either going to save you from building the wrong features? Paraphrasing Ed Catmull in his book Creativity Inc, the cost of preventing errors is usually much higher than the cost of fixing them.
I haven’t read that book, so I will, but that sounds like it would only be true if you don’t modify the code repeatedly.