9 ms·

But in Haskell you can get anything done :-)

tmptmp 10y ago
>>But in Haskell you can get anything done :-) Yeah, only if you are willing to spend anything (e.g. insanely large amounts of time) on it :( Please correct me if I am wrong, but for any large project, Haskell actually adds more woes (e.g. laziness induced problems, no good debugging support) than the ones it addresses. The Standard Chartered people had to invent a new language (mu) [1] which doesn't have laziness and the horrors associated with it. BTW, you can get anything done even in (any Turing complete) assembly language too! [1] http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf Edit: added the Standard Chartered example
- bbcbasic 10y ago
  Was just jokingly comparing Haskell which is general purpose to elm which is for the web only.
- 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 ago
      You don't need to do head [] but nulls are unavoidable in Java.
      - tmptmp 10y ago
        How 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 ago
        It'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.
- caconym_ 10y ago
  > Please correct me if I am wrong, but for any large project, Haskell actually adds more woes (e.g. laziness induced problems, no good debugging support) than the ones it addresses. If you want to make a blanket assertion like that, then the onus is on you to provide some evidence of it. The fact that a strict dialect of Haskell exists somewhere in the world and is being used for application X is interesting, but it does not support your claim about Haskell's viability as a general-purpose language.
- tome 10y ago
  > The Standard Chartered people had to invent a new language (mu) [1] which doesn't have laziness and the horrors associated with it. This is a terrible myth that needs to die. Mu is strict because it was designed to target a pre-existing strict runtime. Nothing at all to do with any perceived downsides of laziness, including space leaks.

>>But in Haskell you can get anything done :-) Yeah, only if you are willing to spend anything (e.g. insanely large amounts of time) on it :( Please correct me if I am wrong, but for any large project, Haskell actually adds more woes (e.g. laziness induced problems, no good debugging support) than the ones it addresses. The Standard Chartered people had to invent a new language (mu) [1] which doesn't have laziness and the horrors associated with it. BTW, you can get anything done even in (any Turing complete) assembly language too! [1] http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf Edit: added the Standard Chartered example

bbcbasic 10y ago
Was just jokingly comparing Haskell which is general purpose to elm which is for the web only.
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 ago
    You don't need to do head [] but nulls are unavoidable in Java.
    - tmptmp 10y ago
      How 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 ago
        It'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.
caconym_ 10y ago
> Please correct me if I am wrong, but for any large project, Haskell actually adds more woes (e.g. laziness induced problems, no good debugging support) than the ones it addresses. If you want to make a blanket assertion like that, then the onus is on you to provide some evidence of it. The fact that a strict dialect of Haskell exists somewhere in the world and is being used for application X is interesting, but it does not support your claim about Haskell's viability as a general-purpose language.
tome 10y ago
> The Standard Chartered people had to invent a new language (mu) [1] which doesn't have laziness and the horrors associated with it. This is a terrible myth that needs to die. Mu is strict because it was designed to target a pre-existing strict runtime. Nothing at all to do with any perceived downsides of laziness, including space leaks.