News for hackers. Stuff that matters.
Re:The unreasonable effectiveness of print debugging by hawkice on Saturday April 24, 2021 @01:54PM (#26926877)
Print debugging not (really) working is haskell is... Non-idea, and a bad pairing for bad real debugging. But test cases are usually easier to figure out. Presumably there's a balance discovered by people in big projects but it never seemed as good as normal approaches to me.
Re:The unreasonable effectiveness of print debugging by corty on Saturday April 24, 2021 @02:18PM (#26927098)
Haskell debugging by testing is great for small functions where you can use quickcheck. But larger tests for the more complicated stuff don't work in quickcheck and there isn't much else that one can easily do.
Re:The unreasonable effectiveness of print debugging by Quekid5 on Saturday April 24, 2021 @03:36PM (#26927672)
Not sure what you mean, there's e.g. Tasty for non-QC testing. It can do all sorts of variations of test, e.g. traditional unit tests, "golden" tests, etc.
Re:The unreasonable effectiveness of print debugging by slaymaker1907 on Saturday April 24, 2021 @03:34PM (#26927659)
I haven't actually used quickcheck in Haskell, but I've used it for very complicated tests in other languages including Racket, TypeScript, Rust, and Java. The nicest thing about quickcheck is that it lets you easily create test data without imposing too many constraints on it. Regular fuzzing or randomized testing is almost as good, but the narrowing done by quickcheck is sometimes nice for understanding test failures.