7 ms·

This kind of comment about Elm is quite hard to understand without context. Have you ever used a typed language before? Have you ever used a pure language befor

by spuz 10y ago

This kind of comment about Elm is quite hard to understand without context. Have you ever used a typed language before? Have you ever used a pure language before? Is there something special about Elm that gives you this kind of benefit, or do other languages do the same thing?

vittore 10y ago
Exactly what I wanted to ask. Can we mere developers have some context to it?
- seanjh 10y ago
  Haven't used Elm myself, but I assume this argument is based in large part on the strength of the Elm compiler error messages. For example: https://twitter.com/ID_AA_Carmack/status/735197548034412546 https://twitter.com/ID_AA_Carmack/status/735197548034412546
  - Semiapies 10y ago
    That's kind of amazing.
    - IanCal 10y ago
      Here are some more examples, though are generally more basic errors: http://elm-lang.org/blog/compilers-as-assistants http://elm-lang.org/blog/compilers-as-assistants Overall, I really like the approach of making error messages an important feature. We see them so often that improving them makes the developer experience much better, but I can imagine they're a less 'sexy' task to work on and probably much harder to get right than you'd expect.
athaeryn 10y ago
I've used typed languages, and pure ones, but what I've found to be really special about Elm is that the compiler is super helpful. This also makes learning the language really enjoyable, as you've got someone helping you along. :)
Tehnix 10y ago
Without having used Elm that much myself: One of its features is its very user friendly error messages. I imagine the author is comparing with more dynamically typed languages, where when you leave your work in the middle of something, there's usually a bit of digging when reopening it and continuing work, which he contrasts with Elm, where the compiler is quite excellent at reporting your unfinished work (in the form of helpful type errors), allowing you to quickly grasp at what point in your program you were at.
agentultra 10y ago
Not the author but I've had similar experiences. I haven't used Haskell or OCaml in my day job (though I would like to if given the opportunity). I have written some trivial and slightly serious programs in both of these languages. I've even worked up a few small programs in Agda. Elm, IMHO, is in a class of its own. There's a strong focus in the design of the language to be usable and friendly to the developer. The focus on structural typing, the error messages, and the tooling all go a long way to bring the developer from beginner to expert with as little friction as possible. In contrast I find this is the biggest hurdle for Haskell and OCaml. It's simple enough in either language to get started but there's a steep learning curve to becoming productive and the tooling, documentation, and even the design of the prelude libraries are the largest stumbling blocks for transitioning from an intermediate developer to an advanced one. update: grammar
orblivion 10y ago
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.
masklinn 10y ago
> Is there something special about Elm that gives you this kind of benefit Evan cares about compiler messages, and as a result Elm's compiler errors are the most friendly, readable, helpful and actionable messages I know of, even compared with projects with good error messages like Clang or Rust. Most other typed functional languages don't come even remotely close, best case scenario is they're fairly complete once you've learned to decrypt them, Elm's compiler error messages have almost no learning curve. Though it may help that Elm is wilfully limited abstraction-wise.
draw_down 10y ago
It's just "Elm is good and other languages are bad/not as good". I try to be live-and-let-live about such things.

by spuz 10y ago

vittore 10y ago

Exactly what I wanted to ask. Can we mere developers have some context to it?

seanjh 10y ago
Haven't used Elm myself, but I assume this argument is based in large part on the strength of the Elm compiler error messages. For example: https://twitter.com/ID_AA_Carmack/status/735197548034412546 https://twitter.com/ID_AA_Carmack/status/735197548034412546
- Semiapies 10y ago
  That's kind of amazing.
  - IanCal 10y ago
    Here are some more examples, though are generally more basic errors: http://elm-lang.org/blog/compilers-as-assistants http://elm-lang.org/blog/compilers-as-assistants Overall, I really like the approach of making error messages an important feature. We see them so often that improving them makes the developer experience much better, but I can imagine they're a less 'sexy' task to work on and probably much harder to get right than you'd expect.

athaeryn 10y ago

I've used typed languages, and pure ones, but what I've found to be really special about Elm is that the compiler is super helpful. This also makes learning the language really enjoyable, as you've got someone helping you along. :)

Tehnix 10y ago

Without having used Elm that much myself: One of its features is its very user friendly error messages. I imagine the author is comparing with more dynamically typed languages, where when you leave your work in the middle of something, there's usually a bit of digging when reopening it and continuing work, which he contrasts with Elm, where the compiler is quite excellent at reporting your unfinished work (in the form of helpful type errors), allowing you to quickly grasp at what point in your program you were at.

agentultra 10y ago

Not the author but I've had similar experiences. I haven't used Haskell or OCaml in my day job (though I would like to if given the opportunity). I have written some trivial and slightly serious programs in both of these languages. I've even worked up a few small programs in Agda. Elm, IMHO, is in a class of its own. There's a strong focus in the design of the language to be usable and friendly to the developer. The focus on structural typing, the error messages, and the tooling all go a long way to bring the developer from beginner to expert with as little friction as possible. In contrast I find this is the biggest hurdle for Haskell and OCaml. It's simple enough in either language to get started but there's a steep learning curve to becoming productive and the tooling, documentation, and even the design of the prelude libraries are the largest stumbling blocks for transitioning from an intermediate developer to an advanced one. update: grammar

orblivion 10y ago

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.

masklinn 10y ago

> Is there something special about Elm that gives you this kind of benefit Evan cares about compiler messages, and as a result Elm's compiler errors are the most friendly, readable, helpful and actionable messages I know of, even compared with projects with good error messages like Clang or Rust. Most other typed functional languages don't come even remotely close, best case scenario is they're fairly complete once you've learned to decrypt them, Elm's compiler error messages have almost no learning curve. Though it may help that Elm is wilfully limited abstraction-wise.

draw_down 10y ago

It's just "Elm is good and other languages are bad/not as good". I try to be live-and-let-live about such things.