4 ms·

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, bu

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.
    - rtfeldman 9y ago
      > There are certain domains for which Elm makes a lot of sense, and others for which it would be the wrong choice. No argument here! Elm has this characteristic in common with JavaScript, Java, Scala, C, C++, Python, Ruby, Perl, Haskell, PureScript, Go, Rust... ;) > It's perfectly valid to admit there are some limitations there which may be too much for some projects. Absolutely! I know of one team that specifically switched from Elm to ClojureScript because that made more sense for their project (whose purpose was to stitch together JS libraries on the fly), and I thought they made the right decision. ClojureScript was a better fit for their needs. I also wouldn't use Elm in situations where a virtual DOM would be problematic, such as making a large-scale rich text editor. I don't think anyone would disagree with the broad claim that some languages are a better fit for some projects. > Elm as a language is still in search of its ideal abstractions Also true of every programming language, except for the abandoned ones. :) > I don't think the above commenter's claim was any more misleading or vague than your claim. I'm not sure what claim you think I'm making. I think I've been pretty consistent about pointing out Elm has led to some great outcomes. I'm not saying things like "Everyone should drop what they're doing and switch to Elm" - that would be absurd. I responded to an equally absurd claim by giving a counterexample. Just as it's valid to point out that Elm (being a programming language) has limitations, it's also valid to point out that people's preferences for various programming languages aren't the same thing as universal truths. If someone wants to say "I tried both Elm and PureScript and preferred the latter," that's great! Everybody is happy with the language they're using. We all win! If someone wants to say "I switched from Elm to PureScript since nontrivial Elm apps can't exist because abstractions," it's fair for me to demonstrate the absurdity of that claim by pointing out that our 150,000 line Elm app exists.

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.
  - rtfeldman 9y ago
    > There are certain domains for which Elm makes a lot of sense, and others for which it would be the wrong choice. No argument here! Elm has this characteristic in common with JavaScript, Java, Scala, C, C++, Python, Ruby, Perl, Haskell, PureScript, Go, Rust... ;) > It's perfectly valid to admit there are some limitations there which may be too much for some projects. Absolutely! I know of one team that specifically switched from Elm to ClojureScript because that made more sense for their project (whose purpose was to stitch together JS libraries on the fly), and I thought they made the right decision. ClojureScript was a better fit for their needs. I also wouldn't use Elm in situations where a virtual DOM would be problematic, such as making a large-scale rich text editor. I don't think anyone would disagree with the broad claim that some languages are a better fit for some projects. > Elm as a language is still in search of its ideal abstractions Also true of every programming language, except for the abandoned ones. :) > I don't think the above commenter's claim was any more misleading or vague than your claim. I'm not sure what claim you think I'm making. I think I've been pretty consistent about pointing out Elm has led to some great outcomes. I'm not saying things like "Everyone should drop what they're doing and switch to Elm" - that would be absurd. I responded to an equally absurd claim by giving a counterexample. Just as it's valid to point out that Elm (being a programming language) has limitations, it's also valid to point out that people's preferences for various programming languages aren't the same thing as universal truths. If someone wants to say "I tried both Elm and PureScript and preferred the latter," that's great! Everybody is happy with the language they're using. We all win! If someone wants to say "I switched from Elm to PureScript since nontrivial Elm apps can't exist because abstractions," it's fair for me to demonstrate the absurdity of that claim by pointing out that our 150,000 line Elm app exists.