6 ms·

Haskell does the same thing. EDIT: I didn't mean to say that Haskell is as easy, or that the error messages are as good. I just mean that the error messages ca

Haskell does the same thing. EDIT: I didn't mean to say that Haskell is as easy, or that the error messages are as good. I just mean that the error messages can give you a nice reminder of what you were working on, which I believe was the point of this post.

baldfat 10y ago
Really? Having dipped my toes in both I certainly felt like the error messages of the compiler to be very different. I could be way off.
skybrian 10y ago
Haskell had poor error messages last I tried it. Have they improved?
- orblivion 10y ago
  I didn't think that ease of understanding was necessarily the point. My point was that once you do understand them, it sort of tells you what to do next. That said, in a recent HN post somebody said that the latest version of GHC has better error messages, which I agree would be welcome, but I haven't tried it.
- danpalmer 10y ago
  Haskell has... precise... error messages. As I learn more about it, the errors are become more useful, and driving my development in a similar way to with Elm, however with Elm the learning curve is far shallower and the compiler helps you up it, whereas with Haskell I'm always just googling types to figure out what the compiler is trying to tell me.
  - thinkpad20 10y ago
    Many of the error messages become clearer with experience, but this is mostly due to developing an intuition for what is actually wrong with your code based on the error message you see, not due to the helpfulness of the error message. Often the actual source of the error is in a different place than what is reported. Consider what happens if you mean to concatenate two strings but forget to put `++` in there: Prelude> "foo" "bar" <interactive>:3:1: Couldn't match expected type ‘[Char] -> t’ with actual type ‘[Char]’ Relevant bindings include it :: t (bound at <interactive>:3:1) The function ‘"foo"’ is applied to one argument, but its type ‘[Char]’ has none In the expression: "foo" "bar" In an equation for ‘it’: it = "foo" "bar" Yikes. Even worse, consider a similar situation with numbers: Prelude> 1 2 <interactive>:2:1: Non type-variable argument in the constraint: Num (a -> t) (Use FlexibleContexts to permit this) When checking that ‘it’ has the inferred type it :: forall a t. (Num a, Num (a -> t)) => t Also the parser errors in Haskell are terrible. That the community has so long put up with "parse error (possibly incorrect indentation or mismatched brackets)" is a marvel to me, and is one of the most irritating errors to fix because of the (at least apparent) simplicity of improving it.
    - HelloNurse 10y ago
      The first error message is good: it helpfully includes the exact expression that craps out, and it means, matching intuition about how Haskell should be compiled, that the expression "foo" "bar" could only make sense if "foo" were a function from [Char] (i.e. the type of "bar") to some type t, but unfortunately "foo" is a [Char]: everyone should understand it easily, even if gratuitously introducing other names (it and its type t) and details about the compiler making up type equations is highly inelegant. The second error message, on the other hand, proves that the first one is a lucky accident.
      - AlexCoventry 10y ago
        Everything you say is true, but it took me about 90s of staring at the Haskell error before I parsed out exactly what it was objecting to, even though I knew exactly how the code was broken. Whereas it took me no discernible time to understand the Elm error messages. Some of it could be that parsing the Haskell message primed me for the Elm message, but it doesn't seem that way to me.
      - MustardTiger 10y ago
        >The second error message, on the other hand, proves that the first one is a lucky accident. No, the second error message just shows that there's more options there so the error message is vague and not very helpful. The first one is not an accident, it is the standard type mismatch error.
        HelloNurse 10y ago
        My point is that 1 2 should give the same type of error message as "foo" "bar", because it is the same kind of error (1 isn't a function with one or more arguments). The compiler exposes that when numbers are involved it attempts (and fails) some fancy and unexpected reasoning involving forall, while with plain type constructors like [Char] it attempts (and fails) straightforward and intelligible pattern matching. Figuring out the type of 1 and 2 might be more difficult than figuring out the type of "foo" and "bar", but the special rules should be hidden: a compiler that cares about practical usage would provide unified and clear error messages, possibly listing sets of alternative types it was unable to choose from.
the_gipsy 10y ago
No, Elm is definitely less complex and generally targetted for newcomers to the FP and pure world. In haskell there are like a 100 ways of doing anything and it's very hard (for me at least) to figure out where even to begin. Elm tries to reduce options and lets noobs like me get going.
- MustardTiger 10y ago
  It seemed to me like elm reduced options all the way to zero for way too many things. Trying to do basic tasks that are trivial in ocaml and haskell ended up with me giving up completely when trying in elm. Just generating random sequences was ridiculous.
  - spuz 10y ago
    For what it's worth, generating random values is slightly easier with the introduction of subscriptions in 0.17. If that's the version you tried, it would be nice to see why you think Elm is unnecessarily complex compared to Haskell (which is also pure) when it comes to generating random values.
    - MustardTiger 10y ago
      >If that's the version you tried No, it was a couple years ago. >compared to Haskell (which is also pure) But which has both a real type system and a useful set of base libraries. The lack of basic stuff like monads is really painful in elm.

baldfat 10y ago

Really? Having dipped my toes in both I certainly felt like the error messages of the compiler to be very different. I could be way off.

skybrian 10y ago

Haskell had poor error messages last I tried it. Have they improved?

orblivion 10y ago
I didn't think that ease of understanding was necessarily the point. My point was that once you do understand them, it sort of tells you what to do next. That said, in a recent HN post somebody said that the latest version of GHC has better error messages, which I agree would be welcome, but I haven't tried it.
danpalmer 10y ago
Haskell has... precise... error messages. As I learn more about it, the errors are become more useful, and driving my development in a similar way to with Elm, however with Elm the learning curve is far shallower and the compiler helps you up it, whereas with Haskell I'm always just googling types to figure out what the compiler is trying to tell me.
- thinkpad20 10y ago
  Many of the error messages become clearer with experience, but this is mostly due to developing an intuition for what is actually wrong with your code based on the error message you see, not due to the helpfulness of the error message. Often the actual source of the error is in a different place than what is reported. Consider what happens if you mean to concatenate two strings but forget to put `++` in there: Prelude> "foo" "bar" <interactive>:3:1: Couldn't match expected type ‘[Char] -> t’ with actual type ‘[Char]’ Relevant bindings include it :: t (bound at <interactive>:3:1) The function ‘"foo"’ is applied to one argument, but its type ‘[Char]’ has none In the expression: "foo" "bar" In an equation for ‘it’: it = "foo" "bar" Yikes. Even worse, consider a similar situation with numbers: Prelude> 1 2 <interactive>:2:1: Non type-variable argument in the constraint: Num (a -> t) (Use FlexibleContexts to permit this) When checking that ‘it’ has the inferred type it :: forall a t. (Num a, Num (a -> t)) => t Also the parser errors in Haskell are terrible. That the community has so long put up with "parse error (possibly incorrect indentation or mismatched brackets)" is a marvel to me, and is one of the most irritating errors to fix because of the (at least apparent) simplicity of improving it.
  - HelloNurse 10y ago
    The first error message is good: it helpfully includes the exact expression that craps out, and it means, matching intuition about how Haskell should be compiled, that the expression "foo" "bar" could only make sense if "foo" were a function from [Char] (i.e. the type of "bar") to some type t, but unfortunately "foo" is a [Char]: everyone should understand it easily, even if gratuitously introducing other names (it and its type t) and details about the compiler making up type equations is highly inelegant. The second error message, on the other hand, proves that the first one is a lucky accident.
    - AlexCoventry 10y ago
      Everything you say is true, but it took me about 90s of staring at the Haskell error before I parsed out exactly what it was objecting to, even though I knew exactly how the code was broken. Whereas it took me no discernible time to understand the Elm error messages. Some of it could be that parsing the Haskell message primed me for the Elm message, but it doesn't seem that way to me.
    - MustardTiger 10y ago
      >The second error message, on the other hand, proves that the first one is a lucky accident. No, the second error message just shows that there's more options there so the error message is vague and not very helpful. The first one is not an accident, it is the standard type mismatch error.
      - HelloNurse 10y ago
        My point is that 1 2 should give the same type of error message as "foo" "bar", because it is the same kind of error (1 isn't a function with one or more arguments). The compiler exposes that when numbers are involved it attempts (and fails) some fancy and unexpected reasoning involving forall, while with plain type constructors like [Char] it attempts (and fails) straightforward and intelligible pattern matching. Figuring out the type of 1 and 2 might be more difficult than figuring out the type of "foo" and "bar", but the special rules should be hidden: a compiler that cares about practical usage would provide unified and clear error messages, possibly listing sets of alternative types it was unable to choose from.

the_gipsy 10y ago

No, Elm is definitely less complex and generally targetted for newcomers to the FP and pure world. In haskell there are like a 100 ways of doing anything and it's very hard (for me at least) to figure out where even to begin. Elm tries to reduce options and lets noobs like me get going.

MustardTiger 10y ago
It seemed to me like elm reduced options all the way to zero for way too many things. Trying to do basic tasks that are trivial in ocaml and haskell ended up with me giving up completely when trying in elm. Just generating random sequences was ridiculous.
- spuz 10y ago
  For what it's worth, generating random values is slightly easier with the introduction of subscriptions in 0.17. If that's the version you tried, it would be nice to see why you think Elm is unnecessarily complex compared to Haskell (which is also pure) when it comes to generating random values.
  - MustardTiger 10y ago
    >If that's the version you tried No, it was a couple years ago. >compared to Haskell (which is also pure) But which has both a real type system and a useful set of base libraries. The lack of basic stuff like monads is really painful in elm.