4 ms·

I'm familiar with those controversies, and most if not all of them I would side with the Elm team. The thing is that, yes it is nice to get user-driven developm

by lalos 6y ago

I'm familiar with those controversies, and most if not all of them I would side with the Elm team. The thing is that, yes it is nice to get user-driven development but they seemed to be proposing to bring back concepts from their OO experience and/or baking in features that should not be part of the core library and are easily implemented if you understand how Elm is wired. Seems like these users are excited to contribute but need to get more familiar with FP before contributing to a higher level FP library. I remember one where the proposal could be easily be implemented generically with ports and any other JS library instead of bringing some weird binding logic to A specific JS library. Add the fact that devs from the FP world are concise with their explanations and you have a recipe for miscommunication problems when trying to explain why that idea is DOA to someone not familiar with core FP concepts.

Latty 6y ago
Eh, it isn't just that though. I recently made a big push to try and get a relatively small change through (setting CSS Custom Properties), which is a big blocker for using a lot of web components (which is officially suggested as a way to deal with interop for the language), and will likely block interaction with future web APIs that use custom properties. I went through and collected up the reasons to do it, distilled it down and gave examples as requested by the core team and got lots of positive feedback from the community, and just got no response from the core devs and nothing happened. I agree not all changes people propose are good, I like the fact the language is opinionated and doesn't include half-baked ideas, but there is literally no way to get anything through into Elm core, any attempt to do the legwork is just ignored and thrown away. It is a one-man project and that's it, but they pretend that isn't the case. Honestly, the answer is probably an unstable fork of the language for more experimentation and development, which to be fair, anyone could do¸ but obviously maintaining that would be a lot of work (I don't want to imply that the core Elm team have some responsibility to do it).
pcstl 6y ago
That's not really what I'm talking about. For instance, a few years ago when I was really into Elm, I wanted to implement a WebAudio library. Back when Elm was an FRP language, I thought it would be a great fit with the language's model. I even got a proof of concept working and showed it off in the Elm Slack. And then I got told my library would not get accepted on the official package repository because the core team was developing their own "correct" abstractions for the main Web APIs and they did not want third-party libraries to compete with the core team's libraries, as regular web developers don't know what they're doing and are incapable of choosing the "right" abstractions, which apparently only the Elm core team is capable of doing. That experience turned me off Elm for good. Flash forward to 2020: There is still no "official" Web Audio library. (There are a few non-official ones on Elm Packages) It's your right to side with the core team, but they're the ones pretty much killing the language's chance to see any real usage.

by lalos 6y ago

Latty 6y ago

Eh, it isn't just that though. I recently made a big push to try and get a relatively small change through (setting CSS Custom Properties), which is a big blocker for using a lot of web components (which is officially suggested as a way to deal with interop for the language), and will likely block interaction with future web APIs that use custom properties. I went through and collected up the reasons to do it, distilled it down and gave examples as requested by the core team and got lots of positive feedback from the community, and just got no response from the core devs and nothing happened. I agree not all changes people propose are good, I like the fact the language is opinionated and doesn't include half-baked ideas, but there is literally no way to get anything through into Elm core, any attempt to do the legwork is just ignored and thrown away. It is a one-man project and that's it, but they pretend that isn't the case. Honestly, the answer is probably an unstable fork of the language for more experimentation and development, which to be fair, anyone could do¸ but obviously maintaining that would be a lot of work (I don't want to imply that the core Elm team have some responsibility to do it).

pcstl 6y ago

That's not really what I'm talking about. For instance, a few years ago when I was really into Elm, I wanted to implement a WebAudio library. Back when Elm was an FRP language, I thought it would be a great fit with the language's model. I even got a proof of concept working and showed it off in the Elm Slack. And then I got told my library would not get accepted on the official package repository because the core team was developing their own "correct" abstractions for the main Web APIs and they did not want third-party libraries to compete with the core team's libraries, as regular web developers don't know what they're doing and are incapable of choosing the "right" abstractions, which apparently only the Elm core team is capable of doing. That experience turned me off Elm for good. Flash forward to 2020: There is still no "official" Web Audio library. (There are a few non-official ones on Elm Packages) It's your right to side with the core team, but they're the ones pretty much killing the language's chance to see any real usage.