I have only been part of the Elm community for something like 7-8 months, but i'll still take the chance and say a few words. I hadn't seen part 1 of this topic https://groups.google.com/forum/#!msg/elm-discuss/np3BO9X5rEc/jG3AIiU2zYEJ before, but found it enlightening.
- I'm not worried about the pace of the language, I love that everything is thorough and really well thought through - I'm fine with Elm maybe not being ready for *me or my projects* in production. Of course that might be me misjudging what I perceive I feel is missing but in reality there are alternatives to solving those concerns. If indeed it's not suitable for my cases maybe it will be in 0.18 or 0.19 or whatever. I'm totally cool with that. I'm still having a blast playing with Elm regardless and I'm having trouble not sharing my growing enthusiasm. - I also realize that there are many considerations and priorities that I'm not privy to and don't need to or have no entitlement in knowing about Like any enthusiastic Elm community member I've invested lots of time learning the language, trying to understand the philosophy behind it, contributing where I can and sharing with the rest of the community and beyond. I have learned tons, had a great time and I'm thankful for Elm in so many ways. That's a really big reward in itself. Evan: I think what you have done and keep doing is amazing. My only really big concern is what I wish that I was able to see more signs that other people in the community were being trusted. And if sometimes people fail to live up to that trust, because they are humans and make mistakes, that's something you can live with. To me as an outsider (sort of, mostly I guess), it seems every minute little issue in the Elm repos, even tiny spelling mistake issues have to go through you. It's difficult for me to understand why this needs to be the case or even why it's taking time to address. Surely there must be a few others in the community that have shown they are worthy and could at least be allowed to resolve the simpler issues. Process bots and issue templates might help reduce the number of issues and hopefully improve the quality of issues. But I don't see automation as the solution to the bigger things that needs addressing, one of which I feel is the bus factor the other probably a little more open communication on where things are going forward. Before the release of 0.17 I felt at one point that I had unknowingly signed some sort of NDA for a Company with business critical secrets that would somehow destroy a competitive advantage if even the tiniest leak should happen . It came to a point where I wasn't even sure I could use Elm and 0.17 in the same sentence. That's obviously not a rational response for your call to keep things under the lid from my side. But at that time I remember thinking : "hey this doesn't feel like being part of an Open Source Community". I hope I don't end up feeling this way in the future, then I guess I might be better off staying away from any "Do not share" info altogether. To contradict myself to a degree and to empathize with the wish/need for secrecy, I compare with what recently happened with Clojure Spec recently being announced. I had no clue (and I do follow the community there too, although not nearly as much as Elm), but the big difference being it didn't break anything, had no impact on any of our production apps and it was just really a nice addition which is an option for us to use. You've already elaborated your reasoning behind the secrecy, I'm just giving you some feedback how I feel/felt for whatever that's worth. I'm not saying I'm right, consider it another data point if you like. I'm encouraged by Noah's reply above, even though I'm perhaps being unfairly impatient hoping for more clear visible signs sooner rather than later. cheers -magnus On Friday, 3 June 2016 17:01:01 UTC+2, Noah Hall wrote: > > > I must say one of the main reasons I'm not using Elm today nor do I plan > to use it on the medium term is how slow paced, constraining and tightly > controlled it is. > > I disagree that it's slow paced. I agree that it is constrained and > tightly controlled. Part of this is the focus on delivering Elm as an > entire, functional product that you can use and trust. There are some > negatives to this, like Evan doing all the work alone. I agree that > this is not ideal. But look at the end result we have - Elm is a > language that I can trust and work with day in, day out. With less > control over core, this wouldn't be possible to the same extent. That > isn't to say that it's not possible to still have a fully furnished > product without the control - but there is a process shift that needs > to happen in _the right way_ to make that happen. > > > All this to say, Elm has been created 3 years ago, I sincerely hope it > will start to solve problems at a faster pace and be more open to the > community. > > I think the biggest problem is not about solving problems at a fast > pace. At NRI, we have solved all kinds of problems other people want, > and it wasn't a lot of work to implement them. Solving these problems > at a fast pace is almost my entire job. > > But - developing things at a fast pace is not the way to create a > reliable or well designed language. We can trust our solutions > interally, since we know they work for _us_. That doesn't mean that > they will work for everyone, but as a result from our experiments, we > can give feedback upstream and help model the language by being part > of the community. Part of maintaining good language design is to not > just evaluate one use case and say "oh hey well it works for NRI, so > who cares about the rest". Most contributions have selfish reasons in > mind as to why they are contributed. > > Being open with the community is a problem, and Evan has heard this > problem. As you can imagine, it sometimes come down to "write an email > in reply to A" or "write some code for this bug X that are blocking > people". It's frustrating for there to be no reply, I know. But there > is a good reason for it. This is a problem that's very dear to me, and > there is some stuff in the works to solve it, but it's not a simple > solution, and it needs a lot of thought on how to be proactive. > > The biggest problem has been the changes in 0.17, for some people. > There were approaches possible in 0.16 that aren't as easy in 0.17. > 0.17 is a better language, and html is a better framework. More > openness on this shift would've helped a bit here - a thread was made > on the changes to Html, but not so much as to what would happen to > signals. I believe I'm probably one of the people who has upgraded > most code from 0.16 to 0.17, and I know that it is possible to upgrade > everything. And almost everything I've upgraded has left me feeling > like "woooo this is much better!". So it's not a technical deficiency > here - the foundation is good. It's hard to communicate with everyone > about their particular use cases, though. > > > tl;dr - You aren't wrong to be frustrated, but there are good reasons > for the things that are frustrating you. > -- 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.
