5 ms·

I think i'm missing something. On slide 4 it says (the code) it has 0 exceptions and is robust, but then on slide 7 it says that (the system) it crashes without

I think i'm missing something. On slide 4 it says (the code) it has 0 exceptions and is robust, but then on slide 7 it says that (the system) it crashes without stack traces? Is that right? What did the OP meant by being robust, when the code crashes unexpectedly?

Guvante 13y ago
Likely that is referring to the fact that when it crashes, it crashes in a way that can be interesting to debug. I took it as a comment about development vs one about production.
- emilv 13y ago
  "can be interesting to debug" sounds scary :-)
  - dons 13y ago
    Lazy languages don't have equivalent call stacks as strict languages. However, GHC lets you get a stack trace via profiling. E.g. +RTS -xc flag gives a stack trace.
    - enigmo 13y ago
      The actual evaluation stack (re: GHC w/ DWARF symbols) is also quite useful for debugging and doesn't need a profiled executable to work.
alipang 13y ago
In Haskell one typically eschews exceptions in favor of for instance the Error monad, as you don't get a typical stack trace in a lazily evaluated language. Probably they have experienced some exception during development, but have had no exeptions in productin.
bermanoid 13y ago
The cynic in me says that unless Haskell has a magical "do the right thing in every situation, with automatic full knowledge of your application's business requirements" operator, if there's no specific logic in the code that responds to errors, they're just ignoring them (or else they're building a very bare bones app - any nontrivial piece of software will have potential error conditions out of its control that it has to react to in very specific ways that depend on the app itself). In which case I could produce an equally "robust" Java program by wrapping everything in a try/catch and not logging anything. Except that in Java, or just about any other language, with a single method call I could obtain that elusive stack trace that OP is sorely missing. Which, in real applications (which, to be fair, I've never been masochistic enough to write in Haskell), I always do, and it significantly improves our ability to track down the remaining unanticipated conditions that our error handling logic hasn't already handled in well defined ways. And that sort of work should consume most of anyone's time spent developing, because the happy path is the easiest piece of the puzzle - engineers handle all code paths, hackers handle the most important ones, and hacks only handle the best case scenarios. I'm not really getting what Haskell has helped here, apart from making the article more upvote-able. That said, the presentation slides don't give me even a vague sense what the real thrust of the presentation was, so I'm probably missing the substance. I take issue with this being posted without any additional context, but I'll grant the benefit of the doubt and assume that there may actually have been something worth listening to if we didn't just have the slides to look at.
- DanWaterworth 13y ago
  Haskell doesn't need a magical "do the right thing" operator. What it does instead is constantly nag you, saying, "but you haven't considered this case". This causes you to think about you code in much more depth and generally leads to good results without the need to constantly debug. I find that things written in Haskell that compile generally work first time more often than the law of averages would seem to allow.
- tel 13y ago
  Exception in Haskell is more specific than in other languages. There are many ways to have "unexpected circumstances" such as Maybe, Either, Error, Mplus, Alternative, and the transformer variants thereof. Exceptions refer explicitly to "asynchronous" exceptions—the kind in most other languages, that imply global changes in control flow that are difficult to reason about. People tend to avoid this behavior except in rare circumstances. That said, it's easy to replicate locally with the Cont monad. These local reflows are easier to reason about as well. You can even build it atop delimited continuations for more control. These are great for covering early stopping in searches, for instance.
gtani 13y ago
I think s7 was emphasizing issues getting what strict/eagerly evaluated languages refer to as stacktraces http://hackage.haskell.org/trac/ghc/ticket/3693 http://hackage.haskell.org/trac/ghc/ticket/3693 http://www.haskell.org/wikiupload/6/6c/Hiw2012-simon-marlow.pdf http://www.haskell.org/wikiupload/6/6c/Hiw2012-simon-marlow....
- gtani 13y ago
  [ed] oops, nevermind, see dons' post above re:"+RTS -xc", probably shd mark the trac ticket superceded or something

Guvante 13y ago

Likely that is referring to the fact that when it crashes, it crashes in a way that can be interesting to debug. I took it as a comment about development vs one about production.

emilv 13y ago
"can be interesting to debug" sounds scary :-)
- dons 13y ago
  Lazy languages don't have equivalent call stacks as strict languages. However, GHC lets you get a stack trace via profiling. E.g. +RTS -xc flag gives a stack trace.
  - enigmo 13y ago
    The actual evaluation stack (re: GHC w/ DWARF symbols) is also quite useful for debugging and doesn't need a profiled executable to work.

alipang 13y ago

In Haskell one typically eschews exceptions in favor of for instance the Error monad, as you don't get a typical stack trace in a lazily evaluated language. Probably they have experienced some exception during development, but have had no exeptions in productin.

bermanoid 13y ago

The cynic in me says that unless Haskell has a magical "do the right thing in every situation, with automatic full knowledge of your application's business requirements" operator, if there's no specific logic in the code that responds to errors, they're just ignoring them (or else they're building a very bare bones app - any nontrivial piece of software will have potential error conditions out of its control that it has to react to in very specific ways that depend on the app itself). In which case I could produce an equally "robust" Java program by wrapping everything in a try/catch and not logging anything. Except that in Java, or just about any other language, with a single method call I could obtain that elusive stack trace that OP is sorely missing. Which, in real applications (which, to be fair, I've never been masochistic enough to write in Haskell), I always do, and it significantly improves our ability to track down the remaining unanticipated conditions that our error handling logic hasn't already handled in well defined ways. And that sort of work should consume most of anyone's time spent developing, because the happy path is the easiest piece of the puzzle - engineers handle all code paths, hackers handle the most important ones, and hacks only handle the best case scenarios. I'm not really getting what Haskell has helped here, apart from making the article more upvote-able. That said, the presentation slides don't give me even a vague sense what the real thrust of the presentation was, so I'm probably missing the substance. I take issue with this being posted without any additional context, but I'll grant the benefit of the doubt and assume that there may actually have been something worth listening to if we didn't just have the slides to look at.

DanWaterworth 13y ago
Haskell doesn't need a magical "do the right thing" operator. What it does instead is constantly nag you, saying, "but you haven't considered this case". This causes you to think about you code in much more depth and generally leads to good results without the need to constantly debug. I find that things written in Haskell that compile generally work first time more often than the law of averages would seem to allow.
tel 13y ago
Exception in Haskell is more specific than in other languages. There are many ways to have "unexpected circumstances" such as Maybe, Either, Error, Mplus, Alternative, and the transformer variants thereof. Exceptions refer explicitly to "asynchronous" exceptions—the kind in most other languages, that imply global changes in control flow that are difficult to reason about. People tend to avoid this behavior except in rare circumstances. That said, it's easy to replicate locally with the Cont monad. These local reflows are easier to reason about as well. You can even build it atop delimited continuations for more control. These are great for covering early stopping in searches, for instance.

gtani 13y ago

I think s7 was emphasizing issues getting what strict/eagerly evaluated languages refer to as stacktraces http://hackage.haskell.org/trac/ghc/ticket/3693 http://hackage.haskell.org/trac/ghc/ticket/3693 http://www.haskell.org/wikiupload/6/6c/Hiw2012-simon-marlow.pdf http://www.haskell.org/wikiupload/6/6c/Hiw2012-simon-marlow....

gtani 13y ago
[ed] oops, nevermind, see dons' post above re:"+RTS -xc", probably shd mark the trac ticket superceded or something