Issue #15966 has been updated by Eregon (Benoit Daloze).


mame (Yusuke Endoh) wrote:
> I have not yet made up my mind to this proposal, but I think of:

Thank you for your reply! I will reply inline for better context.

> * The process will make Ruby's evolution slow.

I think it's better a bit slower than rushing a feature which isn't ready yet, especially for big features/changes like these.
IMHO, these 2 features were added too fast, without enough prior discussion.
Having the flag would allow introducing early, but have discussion before it's "final unless we manage to convince matz after the fact which is very hard".

> * It may split the community: if some users love the feature, and if the others hate it, we might not make the feature by default nor remove it.

I think at some point we should decide: either make it stable or remove it.
But keeping it as experimental for a while doesn't seem problematic to me.
I expect gems wouldn't use it anyway because of the extra needed flag.
Therefore, I think people wanting the feature will keep asking to make it stable (non-experimental),
and we will have to decide, just like we have to decide now for every new feature.

> Additional note: I'm so sorry about your frustration, but the developer meetings are needed to help matz to triage ticket because matz is too busy to check and discuss all tickets.

Thanks. I understand the dev meetings are needed.

> I understand that the meetings look like attendees decide, but it is not the case, matz decides. [...]
> You may think that the dev-meeting attendees have a stronger right for the decision of Ruby's spec, it is not true.  Only matz decides everything.

Yes, matz decides every big feature/change.
However, I would think matz doesn't have time to read every comment on the issue tracker (very understandably).
So, what I'm concerned about is that comments on the bug tracker might be ignored or forgotten, because once the discussion starts at the dev meeting,
most people will present their own opinions and maybe some opinions on the ticket, but not every opinion on the ticket.
Therefore, I think attendees of the meeting have a much better chance to tell matz about their opinion and argue about it.
Being able to talk in person is a significant advantage: it's always easier to convince somebody when talking to them directly.
*This is the major problem with this process I think: I feel opinions from people outside dev-meeting attendees are less considered.*

> And, the experimental introduction made many people seriously consider the feature, express their opinions, write some articles, bla bla. I believe that these actions would not occur if it was not committed in trunk.

I think they would. People start commenting as soon as there is a commit implementing it in trunk.
I believe whether it's beyond a flag doesn't change that much.
If the flag is not given, we could easily give a useful message for the SyntaxError indicating how to enable it.

> And now, the actions are making matz reconsider the feature.  So this is an experiment as matz intended, and it looks like matz's experiment is succeeded.

I'm not sure about "matz's experiment is succeeded".
For me, an *experimental feature* means it's not stable and subject to change, and also not available by default until stable, or at the very least warned.

I think many people are angry or frustrated because they feel their opinions are ignored and only asked after the fact,
and given it seems very rare that an implemented feature changes, I have little hope the features can be removed or changed significantly.
I do hope both of these features change though, and that we can better listen to feedback from the community.
I think the flag would help acknowledging we are listening to the community, instead of the current
"if you don't complain often and loud enough (and in person), the feature will just stay as it is and become stable in 2.7".

> (BTW, the meeting attendees are not all Japanese; @duerst often attends.)

I meant people who can I attend the meeting in person, which I assume is mostly people living in Japan.
I attended 2 dev meetings, it was nice but it's also very infrequent.
The problem is larger in that the whole community should be able to better share feedback for matz's decision, before everything is decided (or feels like so, by being in trunk by default).

> I think it would be possible to print a warning when `@1` and/or `|>` are used.  A pattern matching prints such a warning in the present time.

I think that would a be a good step towards making these features actually "experimental" and acknowledging "they might change and are under discussion, no guarantee they will remain or won't change significantly".
However, I think the flag sends an even stronger message about this. Warnings can easily be ignored. Flags cannot, they have to be provided.
So with the flag, I expect we would break very little code if we change the feature, and should feel free to do so.
With the warning, I would think we would break a lot more code when we change it.



----------------------------------------
Feature #15966: Introducing experimental features behind a flag, disabled by default
https://bugs.ruby-lang.org/issues/15966#change-79021

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee: matz (Yukihiro Matsumoto)
* Target version: 2.7
----------------------------------------
I feel frustrated with some recent experimental features being added in `trunk`. These features, in my opinion:
* did not have enough discussion before being introduced.
* are going to be almost impossible to remove or even improve.
* got criticisms from hundreds of Rubyists in a couple days, illustrating the feature has major issues.

I think some (or maybe all?) experimental features being added to the language should be disabled by default, and enabled by a flag.
For instance, we could use the features system and have `--enable-experimental=...`.

For instance I'm thinking to 2 experimental features which have many problems reported by many people:
* #4475 / #15723 / #15897 Numbered parameters (`@1`, `@2`, ...)
  I think nobody realized matz would say "yes" after 1 month on https://bugs.ruby-lang.org/issues/4475#note-14, and so there was *zero* discussion about `@1`, `@2` before it was merged, and now we might get stuck with it.
  Many people shared their opinions after, and I think we should consider them carefully, which means not releasing `@1`, `@2` "accidentally" in 2.7.

* #15799 The pipeline operator (`|>`).
  Very little discussion before it was introduced also (the bug was only opened 2 weeks).
  The discussion on the bug tracker seems to have been mostly ignored, the feature was added without a response to concerns on the bug tracker.

Even though both these feature are documented as experimental, if they are released in 2.7, they will not be experimental in any way: there is no warning, nothing special to use it.
So there is no hope to change them if they get in Ruby 2.7.

With the new flag, these experimental features would then be disabled by default, until the core team decides they are stable enough (e.g., there are no major issues with it anymore),
and could still be tried as soon as implemented using e.g., `--enable-experimental=nbargs,pipeline`.

This would allow experimenting with the feature, and discuss about it,
and yet not having the feature set in stone and still be able to change it or remove it.

When such a feature is introduced in Ruby, there is very little chance for it to change or be removed.
In fact, it requires many people in the community to  invest significant time to express the problems of the feature and yet sometimes it's not enough.
If by December, no agreement was reached or no decision by matz was taken, the feature will stay (basically forever) whether it's good or has many issues.
This is not a good process. It requires massive efforts from many people in the community and might result in nothing changed.

By massive efforts from many people, I mean for example:
* Going to Japan in person to discuss with Japanese MRI committers and get a better idea of motivations, thoughts, concerns.
  MRI committers outside Japan and Rubyists in general cannot attend or express their opinion at developer meetings where many decisions are taken, and so have to rely on Japanese MRI committers to relay their opinions.

* Summarizing threads of 100+ comments, and preparing slides or a summary for discussion at a developer meeting (it takes hours).
* Trying to get the motivation for the feature written down on the issue tracker, since often it is not well explained on the issue tracker.
* Writing blog posts sharing thoughts and how to improve the feature/why it should be removed.
* Posting comments on the MRI bug tracker (inconvenient for many people, requires extra account, we see more responses on Twitter or GitHub).
* Writing [blog posts](http://katafrakt.me/2019/06/15/im-worried-about-ruby-future/) or issues like this one to express the general problems of the process for introducing experimental features.

Also, people sometimes respond rather aggressively (me too, I am sorry about that),
because I think people feel it's already too late to share opinions and have an impact on the decision,
the feature might have many problems and yet it's extremely unlikely to change.
I can say it's not a comfortable situation at least, I feel ignored, watching things go wrong and not being able to do much about it.

So I propose `--enable-experimental=...` to make the introduction of experimental features more smooth and allow discussion before the feature is basically written in stone.
What do you think?



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>