2 ms·

The question I find interesting is whether type systems are an efficient way to buy reliability relative to other ways to purchase reliability, such as writing

The question I find interesting is whether type systems are an efficient way to buy reliability relative to other ways to purchase reliability, such as writing tests, doing code review, or enforcing immutability. Of course, some programmers just don't care about purchasing reliability. Those are the ones who eschew type systems, and tests, and produce unreliable software, about like you'd expect. But for my purposes, this is besides the point.

bluGill 1y ago
I find they are valuable. When you have a small program - 10k lines of code you don't really need them. However when you are at more than 10 million lines of code types find a lot of little errors that writing the correct test for would be hard. Most dynamically typed languages (all that I have worked with) cannot catch that you misspelled a function name until that function is called. If that misspelled function is in an error path it would be very easy to never test it until a customer hit the crash. Just having your function names as a strong type that is checked by static analysis (need not be a compiler though that is what everything uses) is a big win. Checking the other arguments as well is similarly helpful.
- 0xDEAFBEAD 1y ago
  Thanks for the reply! Technically, I would say that you should just write a test for the error path. I also tend to think that finding bugs at compile time is not actually that much better than finding them at runtime. If you have good monitoring (which you should have), and a customer triggers the bug at runtime, you can fix the bug then. A customer triggering a rare bug once isn't the end of the world. My sense is that people are very keen to find bugs at compile time rather than run time, but I haven't been generally able to figure out why this matters, unless you're working on some sort of real-time embedded system. What matters to me is the probability of spotting the bug, not when it is spotted. I suppose perhaps data corruption could be a concern with runtime errors? I would argue you should work to be robust against that anyways, by using atomic transactions as necessary. I'm most interested in subtler bugs which don't trigger exceptions at runtime. Those are the sort of bugs which will get executed over and over in production if they aren't prevented. It seems to me that static analysis doesn't do much to prevent these bugs, but tests can be really helpful. I will grant that implicit type conversions can lead to subtle runtime bugs. I see that as a separate issue however. I've worked most with Python, which doesn't do static analysis, but also enforces types at runtime. That seems fairly ideal to me. Interested to hear your perspective!
  - bluGill 1y ago
    I'm guessing you don't work on programs with millions of lines of code. What you say makes perfect sense for programs that are only a few thousand lines wrong. Nothing wrong with small programs, there are a lot of useful programs that only need to be that long. However when you start writing something more complex you need all the help you can get, and suddenly tests become a valueable way to ensure you don't break some working feature when you add the next.
    - 0xDEAFBEAD 1y ago
      I think you might be getting mixed up. I'm the one advocating tests. You've been advocating types :-)

bluGill 1y ago

I find they are valuable. When you have a small program - 10k lines of code you don't really need them. However when you are at more than 10 million lines of code types find a lot of little errors that writing the correct test for would be hard. Most dynamically typed languages (all that I have worked with) cannot catch that you misspelled a function name until that function is called. If that misspelled function is in an error path it would be very easy to never test it until a customer hit the crash. Just having your function names as a strong type that is checked by static analysis (need not be a compiler though that is what everything uses) is a big win. Checking the other arguments as well is similarly helpful.

0xDEAFBEAD 1y ago
Thanks for the reply! Technically, I would say that you should just write a test for the error path. I also tend to think that finding bugs at compile time is not actually that much better than finding them at runtime. If you have good monitoring (which you should have), and a customer triggers the bug at runtime, you can fix the bug then. A customer triggering a rare bug once isn't the end of the world. My sense is that people are very keen to find bugs at compile time rather than run time, but I haven't been generally able to figure out why this matters, unless you're working on some sort of real-time embedded system. What matters to me is the probability of spotting the bug, not when it is spotted. I suppose perhaps data corruption could be a concern with runtime errors? I would argue you should work to be robust against that anyways, by using atomic transactions as necessary. I'm most interested in subtler bugs which don't trigger exceptions at runtime. Those are the sort of bugs which will get executed over and over in production if they aren't prevented. It seems to me that static analysis doesn't do much to prevent these bugs, but tests can be really helpful. I will grant that implicit type conversions can lead to subtle runtime bugs. I see that as a separate issue however. I've worked most with Python, which doesn't do static analysis, but also enforces types at runtime. That seems fairly ideal to me. Interested to hear your perspective!
- bluGill 1y ago
  I'm guessing you don't work on programs with millions of lines of code. What you say makes perfect sense for programs that are only a few thousand lines wrong. Nothing wrong with small programs, there are a lot of useful programs that only need to be that long. However when you start writing something more complex you need all the help you can get, and suddenly tests become a valueable way to ensure you don't break some working feature when you add the next.
  - 0xDEAFBEAD 1y ago
    I think you might be getting mixed up. I'm the one advocating tests. You've been advocating types :-)