6 ms·

What you term the "immaturity of the language" is imo a well thought put focus on simplicity. It was never Elm's intention to reach the complexity of Haskell or

by erokar 8y ago

What you term the "immaturity of the language" is imo a well thought put focus on simplicity. It was never Elm's intention to reach the complexity of Haskell or indeed PureScript. I think that was a sound decision.

iodiniemetra 8y ago
That's not the takeaway that you should have - simplicity doesn't matter if minor language versions make breaks.
- knewter 8y ago
  it was a rewrite of the compiler in a pre-1.0 language trying to find its preferred API. you shouldn't be surprised it broke stuff, especially when literally every thing about native explained it was a private unsupported API. calling this a minor release is idiotic and you're just mad because they took away a thing they promised to take away and said you shouldn't use.
  - alluro2 8y ago
    While I agree about it being ok to break things at this stage, some of the words in your reply were a bit confusing - what do you mean a "private unsupported API" in an open source project? Kind of supports the notion that this is a private group project and others can use it, but are not welcome to participate. Also, if calling this a minor release is idiotic, why was the version number then a minor increase (at least according to commonly accepted understanding, i.e. semver) and not a 0.20 or whatever else, especially if there are breaking API changes.
    - Zyst 8y ago
      In semver versions before 1.0 are prerelease versions.
    - uryga 8y ago
      GP probably meant something like "an internal API that's exposed in case you need it but gives no guarantees about stability because it's still evolving"
    - knewter 8y ago
      > Kind of supports the notion that this is a private group project and others can use it, but are not welcome to participate. Native's existence was an implementation detail. no one using it didn't know it was likely to go away if they read anything about it from core. it was undocumented, but where you could find any documentation it said very clearly not to use it. people used it anyway. I was one. but I knew going in that it would likely disappear. > why was the version number then a minor increase (at least according to commonly accepted understanding, i.e. semver) and not a 0.20 or whatever else, especially if there are breaking API changes. https://semver.org/#spec-item-4 https://semver.org/#spec-item-4 you not understanding semver doesn't make elm bad
      - fulafel 8y ago
        Elm doesn't seem to use semver (which requires that "A normal version number MUST take the form X.Y.Z")
      - mst 8y ago
        I asked upthread about native versus ports and somebody was kind enough to mention ports were async only. But I'm still curious about exactly what people were using native for and why at least some users don't feel they can rewrite easily - care to share what you used and why, and what your thoughts are about replacing it? (the discussion around this has, so far as I've been able to see, devoid of concrete examples, and now the question's nerd sniped me :)
      - vmchale 8y ago
        Clearly the internal API existed because Evan et al. decided they needed to use it. So why did they decide it a feature that was so obviously necessary was too complicated for the hoi polloi?
