5 ms·

Congrats on the release! I have very high hopes for Elm in the future, and I think it truly shifts the paradigm of frontend development. On an attempt to use E

Congrats on the release! I have very high hopes for Elm in the future, and I think it truly shifts the paradigm of frontend development. On an attempt to use Elm in production I ended up switching back to Javascript. The biggest issue I faced was lack of type-classes, which made certain parts of the code feel like I was pulling teeth to get Elm's type system to be happy. Perhaps this is more of an issue of expecting Elm to be more like Haskell than it is. I hope Elm is able to get more adoption, and with it more examples of idiomatic approaches to problems in Elm's style. However this somewhat feels like a chicken-and-egg problem. Regardless, this release looks great for people using it in production already!

rtfeldman 8y ago
> this is more of an issue of expecting Elm to be more like Haskell than it is. Yep, that's it right there. I wonder if there's some way we could make it clearer that Elm is not Haskell, and trying to use it like it's Haskell won't likely to lead to a good experience. At any rate, thank you for the feedback! It's definitely an ongoing communication challenge since the two languages have so much syntax in common.
pdamoc 8y ago
> Perhaps this is more of an issue of expecting Elm to be more like Haskell than it is. Some people have a hard time in Elm because they expect Elm to behave like a language that they are already familiar with. The most frequent impedance mismatch issues I've seen are reaching for `type-classes` or attempting to implement various polymorphic behaviors and people who are too hungover on imperative constructs (Elm is declarative). Once people start using Elm the way it was designed to be used, things become simple and start to flow.
- undreren 8y ago
  > Once people start using Elm the way it was designed to be used, things become simple and start to flow. But how will anyone ever get anything done, when they can't make everything in their code exceptionally clear by wrapping it all up in a 15 monad thick monad-combinator? /s But yes, I totally agree. Elm is a simpler, safer and easier Haskell for the front-end. I just love it :)
  - comex 8y ago
    The idea that wanting to use typeclasses in Elm is an impedance mismatch would be more convincing if Elm and its standard library truly did everything without them, using alternate approaches like explicit dictionary passing. But as you probably know, they don’t. Instead, the language has special syntax for three builtin “typeclasses”: comparable, appendable, and number. And the standard library uses them: its Dict, for example, requires the key type to be comparable. These classes are automatically implemented for various builtin types, but there’s no way to implement them for custom types, so you can’t have Dicts with custom types as keys (unless that changed very recently). And if you want to, say, implement a hash map data structure, which requires the keys to be hashable, you have to use a completely different design, since “hashable” is not one of the three magic typeclasses. To me, rather than principled, that just feels incomplete.
    - undreren 8y ago
      While I agree, I honestly don't care. It's a bit of magic, yeah, but at least we're rid of the insane amount of mental masturbation that permeates the Haskell ecosystem.
    - rtfeldman 8y ago
      Elm handles those things the way Standard ML does, not the way Haskell does. It's cool if you prefer the way Haskell does it, though! You should check out PureScript, which chose to do it the way Haskell did it.
      - comex 8y ago
        > Elm handles those things the way Standard ML does, not the way Haskell does. That's the thing, though: it doesn't. Sure, Elm is expressive enough to allow use of dictionary passing as a substitute for typeclasses, and as you noted, this approach has some resemblance to how ML modules work – albeit with less sugar. However, Elm's standard library does not seem to think this is the best approach, since it instead uses the aforementioned special-cased typeclasses.
baublet 8y ago
Concur. Elm is an excellent addition to one's development quiver. Its strictness made me a far better, more careful programmer, and the push toward functional, side-effect free programming styles (something also coming from the React community) has been a huge boon to the JS world. Loving the current state of JS!
masklinn 8y ago
FWIW you may be interested in Purescript, it's less developed than Elm but is more on-board with abstractions & the like.
- rtfeldman 8y ago
  It's more accurate to say PureScript has Haskell-like (or category-theoretic, if you prefer) abstractions. All high-level programming languages are on board with abstractions, pretty much by definition!
  - masklinn 8y ago
    > All high-level programming languages are on board with abstractions, pretty much by definition! They all provide abstractions, but they're not necessarily on board with letting users build new abstractions. Go is famously absolutely not on board with it for instance. Elm significantly less so — and I think the more restricted use-case also makes the issue significantly less problematic, at least it was in my (admittedly limited) experience — but it's still way downslope from the likes of Haskell or OCaml.

