4 ms·

> Also true of every programming language, except for the abandoned ones. :) You are throwing some hyperbole around here. We are discussing the shifting founda

> 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

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