Noah, that is a very thoughtful post, and I appreciate it. I think you are right that problems can be solved at a fast pace, and that many people can do that. The thing which is sometimes frustrating is the limits on sharing those solutions.
I wonder whether this might feel a little different inside NRI than it does outside NRI. Inside NRI, I'm sure you've got ways of sharing solutions between different programmers. When you, personally, solve some problem, there is some way of "publishing" that solution for others within NRI to use. Outside NRI, we don't have that. Well, we have elm-package. However, you can't use elm-package for anything that involves Javascript code or an effects manager. You can't even use elm-package for the most elm-ish way of dealing with Javascript, via ports. Now, presumably NRI has some internal mechanism for sharing code between developers that doesn't rely on elm-package. Perhaps you "install" each other's work via git in some way. I'm sure it works well for you. -- Ryan Rempel On Friday, June 3, 2016 at 10:01:01 AM UTC-5, 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
