4 ms·

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

• 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
• jasonwelk 9y ago
  Count me among the converts who moved from Elm to ClojureScript, and I'm loving the FP as much as ever. I like quite a bit about Elm, but the main issue came down to productivity and workflow. You can do the same things in either language with the proper time, but Elm requires a lot of extra code and effort to so some simple things, and much is not obvious. When discussing things with other Elm developers, they would tell me "there's not good way to do that now, but here are some hacks to get it to work; hopefully this will change some day." And I hit that time and time again. If you've used Elm for a long time, maybe you already know all the hacks, but I found it disruptive to my flow. With ClojureScript, I do spend a little more time dealing with the occasional console error, but this is a lot less time than having to find the tricks to do certain things in Elm. I can appreciate the goal of purity and rigid typing in Elm, but it definitely came at a cost in development time. My ClojureScript apps are about half as much code and at least half the time spent writing them. One of them currently has about 2000 users and not one has sent a report of any runtime crashes, so I think the frequently-cited horror of runtime problems is somewhat exaggerated when justifying the strong restrictions Elm imposes on the development process (and for what it's worth, you still get runtime exceptions in Elm, just maybe a few less than in other languages). Someone recently posted in the Elm Slack a screenshot from the Chrome console of a live production app with many users that started throwing runtime stack overflow errors on a recent version of Chrome. Apparently it was caused by another of these non-obvious problems that required he break up certain lists into concatted lists instead, which was not idiomatic but necessary for the Elm runtime. Anyway, that's just my $0.02. With ClojureScript I still get all the functional idioms and immutable data and persistent collections, and it has a deeper and more interesting core library for FP that really lets you abstract data manipulation in creative ways, which is a great bonus.
• hellofunk 9y ago
  > Also true of every programming language, except for the abandoned ones. :) You are throwing some hyperbole around here. We are discussing the shifting foundation for abstractions in Elm, and I'm pointing out that Elm is a young language that has changed its design patterns significantly in the last year or two, the language is not so mature yet, and is probably years from 1.0 stability. That's a perfectly valid point to make in any discussion about the language's design choices. Your blanket generalization about all programming languages is perhaps your way of agreeing with some developers' frustrations in Elm. It kind of reminds me of the Steve Jobs' excuse during the iPhone 4 antennagate when he slyly admitted to the problems by saying "look, all cell phones have problems."
  • rtfeldman 9y ago
    > Elm is a young language that has changed its design patterns significantly in the last year or two In the past 2 years there was one big change (0.16 -> 0.17) that said "instead of being best practice, the Elm Architecture is now the only way to do it." [0] Every other release has not meaningfully affected design patterns as far as I can remember. That said, I agree that it's fair to consider "removing alternatives to the best practice" a significant change of design patterns. For for those who had been following different patterns, I know it was a big change. You're also right that Elm is a young language, and there's inherent risk of change that comes along with that. :) > perhaps it is unfair to expect it to be as capable and mature as alternative languages. I don't want to claim Elm is flawless, or for that matter stable and mature—because right now it's none of those things. Sure, it's been battle-tested and proven more than capable, but of course that's not the only factor in choosing a language. I would note that from what I've heard, among functional altJS languages Elm is second in maturity only to ClojureScript. (I base that on conversations I've had with users of CLJS, PureScript, ReasonML, GHCjs, and ScalaJS.) As far as I can tell, the only other "alternative language" that's more mature than Elm is JavaScript itself—or maybe TypeScript, if you count that as a separate language. To be clear, what I do want to claim is that Elm is a strong choice for typical web applications. That's true of small ones, medium-sized ones, and especially big ones. Again, when I make that claim, I'm not saying that everyone should choose Elm for their project. Projects differ, and people have preferences. Elsewhere in this comment thread is someone who preferred ClojureScript, and someone else who preferred PureScript. Great! :D What I'm saying is that nobody should be concerned about whether Elm applications can scale well. They already have scaled well for plenty of projects. There clearly is not some "abstraction wall" that prevents this from happening, and people having personal preferences for other languages' design choices doesn't imply otherwise. :) [0] http://elm-lang.org/blog/farewell-to-frp http://elm-lang.org/blog/farewell-to-frp