Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Putting Down Elm

mkndrsn.com

Post reply on HN
Print view View original

51–60 of 73 posts

Re: Putting Down Elm

#51

Post by montibbalt »

pka wrote: post #21
tlrobinson wrote: post #15

Earlier 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.

For me types make prototyping WAY faster, especially if "throw" or some other keyword satisfies the return type of a function. I can write out the function signatures and data types I need and get things to line up with the help of a tool that tells me exactly what I need to do (the compiler). This lets me quickly find a solution without having to actually implement any of it, and then I have a skeleton ready to fill in with details.

Re: Putting Down Elm

#52

Post by the_af »

IanCal wrote: post #50
the_af wrote: post #47

Earlier quoted context omitted.

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

Agreed, Elm in these two examples is way nicer! It doesn't add information, but it presents it in a beginner-friendly way, which is commendable.

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?

Re: Putting Down Elm

#53

Post by the_af »

ob wrote: post #49
thinkpad20 wrote: post #40

Earlier 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…

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? Also > "foo" + "bar" -- TYPE MISMATCH --------------------------------------------- repl-temp-000.elm The left argument of (+) is causing a type mismatc…

Interesting! Thanks for the example.

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).

Re: Putting Down Elm

#54

Post by draw_down »

spuz wrote: post #2

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?

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.

Re: Putting Down Elm

#55

Post by AlexCoventry »

HelloNurse wrote: post #46
thinkpad20 wrote: post #40

Earlier 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…

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 a…

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.

Re: Putting Down Elm

#56

Post by thinkpad20 »

the_af wrote: post #47
thinkpad20 wrote: post #40

Earlier 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…

Well like I said, once you see enough of these error messages you get a clear idea of how to parse them and understand what they're "really saying". But on first glance, and in particular for newcomers, the error message is rather arcane. And of course, in this instance it's quite straightforward because it's a very simple expression, with a rather clear problem. But consider when the error might be buried in a much more complicated expression, or the fact that it's not a function (or is a function, when you expected otherwise) might not be as clear. For example a curried function that has too many or not enough arguments applied.

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.

Re: Putting Down Elm

#57

Post by naasking »

montibbalt wrote: post #51
pka wrote: post #21

Earlier quoted context omitted.

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.

For me types make prototyping WAY faster, especially if "throw" or some other keyword satisfies the return type of a function. I can write out the function signatures and data types I need and get things to line up with the help of a tool that tells me exactly what I need to do (the compiler). This lets me quickly find a solution without having to actually implement any of it, and then I have a skeleton ready to fill…

> For me types make prototyping WAY faster

Agreed. I can prototype an idea almost entirely in types, and if the types make sense, then the implementation often follows naturally.

Re: Putting Down Elm

#58

Post by elros »

the_af wrote: post #53
ob wrote: post #49

Earlier quoted context omitted.

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? Also > "foo" + "bar" -- TYPE MISMATCH --------------------------------------------- repl-temp-000.elm The left argument of (+) is causing a type mismatc…

Interesting! Thanks for the example. 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).

If you mean typeclasses, Elm doesn't have them.

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.

Re: Putting Down Elm

#59

Post by elros »

the_af wrote: post #53
ob wrote: post #49

Earlier quoted context omitted.

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? Also > "foo" + "bar" -- TYPE MISMATCH --------------------------------------------- repl-temp-000.elm The left argument of (+) is causing a type mismatc…

Interesting! Thanks for the example. 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).

If you mean typeclasses, Elm doesn't have them.

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.

Re: Putting Down Elm

#60

Post by agumonkey »

kriro wrote: post #11

The 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."""

I literally had to read it 5 times before realizing it's not a dismissal of Elm.
Post reply on HN