This is a good thread. I think a lot of important opinions have been voiced here so far.
The thing I personally miss most, and I think this is also what Peter was getting at, is a new big statement on the direction and the process. I personally started to do some serious work with Elm last autumn, shortly after 0.16 was released. Since then, I witnessed several discussions that were postponed until the next version, 0.17, were to be released (native modules, specific parts of the web platform that people wanted to expose, ...). And I think by and large everyone was ok with that. Now 0.17 has come, and it has brought changes (that are great!) and some indication that "the whole web platform is not that much" and it will be covered at some point - which sounds very promising. But there is no roadmap. There is no document I can read on how to contribute. It seems to me that this creates real tension. Noah, I appreciate your comments, but I think that most frustration is not with the slow pace of the language development, but with the inability to share solutions for everyday problems we have. Evan, I think we all agree here that the consideration you take with language and API design is absolutely warranted and that your decisions in these matters are great. But it would be great if we could get an idea how you want to go on from here and where you think the community could help. A lot more people read this newsgroup than write on it. I have spoken to some who have told me that they really like Elm but don't want to use it because of the unclear direction and the frustrations in the community. I think that it would not take much to remedy this. On Friday, June 3, 2016 at 9:24:32 PM UTC+2, Ryan Rempel wrote: > > 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
