As a Haskell user, what would you imagine that I’m most likely to miss about Elm?
Elm, from what I’ve heard, doesn’t have type classes. Is that correct? What is used in their place? Or is the going assumption that you won’t need type classes for most front-end projects?
How does the type system document the different kinds of effects? Is there an extensible effect system like in Purescript, or something like Haskell’s MTL, or something else entirely?
Losing typeclasses does hurt. I’m not sure if there’s a real place where one stops missing them—my Haskell experience was certainly causing me to feel my arms were tied behind my back, though. The tradeoff seems to be eliminating them for simplicity of experience, but that’s just not really a value proposition an experienced Haskell user can perceive.
There isn’t really and effect typing at all. Your entire Elm program lives in an effectual context that’s a bit like FRP, but it does some significant work to keep everything “pure”. In practice, there are actually a lot of ambient effects (Elm isn’t really all that pure, it just looks that way) but you probably won’t care much about them except at the edges of your application. Here’s an example of an untagged effect: https://github.com/evancz/start-app/blob/master/src/StartApp.elm#L86
Elm feels, to me, to be aiming entirely at the simplicity of pure functional data manipulation. Most of your programs are written in this wheelhouse and it feels very nice. There’s a lot of fear that you’ll be a bit hosed when you hit the “rough edges” of that model, though, and Elm doesn’t play super nicely with Javascript (not like Purescript) so you have to do a bit of black magic to make things work. The ports system handles some of this well… but instead of making things compose so as to handle complexities on their own, ports extend through your system and cause enough impedance that it’s hard to say if they’re a real win (at least for me).
Re the above point… Elm would really benefit from pervasive use of lenses, but that seems really antithetical to Evan’s goals given the apparent complexity of a lens system.
Anyway, I’m not a user in anger and I’m also quite sure that I’m missing a lot of what’s going on with Elm. My feelings are that if you could swing getting it so that most of your time is legitimately spent in the highly pure bits of Elm then it will be nice and remarkably simple, though your Haskell habits will have you reaching for power which just isn’t there. Ultimately, I don’t mind a little boilerplate, though. You end up writing slightly verbose but remarkably clear code.
The appeal of Elm to me in its simplicity is actually not an issue with Haskell/Purescript complexity (which I’ve already got) but with the front-end stuff. I find the front-end ecosystem really convoluted, messy, and while I can do simple things like build data viz applications in D3, I don’t feel like I’ve quite got what it would take to, say, build a complex game in a reasonable period of time.
My struggle with Purescript the last time I tried to work with it was not related to the language itself (which was great) but the various tools in the JS world that I had to work with in order to get anything to work. Maybe that would be an issue with Elm as well, though.
This looks very interesting.
As a Haskell user, what would you imagine that I’m most likely to miss about Elm?
Elm, from what I’ve heard, doesn’t have type classes. Is that correct? What is used in their place? Or is the going assumption that you won’t need type classes for most front-end projects?
How does the type system document the different kinds of effects? Is there an extensible effect system like in Purescript, or something like Haskell’s MTL, or something else entirely?
In my little bit of experience with Elm:
Losing typeclasses does hurt. I’m not sure if there’s a real place where one stops missing them—my Haskell experience was certainly causing me to feel my arms were tied behind my back, though. The tradeoff seems to be eliminating them for simplicity of experience, but that’s just not really a value proposition an experienced Haskell user can perceive.
There isn’t really and effect typing at all. Your entire Elm program lives in an effectual context that’s a bit like FRP, but it does some significant work to keep everything “pure”. In practice, there are actually a lot of ambient effects (Elm isn’t really all that pure, it just looks that way) but you probably won’t care much about them except at the edges of your application. Here’s an example of an untagged effect: https://github.com/evancz/start-app/blob/master/src/StartApp.elm#L86
Elm feels, to me, to be aiming entirely at the simplicity of pure functional data manipulation. Most of your programs are written in this wheelhouse and it feels very nice. There’s a lot of fear that you’ll be a bit hosed when you hit the “rough edges” of that model, though, and Elm doesn’t play super nicely with Javascript (not like Purescript) so you have to do a bit of black magic to make things work. The ports system handles some of this well… but instead of making things compose so as to handle complexities on their own, ports extend through your system and cause enough impedance that it’s hard to say if they’re a real win (at least for me).
Re the above point… Elm would really benefit from pervasive use of lenses, but that seems really antithetical to Evan’s goals given the apparent complexity of a lens system.
Anyway, I’m not a user in anger and I’m also quite sure that I’m missing a lot of what’s going on with Elm. My feelings are that if you could swing getting it so that most of your time is legitimately spent in the highly pure bits of Elm then it will be nice and remarkably simple, though your Haskell habits will have you reaching for power which just isn’t there. Ultimately, I don’t mind a little boilerplate, though. You end up writing slightly verbose but remarkably clear code.
The appeal of Elm to me in its simplicity is actually not an issue with Haskell/Purescript complexity (which I’ve already got) but with the front-end stuff. I find the front-end ecosystem really convoluted, messy, and while I can do simple things like build data viz applications in D3, I don’t feel like I’ve quite got what it would take to, say, build a complex game in a reasonable period of time.
My struggle with Purescript the last time I tried to work with it was not related to the language itself (which was great) but the various tools in the JS world that I had to work with in order to get anything to work. Maybe that would be an issue with Elm as well, though.