Putting Down Elm(mkndrsn.com) |
Putting Down Elm(mkndrsn.com) |
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."""
Essentially, you set a visible goal. Passing test, compiling program, running command, visible widget on a browser. Run the test / command / browser URL and watch it fail. Let the error message you get determine your next step.
It makes a good debugging workflow too. The first step is to get a reproduction. Then you need to set up an environment where you can repeatedly and idempotently reproduce the bug at will. Then all you have to do is keep trying and learning things about the system until you know enough to devise a fix. Here you can manipulate the command itself to exercise less of the system, giving you a clearer idea of where the bug is.
Whereas if you're building a new feature, you want to keep the command static until you see what you want to see.
There's nothing magic about programming languages or paradigms that allows you to do this more easily. It's just how well you know your system. Some domains are trickier. You need special tools and expertise to reproduce network errors, and God help you if your stack isn't memory safe.
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
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.
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.
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.
If this were a post about soap (the salt, not the protocol) we'd downvote the post as obvious content-free shilling. But because it's some obscure language that doesn't even make the top 100 TIOBE language list, here we are, upvoting someone we've never heard of, celebrating his opinion of awesome compiler error messages that none of us has ever seen, for a language that nobody uses.
I agree with the basic gist of your comment, there isn't much content here to discuss (no offense to the author, it doesn't seem like it was meant for a site like HN). Though I think you might be over-reacting a bit with the tone of your comment.
I have dreams about it one day replacing JS as the front end language of choice.
which I think most people interested in Elm already knew.
There's also a lot less state to keep in your head, as it's usually a lot more transparent.
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.
That's a terrible work flow though. Quickly sketching out ideas is so much easier with types. So much so that you do that with just types, you don't even need to write the code. Then once you've worked your intuition into something that could actually work, you fill in the code.
Of course it could be better, and that's probably what you are getting at. Ideally the machinery provided for building web applications would be more aware of the nature of web applications and have something in the box (still explicit and obvious, but in the box) to do something like setting focus.
most compilers tell you there's a problem but none outline how to fix it the way Elm does
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.
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.
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"
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
> "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 (+).
<http://package.elm-lang.org/packages/elm-lang/core/latest/Basics#++>The second error message, on the other hand, proves that the first one is a lucky accident.
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.
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.
Agreed. I can prototype an idea almost entirely in types, and if the types make sense, then the implementation often follows naturally.
However, if not, you'll still have a list of compiler errors you have to fix to make the rest of the program work. This alone lets me refactor with confidence, much more so than every dynamic language I've ever used.
(nit: dynamically typed != no types)
How do compiler errors look in Elm with generic functions involved, about which the compiler doesn't have any helpful hardcoded knowledge? (I.e. no "+" or strings involved).
Regarding hardcoded messages, there's been at some point talk in the community regarding allowing library authors to have some sort of hook to compiler that would make it possible to customize specific error messages along with a package.
Also, although from a compiler's point of view it might make sense, the wording "The function ‘"foo"’ is applied to one argument, but its type ‘[Char]’ has none" doesn't make sense. It's clearly not a function if it doesn't take an argument. The same error message would be far clearer if it said something similar to "The expression ‘"foo"’ is being used as a function, but it is of type ‘[Char]’".
Also these are just two examples I rattled off the top of my head; the fact is that while the compiler is incredibly helpful in making sure your code is correct, it's less helpful in explaining itself. But, I also realize that producing good error messages is hard, and (I assume) significantly less interesting to many on the GHC team.
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
However, I'm left wondering... Elm seems to be using hardcoded knowledge about commonly used types such as strings and numbers in order to improve its error messages (I wonder why Haskell doesn't, by the way). What happens in Elm when an error occurs with more complex, user-defined types and operations?
If you're interested, there were a couple more examples shown elsewhere in this thread:
http://elm-lang.org/blog/compiler-errors-for-humans (an older version it seems)
https://twitter.com/st58/status/732908457217531904
https://twitter.com/GregorySchier/status/732830868562182144
Something I've just found is that the errors can also be output in a nice machine readable format, so the suggested fixes can be read in by your editor plugin.
And finally, this is wonderful, a specific repo for code that causes error messages and a request for people to submit error messages that are confusing: https://github.com/elm-lang/error-message-catalog
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.
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.
And my point is that no it should not. "1 2" is more ambiguous, it could be more things, hence there is a more ambiguous error message.