mikekchar 8y ago
I think you are right, but the way decisions are communicated in Elm are frustrating. There are lots of decisions like this, which in the end are just decisions, but can be frustrating if you are expecting a more complex language. Even without talking about type classes, the lack of applicative is weird. I know: nobody understands what applicative is for, but if you have map and you are currying parameters, you're going to run into the issue ;-) Instead, you've got map, map2, map3, map4, map5 (which also, frustratingly, don't implement applicative). There are lots of validation scenarios that are just way more complex to do in Elm than they need to be. But to be honest, it's fine because the language is not supposed to give you everything that you might want. It's geared for people who want a subset that's easy to learn. If I'm going to write code for myself in this space (functional language that compiles down to JS), I'm going to pick Purescript because it has everything that you're ever going to want. But if I'm choosing a language for my team that doesn't know functional programming and (to be blunt) doesn't really care to learn: Elm is a much better fit. They can learn just enough to get their work done. But I just wish it was stated in those terms clearly. The premise of the article has been played out time and time again in the Elm community: "I thought this was a fully featured functional language, but when I tried to do this completely reasonable thing I got my hand slapped". At every turn the response to, "Why can't I do X" is "Because you don't need to do X. It's much simpler to do without X" -- which usually isn't true. It's much simpler to learn something without X, but X is there to make your life much easier as long as you can deal with the complexity of learning it. It's the old "ease of use" vs "ease of learning" issue.
- always_good 8y ago
  On the other hand, people need to learn to take no for an answer and move on. Instead, egos get involved and a new essay of the week appears on how Elm is doomed because it doesn't have <pet feature>. That nobody can take Elm seriously if it doesn't have type-classes, synchronous FFI, derivable JSON codecs, component state, or whatever the pyre was built on that day. If you didn't know better, you'd think they were disgruntled paying customers. Elm's simplicity, lack of abstraction, and resulting boilerplate have more to offer than helping beginners learn. Nothing demonstrates this better than coming back to an old Elm application and immediately making meaningful changes to the code despite a long hiatus from using Elm at all. There are a lot of languages that continually add features in this space like PureScript, ReasonML, and even TypeScript. Why not see where Elm ends up with its aggressive devotion to a minimal API instead of trying to turn it into a language we already have? Some of the best aspects of Elm come from its restrictive nature. Like how every Elm application uses the same "TEA" abstraction which is a breath of fresh air for anyone who never felt particularly empowered by the paralyzing abundance of options in the JS ecosystem nor the task of webpack-plumbing them together.
vmchale 8y ago
No, "immaturity of the language" refers to Evan's tendency to make breaking changes for absolutely no good reason. Use custom operators? Fuck you. Now go rewrite all the libraries you contributed to the community.

by erokar 8y ago

iodiniemetra 8y ago

That's not the takeaway that you should have - simplicity doesn't matter if minor language versions make breaks.

knewter 8y ago
it was a rewrite of the compiler in a pre-1.0 language trying to find its preferred API. you shouldn't be surprised it broke stuff, especially when literally every thing about native explained it was a private unsupported API. calling this a minor release is idiotic and you're just mad because they took away a thing they promised to take away and said you shouldn't use.
- alluro2 8y ago
  While I agree about it being ok to break things at this stage, some of the words in your reply were a bit confusing - what do you mean a "private unsupported API" in an open source project? Kind of supports the notion that this is a private group project and others can use it, but are not welcome to participate. Also, if calling this a minor release is idiotic, why was the version number then a minor increase (at least according to commonly accepted understanding, i.e. semver) and not a 0.20 or whatever else, especially if there are breaking API changes.
  - Zyst 8y ago
    In semver versions before 1.0 are prerelease versions.
  - uryga 8y ago
    GP probably meant something like "an internal API that's exposed in case you need it but gives no guarantees about stability because it's still evolving"
  - knewter 8y ago
    > Kind of supports the notion that this is a private group project and others can use it, but are not welcome to participate. Native's existence was an implementation detail. no one using it didn't know it was likely to go away if they read anything about it from core. it was undocumented, but where you could find any documentation it said very clearly not to use it. people used it anyway. I was one. but I knew going in that it would likely disappear. > why was the version number then a minor increase (at least according to commonly accepted understanding, i.e. semver) and not a 0.20 or whatever else, especially if there are breaking API changes. https://semver.org/#spec-item-4 https://semver.org/#spec-item-4 you not understanding semver doesn't make elm bad
    - fulafel 8y ago
      Elm doesn't seem to use semver (which requires that "A normal version number MUST take the form X.Y.Z")
    - mst 8y ago
      I asked upthread about native versus ports and somebody was kind enough to mention ports were async only. But I'm still curious about exactly what people were using native for and why at least some users don't feel they can rewrite easily - care to share what you used and why, and what your thoughts are about replacing it? (the discussion around this has, so far as I've been able to see, devoid of concrete examples, and now the question's nerd sniped me :)
    - vmchale 8y ago
      Clearly the internal API existed because Evan et al. decided they needed to use it. So why did they decide it a feature that was so obviously necessary was too complicated for the hoi polloi?

mikekchar 8y ago

I think you are right, but the way decisions are communicated in Elm are frustrating. There are lots of decisions like this, which in the end are just decisions, but can be frustrating if you are expecting a more complex language. Even without talking about type classes, the lack of applicative is weird. I know: nobody understands what applicative is for, but if you have map and you are currying parameters, you're going to run into the issue ;-) Instead, you've got map, map2, map3, map4, map5 (which also, frustratingly, don't implement applicative). There are lots of validation scenarios that are just way more complex to do in Elm than they need to be. But to be honest, it's fine because the language is not supposed to give you everything that you might want. It's geared for people who want a subset that's easy to learn. If I'm going to write code for myself in this space (functional language that compiles down to JS), I'm going to pick Purescript because it has everything that you're ever going to want. But if I'm choosing a language for my team that doesn't know functional programming and (to be blunt) doesn't really care to learn: Elm is a much better fit. They can learn just enough to get their work done. But I just wish it was stated in those terms clearly. The premise of the article has been played out time and time again in the Elm community: "I thought this was a fully featured functional language, but when I tried to do this completely reasonable thing I got my hand slapped". At every turn the response to, "Why can't I do X" is "Because you don't need to do X. It's much simpler to do without X" -- which usually isn't true. It's much simpler to learn something without X, but X is there to make your life much easier as long as you can deal with the complexity of learning it. It's the old "ease of use" vs "ease of learning" issue.

always_good 8y ago
On the other hand, people need to learn to take no for an answer and move on. Instead, egos get involved and a new essay of the week appears on how Elm is doomed because it doesn't have <pet feature>. That nobody can take Elm seriously if it doesn't have type-classes, synchronous FFI, derivable JSON codecs, component state, or whatever the pyre was built on that day. If you didn't know better, you'd think they were disgruntled paying customers. Elm's simplicity, lack of abstraction, and resulting boilerplate have more to offer than helping beginners learn. Nothing demonstrates this better than coming back to an old Elm application and immediately making meaningful changes to the code despite a long hiatus from using Elm at all. There are a lot of languages that continually add features in this space like PureScript, ReasonML, and even TypeScript. Why not see where Elm ends up with its aggressive devotion to a minimal API instead of trying to turn it into a language we already have? Some of the best aspects of Elm come from its restrictive nature. Like how every Elm application uses the same "TEA" abstraction which is a breath of fresh air for anyone who never felt particularly empowered by the paralyzing abundance of options in the JS ecosystem nor the task of webpack-plumbing them together.

vmchale 8y ago

No, "immaturity of the language" refers to Evan's tendency to make breaking changes for absolutely no good reason. Use custom operators? Fuck you. Now go rewrite all the libraries you contributed to the community.