4 ms·

Just yesterday on Slack some experienced members were pointing out the workarounds necessary to handle certain challenging abstractions, things which are still

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.
  - rtfeldman 9y ago
    > It would appear that you misunderstood what I said. Could be. The point of the paragraph after this seems to be self-evident (if an abstraction is unavailable, then you use a lower-level alternative). If that was what you meant, then I agree...and I don't think I needed to have read SICP to know that. ;) > This was because the community leaders/ members were often quick to dismiss any suggestions/ complaints offered instead of patiently exploring them. I would describe this particular issue as having been "patiently explored to death." Here are several links demonstrating this: [0] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/T2I_8L-AL6EJ https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/T2I_... [1] https://www.youtube.com/watch?v=oYk8CKH7OhE https://www.youtube.com/watch?v=oYk8CKH7OhE [2] https://github.com/elm-lang/elm-compiler/issues/1039 https://github.com/elm-lang/elm-compiler/issues/1039 [3] http://faq.elm-community.org/#does-elm-have-ad-hoc-polymorphism-or-typeclasses http://faq.elm-community.org/#does-elm-have-ad-hoc-polymorph... > Elm not facilitating the use of sufficient level of abstractions [...] I had never got the impression that the Elm community was going to fix those problems any time soon. [...] Indeed your characterizing of this thread as talking about some `spooky "abstraction wall"` is a testament to that. This quote characterizes Elm as not having "sufficient level of abstractions" and that these are "problems" that are not being "fixed." My reference to the "abstraction wall" is also a direct quote from a previous comment. [4] All of these quotes frame personal preference as objective fact. It's like saying Java is "broken" because it does not support manual memory management, which no one seems "interested in fixing" by adding `malloc()` and `free()` to the language. Plenty of people would (rightly!) be upset if Java introduced `malloc()` and `free()`, thus breaking the invariant that everything is garbage collected. Likewise, there are many happy Elm users, myself included, who think Elm would be substantially worse if it moved toward the abstractions that PureScript embraces. The fact that Elm doesn't is a benefit from our perspective, even if it's a drawback from yours. Neither of us have "wrong" preferences. There's no universally correct answer here. We can both go about building Web applications in our languages of choice. This distinction may not matter to you, but to someone wondering whether Elm is worth looking into, there's a big difference between "I am inevitably going to hit a wall" (which is not true) and "not everyone agrees with Elm's design decisions" (which is of course true). [4] https://news.ycombinator.com/item?id=14877406 https://news.ycombinator.com/item?id=14877406

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.
- rtfeldman 9y ago
  > It would appear that you misunderstood what I said. Could be. The point of the paragraph after this seems to be self-evident (if an abstraction is unavailable, then you use a lower-level alternative). If that was what you meant, then I agree...and I don't think I needed to have read SICP to know that. ;) > This was because the community leaders/ members were often quick to dismiss any suggestions/ complaints offered instead of patiently exploring them. I would describe this particular issue as having been "patiently explored to death." Here are several links demonstrating this: [0] https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/T2I_8L-AL6EJ https://groups.google.com/d/msg/elm-discuss/oyrODCgYmQI/T2I_... [1] https://www.youtube.com/watch?v=oYk8CKH7OhE https://www.youtube.com/watch?v=oYk8CKH7OhE [2] https://github.com/elm-lang/elm-compiler/issues/1039 https://github.com/elm-lang/elm-compiler/issues/1039 [3] http://faq.elm-community.org/#does-elm-have-ad-hoc-polymorphism-or-typeclasses http://faq.elm-community.org/#does-elm-have-ad-hoc-polymorph... > Elm not facilitating the use of sufficient level of abstractions [...] I had never got the impression that the Elm community was going to fix those problems any time soon. [...] Indeed your characterizing of this thread as talking about some `spooky "abstraction wall"` is a testament to that. This quote characterizes Elm as not having "sufficient level of abstractions" and that these are "problems" that are not being "fixed." My reference to the "abstraction wall" is also a direct quote from a previous comment. [4] All of these quotes frame personal preference as objective fact. It's like saying Java is "broken" because it does not support manual memory management, which no one seems "interested in fixing" by adding `malloc()` and `free()` to the language. Plenty of people would (rightly!) be upset if Java introduced `malloc()` and `free()`, thus breaking the invariant that everything is garbage collected. Likewise, there are many happy Elm users, myself included, who think Elm would be substantially worse if it moved toward the abstractions that PureScript embraces. The fact that Elm doesn't is a benefit from our perspective, even if it's a drawback from yours. Neither of us have "wrong" preferences. There's no universally correct answer here. We can both go about building Web applications in our languages of choice. This distinction may not matter to you, but to someone wondering whether Elm is worth looking into, there's a big difference between "I am inevitably going to hit a wall" (which is not true) and "not everyone agrees with Elm's design decisions" (which is of course true). [4] https://news.ycombinator.com/item?id=14877406 https://news.ycombinator.com/item?id=14877406