Elm has the best error messages of any language I have ever used.
I have dreams about it one day replacing JS as the front end language of choice.
Putting Down Elm
41–50 of 73 posts
Re: Putting Down Elm
#42Fell into the bait! Clicked and disappointed at a different content than expected
Re: Putting Down Elm
#43To me, the most promising thing about elm is how much improvement it has seen. The last minor version was a huge leap forward for building real things AND for beginners. The makers of elm (seems to mostly be Evan Czaplicki) think about things the same way I do, except they are thinking about it more than I do and more carefully. Whether it's elm or anything else, I'm glad the tool-explosion has let more people use tools they vibe with. Hopefully it will help more random people (like me) do more cool stuff.
Re: Putting Down Elm
#44The title is unfortunate. At first I though...wait why are they discontinuing Elm, what did I miss. I've never written anything in Elm but that short post makes me want to try it. Sounds like a pretty great feature of a language to have easy to follow error messages you can readily pick up. This also made me chuckle """I thought Elm was a pure, functional language, but this is one hell of a side effect."""
The error messages in Elm really are outstanding. I've never used a language that has such clear, concise, and human-friendly error messages. It's a high water mark, and I hope other programming languages are inspired to try to equal what Elm has accomplished.
Re: Putting Down Elm
#45Earlier quoted context omitted.
I think "gradual typing" like Flow might be a nice middle-ground. You're still free to quickly sketch out ideas without worrying about type checking, but you can solidify things by just adding /* @flow */ to the top of a file and fixing the errors. I haven't actually tried Elm though, so maybe a "middle-ground" isn't necessary.
This will sound counterintuitive to dynamic language people, but prototyping is actually much easier with types. I often find myself rewriting 50 to 75% of the codebase in the early stages of prototyping, and without types I'd be much less willing to do that, settling for a less than ideal design. This design will then be the base of a potentially large project, which amplifies early mistakes even more.
I think it's a matter of personality. Dynamic language people (to the extent there are such people... most of us use both) are generally not scared at all to change things. We're just more comfortable with the intervening chaos. For instance I might want to change some underlying model code without worrying that it breaks every single page in the site except the one I'm using to work on it, or the individual test. Sometimes I want to work on the heart of the matter first and clean up details later instead of working on the compiler's set of priorities.
Re: Putting Down Elm
#46Earlier quoted context omitted.
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.
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: Prelud…
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.
Re: Putting Down Elm
#47Earlier quoted context omitted.
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.
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: Prelud…
Not saying many Haskell compiler errors are obscure, especially for the uninitiated, but the particular error you picked as your first example is perfectly clear.
Haskell is telling you 'you tried to apply a string literal to an argument as if it were a function, but it's not! It's a string literal. By the way, the string I'm talking about is "foo", which you tried to apply to "bar" in the expression "foo bar"'.
Yikes? It seems pretty helpful to me :)
Your second example is better, though.
Re: Putting Down Elm
#48ok nice. We know that. I'm personally touching Elm only after they have something like ComponentDidMount from React or something which is better implementend than "wait 50msec and do something like set focus" on their (virtual) DOM rendering is solved: https://github.com/evancz/elm-todomvc/blob/8be8914582870d599...
Elm gives you the ability to hook into requestAnimationFrame, which allows you to execute some native js through a port when a piece of html first renders.
Re: Putting Down Elm
#49Earlier quoted context omitted.
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.
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: Prelud…
And that is exactly why people love Elm:
> "foo" "bar"
-- TYPE MISMATCH --------------------------------------------- repl-temp-000.elm
You are giving an argument to something that is not a function!
3| "foo" "bar"
^^^^^
Maybe you forgot some parentheses? Or a comma?
> "foo" + "bar"
-- TYPE MISMATCH --------------------------------------------- repl-temp-000.elm
The left argument of (+) is causing a type mismatch.
3| "foo" + "bar"
^^^^^
(+) is expecting the left argument to be a:
number
But the left argument is:
String
Hint: To append strings in Elm, you need to use the (++) operator, not (+).
Re: Putting Down Elm
#50Earlier quoted context omitted.
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: Prelud…
Not saying many Haskell compiler errors are obscure, especially for the uninitiated, but the particular error you picked as your first example is perfectly clear. Haskell is telling you 'you tried to apply a string literal to an argument as if it were a function, but it's not! It's a string literal. By the way, the string I'm talking about is "foo", which you tried to apply to "bar" in the expression "foo bar"' . Yik…
The output contains all you need, yes, but it would be nice if what you typed was added to the output. You wrote out a much more user friendly version.
Someone posted the output from Elm, which does this: https://news.ycombinator.com/item?id=11848467
Edit: checkout the elm error message page here http://elm-lang.org/blog/compilers-as-assistants