About the elm leadership

Learn
1

I’m an elm lover. I’m using elm in my developer life, as both for my personal projects and for consulting or industrial projects. I think it’s one of the best language in those past years, and I globally agree on the design decisions of the language.

I strongly think that closing native/kernel code is a good idea (and that’s how it should be since the beginning). I’m not writing V8 bytecode when writing JavaScript, why should we when writing elm? But, in the last post about Native Code in 0.19, one point bothered me. I got the feeling that @evancz is alone writing, developing, designing elm. OK, he’s delegating some work to others (mainly in elm-community and elm-explorations), but when looking at elm-lang in github, Evan is the main contributor for the majority of the packages. I feel that Evan is the guarantee that elm is working. We’re all dependent of a software written by one person. (Have a look at GitTrends is you have some doubts.)

What about the bus factor? And what about the time that Evan can spend to both maintain elm, develop new features, think about technical debts, etc. and having a happy life? In the last post of Evan, he said:

I can focus on any web platform libraries that are show stoppers for people.

That reinforces the growing feeling I got since the beginning. Evan is working for everyone, and will one person be sufficient for supporting the entire community? What will happen when the community will be larger than today?

In another language, you can do what you want when jumping in, and if you disagree with the leadership, well, you can always write what you want on your own. In elm you will not be able to do it. So if you really need some thing and can’t deal with the actual solution (i.e. ports, for good reasons), you can only ask the community and hope that Evan will take care of your problem (or maybe elm-explorations will be able to solve your problem?).

I really would like to open the discussion (and not ended up in trolling), to get a better overview of the elm state today, how it will evolve, etc. It is a real question for me those days. I feel that people could be angry about Native Code interdiction because it feels like an arbitrary choice ; because the “Tell me what you need to do, I’ll tell you how to get by” is not a correct answer ; and because the people able to solve the problem once and for all (and not trying to easily solve it with ports) will not respond (because he doesn’t have time for this, I think). I feel like we could do things better, maybe by involving more persons in the elm team, maybe another way I don’t know.

Once again, I don’t exactly know where to post this? I don’t know if it’s the good place or if it resides on Slack or on Google Groups, but I think that posting it here publicly could be good to reassure people and showing that the community is aware of its problems and tries to fix it the best way possible!

If I’m wrong about those feelings, I think it would be so cool to have a place which can easily be found be everyone, exposing the elm development philosophy, and how it is planned to evolve.

6 Likes
2

Some thoughts:

  1. This approach has a track record of success. Python, Ruby, C++, and Rust were also 1-person shows for the first ~5 years. It did not stop them from being successful, and in fact they might not have been successful if their authors had focused on delegation before they were ready for it.
  2. Community contributions to elm-lang/ have been increasing. The next core release has an Array implementation written by Robin and a Random implementation written by Max. elm-format and elm-test are on a similar trajectory, as are new Dict implementations Robin has been working on using the same approach. I predict community contributions will (gradually) continue to increase over time, and I think trying to rush that process can easily do more harm than good.
  3. There are no shortcuts here. We have tried delegation experiments in the past that failed, and today we’re trying new ones. If they work better, great! If not, it’s back to the drawing board. Each failed experiment comes at the expense of other progress, so rushing to do more of them can do more harm than good too. Delegation experiments are not free.

I understand where these concerns come from, but the reality is that it often takes more patience to be an early adopter of a successful programming language.

That may not be a satisfying answer, but it’s the truth.

23 Likes
3

Evan explained much of his development philosophy in his talk, Code is the Easy Part, which I finally watched recently and really enjoyed.

6 Likes
4

An interesting experiment by the Red Language team - http://www.red-lang.org/ where they’ve created a foundation, and sold cyber currency that will be used as rewards to developers to incentivize the development of the language

“The role of the Foundation, as explained in the announcement article and in the RED whitepaper, is to manage the whole Red open source project, and set up a new economic model for open source projects using the RED token.”

Red whose language ancestor was Rebol had a situation where the language author stopped developing the project, and Rebol languished for years.

1 Like
5

I think this is off topic, because Evan does not lack funding and development is not in danger of stopping any time soon. Quite the opposite even

2 Likes
6

As a part-time professional but mostly hobbyist, I find that Elm is at least 10 times as productive as that colossal rotten mass called Javascript. I can’t envisage any JS programmer, shown Elm, not wanting to change.

What Evan has achieved in a very short time, is extraordinary, and I’m happy to let him and his close advisers, move forward as they will.

They’ve already provided me with more benefits than I could possibly repay.

7 Likes
7

I agree (edit: well, maybe except the “colossal rotten mass” :joy: that seems a little too strong, I still like some javascript features and evolutions).

I think that most of the friction that can be noticed now comes from the difference in perspectives between Evan planning for a well thought, robust and simple front-end language for 1.0 in a few years and people like me that use professionally Elm because it already provides most of those. Hobbyists are likely more inclined to share the long term vision and to restrain their impatience.

Having to satisfy customers or being in production right now leads to frustrations that would not exist if the language was already 1.0. This makes me sometimes feel schizophrenic, fully agreeing with Evan’s plan, and still agreeing with frustrated developers. But at the end, I really want to see the final vision becoming a reality, and would not like to be part of something breaking it.

As @rtfeldman said:

7 Likes
8

Sorry, don’t mean to imply that. Just thought it was an interesting approach to the funding of development.

10

Folks, I don’t think any new ideas are going to come to light in this thread that we don’t already understand. We’ve heard “just delegate” and “bus factor” more times than we can possibly count. It doesn’t help us very much. It’s time to wrap up this discussion.

1 Like