rtfeldman 8y ago

> this is more of an issue of expecting Elm to be more like Haskell than it is. Yep, that's it right there. I wonder if there's some way we could make it clearer that Elm is not Haskell, and trying to use it like it's Haskell won't likely to lead to a good experience. At any rate, thank you for the feedback! It's definitely an ongoing communication challenge since the two languages have so much syntax in common.

pdamoc 8y ago

> Perhaps this is more of an issue of expecting Elm to be more like Haskell than it is. Some people have a hard time in Elm because they expect Elm to behave like a language that they are already familiar with. The most frequent impedance mismatch issues I've seen are reaching for `type-classes` or attempting to implement various polymorphic behaviors and people who are too hungover on imperative constructs (Elm is declarative). Once people start using Elm the way it was designed to be used, things become simple and start to flow.

undreren 8y ago
> Once people start using Elm the way it was designed to be used, things become simple and start to flow. But how will anyone ever get anything done, when they can't make everything in their code exceptionally clear by wrapping it all up in a 15 monad thick monad-combinator? /s But yes, I totally agree. Elm is a simpler, safer and easier Haskell for the front-end. I just love it :)
- comex 8y ago
  The idea that wanting to use typeclasses in Elm is an impedance mismatch would be more convincing if Elm and its standard library truly did everything without them, using alternate approaches like explicit dictionary passing. But as you probably know, they don’t. Instead, the language has special syntax for three builtin “typeclasses”: comparable, appendable, and number. And the standard library uses them: its Dict, for example, requires the key type to be comparable. These classes are automatically implemented for various builtin types, but there’s no way to implement them for custom types, so you can’t have Dicts with custom types as keys (unless that changed very recently). And if you want to, say, implement a hash map data structure, which requires the keys to be hashable, you have to use a completely different design, since “hashable” is not one of the three magic typeclasses. To me, rather than principled, that just feels incomplete.
  - undreren 8y ago
    While I agree, I honestly don't care. It's a bit of magic, yeah, but at least we're rid of the insane amount of mental masturbation that permeates the Haskell ecosystem.
  - rtfeldman 8y ago
    Elm handles those things the way Standard ML does, not the way Haskell does. It's cool if you prefer the way Haskell does it, though! You should check out PureScript, which chose to do it the way Haskell did it.
    - comex 8y ago
      > Elm handles those things the way Standard ML does, not the way Haskell does. That's the thing, though: it doesn't. Sure, Elm is expressive enough to allow use of dictionary passing as a substitute for typeclasses, and as you noted, this approach has some resemblance to how ML modules work – albeit with less sugar. However, Elm's standard library does not seem to think this is the best approach, since it instead uses the aforementioned special-cased typeclasses.

baublet 8y ago

Concur. Elm is an excellent addition to one's development quiver. Its strictness made me a far better, more careful programmer, and the push toward functional, side-effect free programming styles (something also coming from the React community) has been a huge boon to the JS world. Loving the current state of JS!

masklinn 8y ago

FWIW you may be interested in Purescript, it's less developed than Elm but is more on-board with abstractions & the like.

rtfeldman 8y ago
It's more accurate to say PureScript has Haskell-like (or category-theoretic, if you prefer) abstractions. All high-level programming languages are on board with abstractions, pretty much by definition!
- masklinn 8y ago
  > All high-level programming languages are on board with abstractions, pretty much by definition! They all provide abstractions, but they're not necessarily on board with letting users build new abstractions. Go is famously absolutely not on board with it for instance. Elm significantly less so — and I think the more restricted use-case also makes the issue significantly less problematic, at least it was in my (admittedly limited) experience — but it's still way downslope from the likes of Haskell or OCaml.