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

61–70 of 73 posts

Re: Putting Down Elm

#61

Post by masklinn »

the_af wrote: post #52
IanCal wrote: post #50

Earlier quoted context omitted.

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

In the "+" case, only the final hint is type-specific. The first error is kind-of type-specific but only distinguishes functions and non-functions.

Re: Putting Down Elm

#62

Post by MustardTiger »

the_gipsy wrote: post #30
orblivion wrote: post #17

Earlier quoted context omitted.

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.

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.

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.

Re: Putting Down Elm

#63

Post by MustardTiger »

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…

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

Re: Putting Down Elm

#64

Post by MustardTiger »

tlrobinson wrote: post #15
kemiller wrote: post #7

This has always been my experience with TDD, at least if you always leave yourself a failing test when you go. A lot more labor-intensive, since you are essentially writing the "compiler" as you go, but a similar effect.

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.

>You're still free to quickly sketch out ideas without worrying about type checking,

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.

Re: Putting Down Elm

#65

Post by spuz »

MustardTiger wrote: post #62
the_gipsy wrote: post #30

Earlier quoted context omitted.

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.

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.

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.

Re: Putting Down Elm

#66

Post by MustardTiger »

spuz wrote: post #65
MustardTiger wrote: post #62

Earlier quoted context omitted.

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.

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.

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

Re: Putting Down Elm

#67

Post by pka »

kemiller wrote: post #45
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.

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. So…

Sure. In Haskell for example you can turn type errors into warnings with a compiler flag. If you then encounter a type error at runtime the program will crash, much like in a dynamic language. And if it turns out the change was a dead end, just git checkout master and you're done.

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.

Re: Putting Down Elm

#68

Post by ccapndave »

therealmarv wrote: post #12

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

This is certainly annoying at the moment (although there are workable hacky solutions). However it's a well known issue and there is movement at https://github.com/elm-lang/html/issues/19 so hopefully it will be addressed in the near future.

Re: Putting Down Elm

#69

Post by ocean3 »

therealmarv wrote: post #12

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

I have the same issue on React components as well. Had to implement setTimeout in componentDidMount.

Re: Putting Down Elm

#70

Post by IanCal »

Semiapies wrote: post #33
seanjh wrote: post #5

Earlier quoted context omitted.

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

That's kind of amazing.

Here are some more examples, though are generally more basic errors: 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.

Post reply on HN