8 ms·

> 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 w

> 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.
  - sridca 9y ago
    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. It would appear that you misunderstood what I said. Elm not facilitating the use of sufficient level of abstractions does not necessarily mean one cannot use Elm to write the said app. It simply means that you would have to deal with it all at a lower level (with the corresponding code duplication where necessary) in the absence of the aforementioned capability to build abstractions. For more on this topic refer to https://en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs https://en.wikipedia.org/wiki/Structure_and_Interpretation_o... Furthermore, in the process of agreeing with the parent comment, I was also stating that I had never got the impression that the Elm community was going to fix those problems any time soon. This was because the community leaders/ members were often quick to dismiss any suggestions/ complaints offered instead of patiently exploring them. Indeed your characterizing of this thread as talking about some `spooky "abstraction wall"` is a testament to that. Speaking personally, those were the two-fold reasons (both technical and social) for me to switch to PureScript for my personal projects. I still think Elm is pleasant to work with and to that extent I am continuing to keep track of its progress.

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.
- sridca 9y ago
  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. It would appear that you misunderstood what I said. Elm not facilitating the use of sufficient level of abstractions does not necessarily mean one cannot use Elm to write the said app. It simply means that you would have to deal with it all at a lower level (with the corresponding code duplication where necessary) in the absence of the aforementioned capability to build abstractions. For more on this topic refer to https://en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs https://en.wikipedia.org/wiki/Structure_and_Interpretation_o... Furthermore, in the process of agreeing with the parent comment, I was also stating that I had never got the impression that the Elm community was going to fix those problems any time soon. This was because the community leaders/ members were often quick to dismiss any suggestions/ complaints offered instead of patiently exploring them. Indeed your characterizing of this thread as talking about some `spooky "abstraction wall"` is a testament to that. Speaking personally, those were the two-fold reasons (both technical and social) for me to switch to PureScript for my personal projects. I still think Elm is pleasant to work with and to that extent I am continuing to keep track of its progress.