5 ms·

The "our way is the right way" mentality that is common in the Elm community is really the larger issue here, and it has been a bit of a turn off for m

by sridca 9y ago

The "our way is the right way" mentality that is common in the Elm community is really the larger issue here, and it has been a bit of a turn off for me. This is exactly how I felt as well. I really enjoyed Elm in the beginning but soon hit the abstraction wall as the complexity of my apps grew. I never got the impression that the Elm community was going to fix those problems any time soon. I now use PureScript which is far more pleasant to use, albeit it took a while to get up to speed with the language. Also I'm not the only one who went to PureScript from Elm: https://youtu.be/ngWo5e-294o?t=19m14s https://youtu.be/ngWo5e-294o?t=19m14s

rtfeldman 9y ago
We're over 150,000 lines of Elm code in production and are loving it. Wouldn't trade Elm for anything! It's natural for people to have language preferences, but let's not pretend there's some spooky "abstraction wall" prohibiting a nice experience at scale. ;)
- hellofunk 9y ago
  That's great that you are having a good time. But a few points: 1) The experiences you've personally had do not capture all problems that everyone has, and to assume you've seen it all is pretentious at best. You are quick to dismiss the very idea that anyone would find limitations in the language or its architecture, without even knowing the details of the myriad other projects out there; sorry, that is just naive or arrogant. 2) I've noticed that on nearly any forum, you like to brag about the size of your... codebase. The quality of a project and the problems it has solved are not revealed in quantity of lines. It doesn't matter if you have 100K or now you say 150K lines of code. I have no idea what problems you are solving, nor you us; so stop hiding behind a nice round number and claiming it gives you all manner of authority on what developers need. > let's not pretend there's some spooky "abstraction wall" Honestly, it's comments like this that underscore what many others here have said about the general stance in the Elm community. How about actually listening to people's experiences rather than dismissing them? You can't end your comments with little emojis and pretend it washes over the general brush-off you are presenting.
  - rtfeldman 9y ago
    > You are quick to dismiss the very idea that anyone would find limitations in the language or its architecture I really don't think that's a fair reading of what I wrote. :) > The quality of a project and the problems it has solved are not revealed in quantity of lines. I totally agree! I was responding to a comment where the author said they "soon hit the abstraction wall as the complexity of my apps grew." Stating that we haven't hit any such wall in 150,000 lines of code provides a concrete sanity check on that claim. Obviously I can't post our proprietary code base, and I'd prefer to say something more objective than "we have a very complex code base." (Which I'd certainly say we do!) > How about actually listening to people's experiences rather than dismissing them? The statement "Elm has an abstraction wall" is not an experience report, it's a claim about a language. I'm not dismissing anyone's experience by providing a counterpoint to that claim. I agree with you that nobody should tell others their experiences are invalid. But I feel no obligation to slump my shoulders and say "yeah I guess you must be right" if someone makes a misleading claim in a public forum. > You can't end your comments with little emojis and pretend it washes over the general brush-off you are presenting. I tend to write smileys whether I agree or disagree with someone. Sorry if that bothers you. :)
    - hellofunk 9y ago
      Just yesterday on Slack some experienced members were pointing out the workarounds necessary to handle certain challenging abstractions, things which are still being thought about for future versions. It's perfectly valid to admit there are some limitations there which may be too much for some projects. I don't think the above commenter's claim was any more misleading or vague than your claim. Elm is not a general purpose programming language. It exists for a single and specific use-case, a single design pattern, and this can be fantastic for those who fit their projects into that world. But it is a genuine side-effect of this that there are abstractions the language simply does not make easy or possible as a result of its goals. That's fine, but it can affect some projects -- obviously not yours. There are certain domains for which Elm makes a lot of sense, and others for which it would be the wrong choice. And Elm as a language is still in search of its ideal abstractions, as they have significantly changed over recent versions, so it's clear that this experience is not unique to the commenter only. Since Elm is just in its alpha stage, perhaps it is unfair to expect it to be as capable and mature as alternative languages.
deleted 9y ago
[deleted]

by sridca 9y ago

rtfeldman 9y ago

We're over 150,000 lines of Elm code in production and are loving it. Wouldn't trade Elm for anything! It's natural for people to have language preferences, but let's not pretend there's some spooky "abstraction wall" prohibiting a nice experience at scale. ;)

hellofunk 9y ago
That's great that you are having a good time. But a few points: 1) The experiences you've personally had do not capture all problems that everyone has, and to assume you've seen it all is pretentious at best. You are quick to dismiss the very idea that anyone would find limitations in the language or its architecture, without even knowing the details of the myriad other projects out there; sorry, that is just naive or arrogant. 2) I've noticed that on nearly any forum, you like to brag about the size of your... codebase. The quality of a project and the problems it has solved are not revealed in quantity of lines. It doesn't matter if you have 100K or now you say 150K lines of code. I have no idea what problems you are solving, nor you us; so stop hiding behind a nice round number and claiming it gives you all manner of authority on what developers need. > let's not pretend there's some spooky "abstraction wall" Honestly, it's comments like this that underscore what many others here have said about the general stance in the Elm community. How about actually listening to people's experiences rather than dismissing them? You can't end your comments with little emojis and pretend it washes over the general brush-off you are presenting.
- rtfeldman 9y ago
  > You are quick to dismiss the very idea that anyone would find limitations in the language or its architecture I really don't think that's a fair reading of what I wrote. :) > The quality of a project and the problems it has solved are not revealed in quantity of lines. I totally agree! I was responding to a comment where the author said they "soon hit the abstraction wall as the complexity of my apps grew." Stating that we haven't hit any such wall in 150,000 lines of code provides a concrete sanity check on that claim. Obviously I can't post our proprietary code base, and I'd prefer to say something more objective than "we have a very complex code base." (Which I'd certainly say we do!) > How about actually listening to people's experiences rather than dismissing them? The statement "Elm has an abstraction wall" is not an experience report, it's a claim about a language. I'm not dismissing anyone's experience by providing a counterpoint to that claim. I agree with you that nobody should tell others their experiences are invalid. But I feel no obligation to slump my shoulders and say "yeah I guess you must be right" if someone makes a misleading claim in a public forum. > You can't end your comments with little emojis and pretend it washes over the general brush-off you are presenting. I tend to write smileys whether I agree or disagree with someone. Sorry if that bothers you. :)
  - hellofunk 9y ago
    Just yesterday on Slack some experienced members were pointing out the workarounds necessary to handle certain challenging abstractions, things which are still being thought about for future versions. It's perfectly valid to admit there are some limitations there which may be too much for some projects. I don't think the above commenter's claim was any more misleading or vague than your claim. Elm is not a general purpose programming language. It exists for a single and specific use-case, a single design pattern, and this can be fantastic for those who fit their projects into that world. But it is a genuine side-effect of this that there are abstractions the language simply does not make easy or possible as a result of its goals. That's fine, but it can affect some projects -- obviously not yours. There are certain domains for which Elm makes a lot of sense, and others for which it would be the wrong choice. And Elm as a language is still in search of its ideal abstractions, as they have significantly changed over recent versions, so it's clear that this experience is not unique to the commenter only. Since Elm is just in its alpha stage, perhaps it is unfair to expect it to be as capable and mature as alternative languages.

deleted 9y ago

[deleted]