3 ms·
>laziness induced problems This is like saying that Java has "strictness induced problems". It's true, but probably disingenuous. Obviously large, well-funded
by wyager 10y ago
>laziness induced problems
This is like saying that Java has "strictness induced problems". It's true, but probably disingenuous. Obviously large, well-funded strict object-oriented projects have memory leak problems as well (all browsers).
> no good debugging support
One generally doesn't require as much debugging support for Haskell, but it's actually quite nice if you follow a debugging process amenable to pure functional languages. People coming from a Java background want e.g. a breakpoint debugger, which doesn't really make any sense at all in a pure functional language; a vastly superior approach is to do e.g. quickcheck-style checking or input/output debugging on pure functions. If your code is impure, you can essentially debug like normal.
Bugs in Haskell also aren't the same as most of the bugs in other languages; you never get null pointers, for example. Every bug in Haskell is either a logic bug (which can often be debugged purely, and can be minimized by the careful application of types) or an atotality bug (which can be completely avoided by totality/completeness checking, and dynamic debugging of such bugs is getting much better with the new implicit callstack feature added to recent versions of GHC).
- phamilton 10y ago> you never get null pointers To me, head [] is basically a null pointer.
- bbcbasic 10y agoYou don't need to do head [] but nulls are unavoidable in Java.
- tmptmp 10y agoHow can I be sure that some lazy code (may be from some library) may not encounter "head []" at all? Of course, I can avoid that by avoiding all such libraries. Another painful thing is the exception handling is also not as clean and clear as, say Java/Python exception handling, AFAIK. Please correct me if I am wrong here, and I will be a happy camper. In fact, I love Haskell as it has taught me how to think clearly. But I am scary to use it in production, sorry for that.
- wyager 10y agoIt's actually quite easy. Enable the completeness checker. It won't let you use head, because it's incomplete. In other words, it will say "stop using head". What this entails practically is something like a) using safe head, which has type [a] -> Maybe a, or b) using the non-empty list type, or c) using streams, which don't have an empty constructor. There are lots of things you can do, but the general approach is "use pattern matching to cover all cases". The compiler can tell you if you've done this or not, and it you do your program will never crash. >Another painful thing is the exception handling is also not as clean and clear as, say Java/Python exception handling, AFAIK. Monadic exception handling is 100x easier than in Java or Python. Java copied Haskell/ML's use of Maybe/Optional for avoiding null pointers in Java 8, but they haven't yet figured out Haskell's use of Either and friends for exception handling. Handling true exceptions in Haskell outside of IO code is worse than in Java, which is probably what you're thinking of, but most code bases completely avoid it. It's not hard at all. Handling true exceptions in IO is often nicer than Java, because Haskell has well-thought-out primitives like bracket.
- tome 10y ago> Enable the completeness checker. What's this "completeness checker"?
- dllthomas 10y agoTo my mind, it differs importantly in that `head []` is something you basically can't inspect, and so you don't wind up passing it as something meaningful expecting the other side to check for it. While I think this is an important difference, `head` is still harmful.