Afterthoughts around about Kernel code and custom operators complaints

[rupert]

@wolfadex

Would it make sense to place restrictions on the forked compiler? For example, only allow the use of elm/* and elm-explorations/* packages.

That is what I was proposing, but no good to limit to just those 2. It would obviously need to include some new community controlled namespace in order to be able to commit code to somewhere that the compiler can build.

@wolfadex

Make it easy to test ideas and hard to build production apps.

Make it easy to test ideas.

Make it possible to build production applications with less risk of hitting technical blockers - in other words put the power to fix blockers into the hands of people building the application.

@jreusch

I really think a community-driven fork for experiments would benefit upstream as well, as long as the goal really is and stays to be a research project.

I was not thinking it would just be a research project. The ‘experiments’ part of it would be, and would exist as a way of letting kernel code in but with a fairly low barrier to entry - an inclusive way to experiment. The ‘pro’ part of it would not be just for research, its intention would be for production code and to provide a way for people that cannot run Elm in production due to some bug or perceived closedness of its development process that make it too risky for them to adopt.

@jreusch

How will we deal with people just using the “Pro” version? This will definitely happen, especially if answers to the common questions people encounter while learning Elm (localStorage, WebSockets, that-jQuery-Fancybox-Plugin-they-have-to-use-at-work integration) become “you could do this the official way, by manually building all this elaborate wiring where there’s a chance you might not understand half the code and concepts if you just started learning, or btw this community fork has a package for it that might work, just need to pass that extra flag, don’t worry about the details”

It should be ok to just use the pro version - so long as its compiler does not diverge from the official one. On pure Elm code, it should yield the exact same result. Personally, I would probably take care to use the right compiler for the situation though.

The hacky, and bad, way of doing things might be to use an experiment (that has a version number less than 1.0.0. Those would be clearly labelled in the package repo as ‘Experimental - Use at your own risk’.

Anything that made it through to the pro repository would have passed some quality gate, and is ready for production use - there might be an active group of people or businesses supporting it. The kinds of things I imagine you would find in the pro repository would be Dan’s video package; so only people working with video would be interested.

@jreusch

Can we prevent the official channels (Slack, Discourse) from having to deal with the problems of “pro” users unrelated to “core” Elm? Would this be a problem for the Discourse? On Slack, making and referring to a separate channel sounds reasonable. A more clearly separated branding would certainly help, but it also increases the possibility of separating the community as well.

Not really sure how that would work. Maybe it needs a completely different name, and its own comms mechanism to avoid confusion. I guess it depends on whoever runs those channels and what their views are.

@akoppela

Why do you think core team would want to merge forked compiler experiments if that does not happen now?

I don’t think they would. But I forgot to mention in my first post on this - I think any compiler/core fixes should still get PRed back, it seems only courteous.

[turboMaCk]

Just one note. I don’t think any fork should include elm in a name. I’m kind of fan of interpreting this Clause in BSD3 quite strictly:

3. Neither the name of the <organization> nor the
   names of its contributors may be used to endorse or promote products
   derived from this software without specific prior written permission.

I think it protects original authors from being tight to stuff they don’t approve of, what ever it might be. I would suggest picking up some name of the tree for name of fork will it happen. That way it would be still related but less obviously. It can be ash or oak for instance. Also if you want to be super creative there seems to be thing called Camperdownii (which would be arguably hard to type though).

Disclaimer: I personally not dissatisfied enough to switch to fork so take it as just personal opinion / suggestion.

[turboMaCk]

I don’t think they would. But I forgot to mention in my first post on this - I think any compiler/core fixes should still get PRed back, it seems only courteous.

changes in official elm/compiler happens in infrequent large chunks/batches. Be prepared this won’t be an easy job.

[gampleman]

The way I read the situation, I think there are two distinct groups/use-cases that are dissatisfied with how things are¹. I think it would be helpful to be clear in discussions which of these one is addressing, as they have quite different needs:

1. People who are using Elm for work and are worrying about getting blocked. They
   • are building applications
   • are highly time sensitive (i.e. waiting six months for maybe a solution isn’t an option for them)
   • would rather have a good enough solution now than a perfect solution later
   • don’t particularly care about long term concerns like future portability
   • care about smooth tooling (it is not sufficient that just the compiler works, it needs to work with CI systems, JS bundlers, testing toolkits, code generators, etc – this makes low effort forks problematic for them)
2. People who are trying to contribute to Elm in some way. They
   • are building packages or fixing the compiler or tooling
   • care about making a high quality contribution (even if this takes somewhat longer)
   • care about affecting others (i.e. they are not just trying to fix their own code, they want to enable others to achieve things)

For example the ability to compile Kernel code is only useful to group 1, whereas to group 2 it would only be useful if it was also possible to publish packages containing Kernel code².

I believe that the main counter-concern is, that we all want to maintain the high quality of Elm and the benefits that brings.

• For the first group, it has been repeatedly reported that after the ban of native, these people were forced to figure out ports and custom elements and they were often happier at how their code turned out³. That suggests that when the ability was there, it was fairly often used for things where it was not essential but rather as a path of least resistance.

• For the second group, the issue is that packages, once published, are somewhat immortal. Once people start depending on them, it is difficult to remove them. We have heard people complaining about Websockets going away for years now (despite that being a use case remarkably well suited to ports). This creates a lot of pressure on getting these foundational packages right.

A wacky idea for group 1

I wonder if some of these things couldn’t be balanced with adjusting the incentives by adding artificial friction. Perhaps only allowing to compile Kernel code without --optimize like the Debug modules work now and adding a 5s sleep call for each non elm or elm-explorations Kernel module compiled would be sufficient that people would only use this after trying to solve their problem every other way. Other disincentives to consider:

• Printing a humongous and nasty warning on every compile. (Elm Foundation warns: Using Kernel code may lead to lung cancer! )
• Only allowing Kernel code compilation with a crypto key. One would need to print, sign and fax a long form to the Elm Foundation to acquire one.
• Failing compilation randomly with a 15% probability.

A more reasonable idea for group 2

Personally I think the current guidelines on how to contribute to Elm are simply not good enough. Perhaps simply clearly stating something like:

Contributions to Elm are limited to the core team. The core team is based around personal relationships and we do not accept strangers from the internet. Reporting bugs is encouraged, but due to our process, please don’t expect a response.

Would be more fair in terms of expectation setting. There are many open source projects were code changes are limited to some group of people. But something like this would at least set people up with expectations that wouldn’t be frustrated. Any violations of the above would simply be happy exceptions to the rule. Whereas the current talk about how contribution works in Elm (talk, do research, coordinate, then code, …) makes people believe that as long as they follow that somewhat vague process, they are likely to succeed.

---

¹ Of course this is a simplification of reality. Many application developers would also like to reuse/share solutions to common problems for example. But I am here focusing on concerns that become extreme enough that people feel like they need to exit the community (often with a bang).

² With the small caveat that it would at least make testing Kernel code based patches somewhat easier and perhaps enable some hacky ways to get around the package system.

³ Of course there is massive survivorship bias here. Many were not and churned away - in some cases even building tooling to transform their code into a different language.

[bob-shelline]

Quick name idea to throw out there: Morel. Morel mushrooms are delicacies that grow on Elm wood.

I like the idea of a pathway for community experimentation to be able to open up like this without impeding the core team in their goals. Clearly there are some warts to work out on all this, but I think this is a good discussion to be having.

[ChristophP]

@gampleman

• Printing a humongous and nasty warning on every compile. (Elm Foundation warns: Using Kernel code may lead to lung cancer! )
• Only allowing Kernel code compilation with a crypto key. One would need to print, sign and fax a long form to the Elm Foundation to acquire one.
• Failing compilation randomly with a 15% probability.

I’d love a compiler which does all of these things I think those ideas would generate just enough WTF feelings for users to stay away from Kernel code

[rupert]

@gampleman

• Printing a humongous and nasty warning on every compile. (Elm Foundation warns: Using Kernel code may lead to lung cancer! )
• Only allowing Kernel code compilation with a crypto key. One would need to print, sign and fax a long form to the Elm Foundation to acquire one.
• Failing compilation randomly with a 15% probability.

I think the problem with those things is that they all smack of treating the user like they are stupid - and from reading comments on Reddit and Hacker News it would seem that people do feel that Elm treats them that way. None of these things are going to go down well with businesses considering adopting Elm - “So if we hit a technical blocker and need some kernel code, what are our options? Ohhh…”.

[ChristophP]

@gampleman On a more serious note. I think group 2 is really important. I would still like to prevent making the use case for group 1 too easy.
Here’s my reasoning, I think that explorative activity that is community driven would be really helpful in terms of exploring APIs, fixes, browser features, etc., since that part of community experimentation is currently sorely missing.

I also like the idea of printing the warning you suggested about how “Contributions to Elm are limited to the core team.”

[gampleman]

Most of these are a joke.

But I think the idea itself isn’t completely hopeless. Limiting these away from --optimize mode and printing a warning explaining why Kernel code is a bad choice and what the alternatives are might just be good enough. Making it compile slowly (whether that’s a sleep call or just some expensive computation that is intentionally not optimised) could help as well. That might just strike the right balance of not being the path of least resistance, but being there when it is truly needed.

In fact I believe that Group 1 likely doesn’t need Kernel code in the majority of cases. It’s more the fear of needing it in the future and suddenly running out of options that scares them.

[pdamoc]

@gampleman

But I think the idea itself isn’t completely hopeless.

These are technical solutions to an adaptive challenge. They are simply the wrong class of solutions.

The challenge with Elm’s private API is not technical. It is not a matter of safety or technical complexity of the code but a matter of values, a matter of beliefs and a matter of approach.

I would be less surprised by Evan giving up programming and switching careers to become a political analyst than by him implementing the kind of technical solutions that I’ve seen suggested when this kind of discussions come up.

I believe that for the foreseeable future, Elm will have a single author that will work on it on his own terms. Some people will accept this and stay. Some will not accept it, they will get progressively more frustrated and at one point they will leave.

[gampleman]

While I agree with the general thrust of your post, I would not call these technical solutions, as they are chiefly psychological: they are designed to address a psychological problem (fear of future problems) by psychological means (changing the incentive balance by various nudges).

In other words, my hypothesis runs like this:

1. A certain group of people (I call them group 1) are worried that they will unexpectedly¹ need the full flexibility of Kernel code in the future and they will face unpleasant circumstances in their workplace because they will not be able to deliver.
2. However, when this flexibility used to exist, despite being discouraged in the community, it was used in a number of situations where it was not necessary and better solutions existed. This is undesirable for everyone involved and part of the reason for the current restrictions. The main explanation is that it seemed easier than the alternatives.
3. Suitably changing the incentive structure may allow both of these goals to be accommodated.

---

¹ Unexpected, since if you are expecting upfront to need capabilities for which Elm is currently unsuitable, then according to the advice which is now even in the official guide, you should just pick a different technology for the project.

On a more personal note from running an Elm project in a commercial setting where the powers that be had a very begrudging approval of using Elm it had some emotional rollercoasters for me: The joy of how much easier most things were compared to the React stack we were using for other projects combined with the fear of being asked to do something for which there was no pre-existing library and suddenly I would spend 4 times as long working out the best way to hack something together. Generally these fears mostly didn’t materialise, but I can empathise with folks who feel this a lot stronger in less secure situations.