39 ms·

> I've worked on multiple large projects, and while type > errors are a problem, they aren't in the top 5 classes > of 'most commonly reported bugs in

by runeks 10y ago

> I've worked on multiple large projects, and while type > errors are a problem, they aren't in the top 5 classes > of 'most commonly reported bugs in production' - not > if you have tests and a sprinkling of sanity checks, anyhow. My claim is that Pythonists are completely unaware that almost all of the errors they experience could have been avoided by just informing the compiler about what type a value is. I find it peculiar that people prefer writing tests to verify type correctness (a lot of work), rather than just having the compiler check it through simple type annotations. I say this coming from Python, having moved to to Haskell. Two diametrically opposite worlds in terms of type strictness. I think sprinkling type annotations all over the code is much preferable to writing test code. We have a type system such that the compiler can produce the code needed to check types, rather than us having to write this code in a test. In my humble opinion, humans shouldn't have to write test code. If you can't get the compiler to generate the test code you want - by constructing the types carefully - you're wasting a lot of time, because you have to write both the implementation, and a second implementation which tests the first one. So every time you do a rewrite, you also have to rewrite your tests, so that the two match. Double work.

tome 10y ago
Having made the same switch from Python to Haskell I agree. However, I just wanted to temper your claim that "almost all of the errors" could be prevented by type systems. I think it's hard to measure errors in any way such that "almost all" is a valid claim, but "very many" certainly is!
crdoconnor 10y ago
>My claim is that Pythonists are completely unaware that almost all of the errors they experience could have been avoided by just informing the compiler about what type a value is. You literally didn't have to say anything else to let me know that you're a haskell developer :) My claim is that developers who habitually don't do TDD like the methadone hit that static type checking provides. I actually write very almost no tests to directly verify type correctness but I always write a test for any new behaviour.I implement. 95% of the type errors I do encounter indirectly come out in the process of writing tests that I would have written anyway in any language. >I think sprinkling type annotations all over the code is much preferable to writing test code. And I think if you're avoiding writing tests to define what your code should do you're a shoddy programmer. I've been sprinkling my programs with sanity checks and runtime type checks for a decade which has been more than sufficient at eliminating almost all bug-causing type issues the tests don't catch. This isn't something I even need to do often so any alternative to this process isn't going to yield me much of a productivity gain. >In my humble opinion, humans shouldn't have to write test code. If you can't get the compiler to generate the test code you want - by constructing the types carefully - you're wasting a lot of time, because you have to write both the implementation, and a second implementation which tests the first one. So every time you do a rewrite, you also have to rewrite your tests, so that the two match. Double work. Wherein you just indirectly addressed the biggest complaint people have with the haskell community - it's horrendously shitty documentation. You're supposed to figure out the behavior of libraries just by looking at the type. Good tests tell a story. The tests I write for libraries double as readable documentation for that library. The tests I write for applications double as readable executable specifications. This is a relatively new thing hampered somewhat by tooling issues but I think it'll catch on. For libraries that I use I often ignore the official documentation and treat the tests as documentation instead. Compilers can't do this for you. They don't know how your code is supposed to work. Ironically one of the best things to come out of the haskell community was quickcheck - a testing library.
- runeks 10y ago
  > And I think if you're avoiding writing tests to define > what your code should do you're a shoddy programmer. At the opposite end of the testing/no-testing spectrum would be the statement: if you can't look at your own code and see whether it does what you intend it to do, but need to write a test to make sure of this, your code is either of poor quality or you're not paying enough attention. I think both viewpoints have merit. But neither one paints the whole picture. Tests are useful to a certain degree, but since time is limited, it's all about striking the right balance between testing and no testing. You can always write more tests, but at some point it becomes more useful to just look at the code you're testing. And, conversely, you can always look at your code one extra time, but sometimes it's better to formalize your doubts into a test.

by runeks 10y ago

tome 10y ago

Having made the same switch from Python to Haskell I agree. However, I just wanted to temper your claim that "almost all of the errors" could be prevented by type systems. I think it's hard to measure errors in any way such that "almost all" is a valid claim, but "very many" certainly is!

crdoconnor 10y ago

>My claim is that Pythonists are completely unaware that almost all of the errors they experience could have been avoided by just informing the compiler about what type a value is. You literally didn't have to say anything else to let me know that you're a haskell developer :) My claim is that developers who habitually don't do TDD like the methadone hit that static type checking provides. I actually write very almost no tests to directly verify type correctness but I always write a test for any new behaviour.I implement. 95% of the type errors I do encounter indirectly come out in the process of writing tests that I would have written anyway in any language. >I think sprinkling type annotations all over the code is much preferable to writing test code. And I think if you're avoiding writing tests to define what your code should do you're a shoddy programmer. I've been sprinkling my programs with sanity checks and runtime type checks for a decade which has been more than sufficient at eliminating almost all bug-causing type issues the tests don't catch. This isn't something I even need to do often so any alternative to this process isn't going to yield me much of a productivity gain. >In my humble opinion, humans shouldn't have to write test code. If you can't get the compiler to generate the test code you want - by constructing the types carefully - you're wasting a lot of time, because you have to write both the implementation, and a second implementation which tests the first one. So every time you do a rewrite, you also have to rewrite your tests, so that the two match. Double work. Wherein you just indirectly addressed the biggest complaint people have with the haskell community - it's horrendously shitty documentation. You're supposed to figure out the behavior of libraries just by looking at the type. Good tests tell a story. The tests I write for libraries double as readable documentation for that library. The tests I write for applications double as readable executable specifications. This is a relatively new thing hampered somewhat by tooling issues but I think it'll catch on. For libraries that I use I often ignore the official documentation and treat the tests as documentation instead. Compilers can't do this for you. They don't know how your code is supposed to work. Ironically one of the best things to come out of the haskell community was quickcheck - a testing library.

runeks 10y ago
> And I think if you're avoiding writing tests to define > what your code should do you're a shoddy programmer. At the opposite end of the testing/no-testing spectrum would be the statement: if you can't look at your own code and see whether it does what you intend it to do, but need to write a test to make sure of this, your code is either of poor quality or you're not paying enough attention. I think both viewpoints have merit. But neither one paints the whole picture. Tests are useful to a certain degree, but since time is limited, it's all about striking the right balance between testing and no testing. You can always write more tests, but at some point it becomes more useful to just look at the code you're testing. And, conversely, you can always look at your code one extra time, but sometimes it's better to formalize your doubts into a test.