> > I'm going to call out the air of ungratefulness and animosity in this > thread. Evan is giving you software for free, and it's software that's good > enough that you invest your time into writing it and commenting about it. > You should not expect Elm to move at the same pace as Angular (backed by > Google) or React (backed by Facebook). Calling out that you want something > done faster or differently, when you are not a financial backer or core > contributor (to be fair, there aren't any of those besides Evan), comes off > as extremely petulant.
Respectfully, nobody forced Evan to release and promote a programming language; the community that's formed around Elm is entirely of his own making. If there is a feeling of animosity in the community and Evan wants to dedicate resources to improving it, he can choose to... or he can choose not to... that's his choice, but the atmosphere of the community will in part be a reflection of how he is allocating his time and energy towards supporting and maintaining it. On Sunday, April 30, 2017 at 11:43:30 AM UTC-4, Max Goldstein wrote: > > First, I'm going to call out the air of ungratefulness and animosity in > this thread. Evan is giving you software for free, and it's software that's > good enough that you invest your time into writing it and commenting about > it. You should not expect Elm to move at the same pace as Angular (backed > by Google) or React (backed by Facebook). Calling out that you want > something done faster or differently, when you are not a financial backer > or core contributor (to be fair, there aren't any of those besides Evan), > comes off as extremely petulant. > > Second, as for elm-community hosting the "greylisted" packages. I'm a core > member of elm-community, although obviously I don't speak for the group and > opinions are subject to change. I think that elm-community is doing a good > job of providing high-quality packages, which largely means they are 100% > Elm and have the reliability and free distribution that comes from that. > Almost all of our packages are in maintenance mode, stewarded for people > who left the community but who wrote useful packages that need to keep pace > with language version bumps (oh hello original thread topic). With a small > number of exceptions, most of our packages aren't actively developed. > > Third, regardless of who hosts the greylist, there are other problems. > When Evan removed the old graphics library from core and spun it off as a > separate package, he inadvertently added or multiple > <https://github.com/evancz/elm-graphics/issues/3> runtime > <https://github.com/evancz/elm-graphics/issues/14> errors > <https://github.com/evancz/elm-graphics/issues/8> (or perhaps the > surfaced later). This was a well-used library with native code, meant to > not change as it was extracted, by Elm's creator, and runtime errors still > happened. It is very easy to break everything that makes Elm nice with > native code. Using ports means that you're writing more-or-less normal > JavaScript, and it's yours to debug, lint, and fit to your needs, rather > than be stuck on a broken library. The open source dream of a project with > 100 stars and recent commits is appealing, but what happens during the > bring-up when no such project exists? What happens if it never does? What > happens if multiple projects look good? > > Fourth, web components were briefly mentioned. Richard gave a talk on > these <https://www.youtube.com/watch?v=ar3TakwE8o0> last year and it > seems like everything you need already works. > > Fifth and finally, to say something positive. (*If you're skimming, > please read this part.*) The greylist is built on the idea that the best > way to help is by writing code. Instead, let me suggest a collection of > markdown documents that research a particular proposed addition and say why > it would be useful. This is like doing the lit review before getting to > work, and will be helpful to both Evan, anyone pressing ahead with the > greylist, any anyone on the list confused as to what a task port is (for > example). I think these documents should, for a topic X, define X, say why > X is useful, describe the best way(s) to do X in Elm today, describe how > other ML-family and JS-ecosystem languages do X, and finally include a > brief, "first draft" of an interface or API for X in Elm. I think this will > work well for "web platform" things (audio playback, binary data) much > better than language features (type classes). > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
