> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
