Elm is a great language for web. It's evolving but there are some bits that need some rework/improvement/rethought like the canvas performance and managing random number generation. This is difficult with purely functional architecture. But there are a quite a lot of good thought gone into making the whole functional programming user friendly and a pleasant experience. Kudos to the creators/maintainers
Putting Down Elm
31–40 of 73 posts
Re: Putting Down Elm
#32Earlier 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 find it's conductive to rewriting that I can iterate with only one or two codepaths of the remodeled core working before settling on something and fixing the rest of the codebase to match.
(nit: dynamically typed != no types)
Re: Putting Down Elm
#33Earlier quoted context omitted.
Exactly what I wanted to ask. Can we mere developers have some context to it?
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.
Re: Putting Down Elm
#34I feel like something clicked for me once I realized that all functions in Elm are curried by default. Cool feature.
Re: Putting Down Elm
#35[deleted]
Re: Putting Down Elm
#36in my experience, when I am stuck figuring out types, I just let the compiler do it. As the error messages are so well-formed, it tells me exactly which lines are inconsistent and how to put the types back together.
most compilers tell you there's a problem but none outline how to fix it the way Elm does
Re: Putting Down Elm
#37Earlier 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.
Haskell had poor error messages last I tried it. Have they improved?
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.
Re: Putting Down Elm
#38ok 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'm not sure this is a fair criticism. The nice thing about this tiny chunk of code is that there is only one aspect of this example program that needs to manipulate the already instantiated DOM, and that tiny chunk is explicitly brought up to the top level and separated and connected back to the program via the port mechanism. It would certainly be worse if this magic happen behind the scenes. Of course it could be…
It's absolutely a fair criticism. The real DOM is stateful, elm's virtual DOM is not, and elm doesn't provide any tools to manipulate the state of the real DOM. This impedance mismatch is bound to cause problems any time you are dealing with the stateful aspects of the DOM. And solutions like the one linked to by GP are error prone and fragile.
Re: Putting Down Elm
#39This is the perfect example of the content-free HN posts that are topping the charts lately. It contains not a single example of a "helpful error message." Nor a single line of code from the language in question. Just a 173 word free-verse poem with some feel-good handwaving. 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 obsc…
I think this is a case where the topic is something that enough people want to discuss so the post generates discussion regardless of the content.
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.
Re: Putting Down Elm
#40Earlier quoted context omitted.
Haskell had poor error messages last I tried it. Have they improved?
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:
Prelude> "foo" "bar"
:3:1:
Couldn't match expected type ‘[Char] -> t’
with actual type ‘[Char]’
Relevant bindings include it :: t (bound at :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
: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