5 ms·

> 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

by 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.
      - rtfeldman 8y ago
        > use of dictionary passing as a substitute for typeclasses No, I mean that neither Elm nor Standard ML has nor needs typeclasses. No language needs typeclasses. Both Elm and Standard ML have additional type constraints for numbers and comparable types that aren't implemented in terms of a user-definable type constraint like Haskell's typeclasses. Another example of their being different is that Haskell offers custom user-defined operators, whereas Elm intentionally does not allow user-defined operators. There are a fixed list of them, and that's it. A great many languages have that policy too, and I would not call them wrong to do it that way. Again, there are sound design reasons to make either choice! There are costs and benefits to making things user-definable. If you prefer the way Haskell did it, great! That's why we have different programming languages. :)
        Athas 8y ago
        > Both Elm and Standard ML have additional type constraints for numbers and comparable types that aren't implemented in terms of a user-definable type constraint like Haskell's typeclasses. That's not really true. Standard ML has overloaded operators for int/real, but you cannot write a polymorphic function over any kind of number without using the module system. This is a key distinction. Standard ML does have a notion of 'equivalence type variables', which is frequently seen as a wart (since you often get an equality definition you might not be interested in). Standard ML has nothing for 'comparable' types (except, again, through the module system). Offhand, I can't really think of any other language that uses builtin type classes in the style of Elm.
  - sridca 8y ago
    I agree with you. Elm is not going to change, however fortunately there are alternatives. Pick something like PureScript or GHCJS and move on like I did. I now write Haskell professionally[1] both for frontend and backend, something that you'd be hard-pressed to achieve with the likes of Elm. [1] https://www.youtube.com/watch?v=riJuXDIUMA0 https://www.youtube.com/watch?v=riJuXDIUMA0
- leshow 8y ago
  I don't think it's crazy to wish for some kind of interface or trait-like abstraction mechanism in a language. Anything taken to the extreme can sound stupid. edit: I'm not saying Elm should change, the time for that is long gone. Just that the idea someone would want an interface (to do things like bound on generically) isn't that far fetched.
  - Skinney 8y ago
    > the time for that is long gone What makes you say that? Elm has yet to reach 1.0, anything can happen. It's not likely it will happen any time soon, however.
    - leshow 8y ago
      > What makes you say that? Because Evan has shown no interest in implementing a feature like what I'm describing.
      - Skinney 8y ago
        That's like saying Go will never get generics because it doesn't have it right now. Evan doesn't believe type classes are a right fit for Elm, but he has never to my knowledge ruled out that ad-hoc polymorphism will be added to the language.

by pdamoc 8y ago

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.
    - rtfeldman 8y ago
      > use of dictionary passing as a substitute for typeclasses No, I mean that neither Elm nor Standard ML has nor needs typeclasses. No language needs typeclasses. Both Elm and Standard ML have additional type constraints for numbers and comparable types that aren't implemented in terms of a user-definable type constraint like Haskell's typeclasses. Another example of their being different is that Haskell offers custom user-defined operators, whereas Elm intentionally does not allow user-defined operators. There are a fixed list of them, and that's it. A great many languages have that policy too, and I would not call them wrong to do it that way. Again, there are sound design reasons to make either choice! There are costs and benefits to making things user-definable. If you prefer the way Haskell did it, great! That's why we have different programming languages. :)
      - Athas 8y ago
        > Both Elm and Standard ML have additional type constraints for numbers and comparable types that aren't implemented in terms of a user-definable type constraint like Haskell's typeclasses. That's not really true. Standard ML has overloaded operators for int/real, but you cannot write a polymorphic function over any kind of number without using the module system. This is a key distinction. Standard ML does have a notion of 'equivalence type variables', which is frequently seen as a wart (since you often get an equality definition you might not be interested in). Standard ML has nothing for 'comparable' types (except, again, through the module system). Offhand, I can't really think of any other language that uses builtin type classes in the style of Elm.
- sridca 8y ago
  I agree with you. Elm is not going to change, however fortunately there are alternatives. Pick something like PureScript or GHCJS and move on like I did. I now write Haskell professionally[1] both for frontend and backend, something that you'd be hard-pressed to achieve with the likes of Elm. [1] https://www.youtube.com/watch?v=riJuXDIUMA0 https://www.youtube.com/watch?v=riJuXDIUMA0
leshow 8y ago
I don't think it's crazy to wish for some kind of interface or trait-like abstraction mechanism in a language. Anything taken to the extreme can sound stupid. edit: I'm not saying Elm should change, the time for that is long gone. Just that the idea someone would want an interface (to do things like bound on generically) isn't that far fetched.
- Skinney 8y ago
  > the time for that is long gone What makes you say that? Elm has yet to reach 1.0, anything can happen. It's not likely it will happen any time soon, however.
  - leshow 8y ago
    > What makes you say that? Because Evan has shown no interest in implementing a feature like what I'm describing.
    - Skinney 8y ago
      That's like saying Go will never get generics because it doesn't have it right now. Evan doesn't believe type classes are a right fit for Elm, but he has never to my knowledge ruled out that ad-hoc polymorphism will be added to the language.