That only depends on your definition of good tool vs. bad tool. You're painting a doomsday picture here. In the context of real world usage and mainstream adoption, it isn't so black and white. Java is a hugely popular language, but it has fundamental flaws, like nullable values. Yet there are so many great things that have been built with Java/C++/insert language/technology here. It was certainly a huge step forward from what was before, C/C++/insert language/technology here. People thought nulls were good it the time they designed Java. Later on, we learned that there were better ways to do things. That's the way technology evolves. You cannot take tools back, but you can give people new tools. If the bad tools aren't widely replaced with the new tools, then maybe the bad tools weren't so bad after all, or at least they were good *enough*.
Even Elm will make fundamental design flaws that we aren't aware of, and won't be aware of until we learn from them. Nothing lasts forever; even Elm will one day be obsolete, which is a good thing, because then we will have another, even greater language/technology, based on lessons learnt from Elm! Who knows, maybe that new language promises Elm interop, to benefit from the large Elm community/ecosystem, just like Elm promises JS interop today. People were discussing Elm 1.0 more than 3 years ago, and it hasn't happened yet. I think there's a general fear of release number 1.0 in the open source community at large. But even if Elm 1.0 is released, with its inevitable design mistakes, that doesn't mean the end of Elm. (nulls weren't the end of Java either). It will always be possible to release Elm 2.0. At least I hope the ecosystem opens up soon, I would be sorry to see a great project like Elm suffer from Perfectionist's Dilemma, never accepting the risks of an open ecosystem, and never achieve broad adoption. onsdag 26. april 2017 22.00.53 UTC+2 skrev Joey Eremondi følgende: > > There is an underlying premise of Elm that there is One Correct Way™ to >> solve a problem in an application written in Elm, it takes "a long time" to >> discover the One Correct Way™, and Evan is the only person capable of >> doing it. > > > It's not that there's one way of doing it, but that once a bad way of > doing it is widespread, it never dies. Once you give people a tool, you can > never take it back, even if it is a bad tool. The goal is to make Elm solid > *before* 1.0, so that after 1.0, we won't be plagued by backwards > compatibility issues. > > On Wed, Apr 26, 2017 at 12:57 PM, Eirik Sletteberg <eiriksl...@gmail.com > <javascript:>> wrote: > >> I used the persistent-cache code once. I just copied the source code into >> my project. The library readme makes some bold statements, like "it is the >> right technical choice" to expose a LRU cache for localStorage in Elm. It >> certainly wasn't the right choice for my use case, where "least recently >> used" wasn't a relevant factor regarding which elements to retain in >> localStorage; there were a few very important keys, and a couple of "less >> important" keys. The Task-based LocalStorage API that is included in >> persistent-cache works very well. It works very well because it mirrors the >> native API. As a developer, I also prefer the freedom to make my own >> technical choices that are right given the circumstances. I need the power >> of the Web API, I just want it with types and without runtime exceptions. >> >> There is an underlying premise of Elm that there is One Correct Way™ to >> solve a problem in an application written in Elm, it takes "a long time" to >> discover the One Correct Way™, and Evan is the only person capable of >> doing it. (An exaggeration of course) As far as web APIs are concerned, >> there is only one Correct Way™ we all have to deal with, which is W3C >> standards, as they are implemented in the browsers. Maybe it's possible to >> take WebIDL definitions and convert them to Elm bindings, then one would >> have a type-safe, exception-free interface to the browsers, without all the >> maintenance overhead. >> >> BDFL for both a language and its ecosystem is perfectly fine for a >> project philosophy, but it is intrinsically linked to having a small niche >> community. Then again, broad adoption may not be a significant priority for >> Elm during the next few years, so that might be a good thing. In the case >> of commercial software development, cash is king, and delivering working >> features is the top priority. Nobody cares that your car is shiny and >> polished, if it cannot drive in reverse. The article Choose Boring >> Technology <http://mcfunley.com/choose-boring-technology> comes to mind. >> >> Bottom line, there is a huge untapped potential here, people are excited >> about Elm, want to use it in production, but then there are small things >> like missing support for localStorage, file uploads, audio playback, binary >> data, being able to control event.preventDefault(). Many of those are >> problems that people would fix themselves and publish as a package. All it >> takes is to trust the broader community. Even if you end up with 5 >> different libraries dealing with cookies, one of them will probably >> prevail, and all 5 of them will learn from each other's advantages and >> drawbacks. I don't buy the argument that opening up the ecosystem will ruin >> Elm's guarantees - I would trust the robustness of a third party cookie >> package with 5000 GitHub stars and 100 merged pull requests just as much as >> (or more than) I trust the Elm core. Just look at what npm did for the >> JavaScript community. Look at the success of React and Redux, which are >> more or less based on TEA. But they have excellent JS interop and an open >> ecosystem. Wouldn't it be great if Elm were just as widespread? And had >> just as many contributors? >> >> >> onsdag 26. april 2017 19.28.59 UTC+2 skrev Wojtek Piekutowski følgende: >>> >>> The thing is that this exact kind of cache (LRU) might not work for all >>> people, so it'd be great to have barebones interface to >>> localStorage/sessionStorage/etc. Then higher level abstractions, like >>> persistent-cache, could be easily built on top of it. >>> >>> On Wed, 26 Apr 2017 at 18:24, Mark Hamburg <mhamb...@gmail.com> wrote: >>> >>>> Exactly and look at the months old comment at the top of the read me: >>>> >>>> NOT RELEASED YET — I hope to release it relatively soon, but I cannot >>>> make any promises. Until then, please use ports if you want to use >>>> localStorage. >>>> >>>> >>>> On Wed, Apr 26, 2017 at 9:22 AM Rex van der Spuy <dandy...@gmail.com> >>>> wrote: >>>> >>>>> On Wednesday, April 26, 2017 at 5:07:39 AM UTC-4, Wojtek Piekutowski >>>>> wrote: >>>>>> >>>>>> >>>>>> https://github.com/elm-lang/persistent-cache? >>>>>> >>>>> >>>>> Wow, that's exactly what I need! >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> 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...@googlegroups.com. >>>>> >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> >>>>> -- >>>> 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...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >> 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...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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.
