3 ms·
The trick is to realize that the incremental incorrect output you get from the compiler is roughly equivalent to the incorrect output you'd get from the failed
by nimish 10y ago
The trick is to realize that the incremental incorrect output you get from the compiler is roughly equivalent to the incorrect output you'd get from the failed runtime.
Personally I'd start from smaller functions up but it's not like there's no feedback.
- Ericson2314 10y agoOr rather, you're going to need to fix that code anyways, so might as well use the thing that tells you what to do. I personally find fixing type errors far more enjoyable than debugging, and even if I didn't, I think one can argue that fixing type errors is a more predictable workflow and therefore contributes less uncertainty for time budgeting.
- cle 10y agoIf you're prototyping and exploring, most likely you're not going to need to fix that code anyways, so it would be a waste of time (unless you're already efficient with Haskell dev). I'm a big believer in exploring problem spaces with loose, flexible tools that let you get to the point ASAP and ignore unrelated stuff. If you're then going to build a long-lived, high-availability production system, then take what you learned and harden your design using tools built for long-lived, high-availability production systems (e.g. static typing, formal methods, etc.).
- Ericson2314 10y agoYeah I just don't recall a type error where the low chance of hitting it outways the cost of fixing it. The joy of good languages is closing the gap between prototyping and production, research and practice.