Front page | perl.perl5.porters |
Postings from January 2018
Re: We need a language design process.
From: Dave Rolsky
January 1, 2018 22:25
Re: We need a language design process.
Message ID: CAHKw1M+RuV_j2OkmgZeaLDTWd9Zu77+146To1DKX8hZdBCJ0AA@mail.gmail.com
Re: a RFB procedure ...
I like this idea a lot. This list has so many different topics that trying
to follow what's happening on an ongoing basis is like drinking from the
firehose. I think I would be inclined to review RFBs (at least for some
topics) much more than I want to follow P5P very closely.
On Mon, Jan 1, 2018 at 6:16 AM, Sawyer X <email@example.com> wrote:
> I was happy to see this thread, but I think it petered off so I would
> like to focus on two particular topics: PEP/JCP and experimental.
> First of all, on PEP/JCP:
> Years ago. Stevan Little and I were envisioning a process similar to PEP
> which we called RFB for "Request For Bikeshed." The idea was to collect
> the following information on any feature suggestion:
> * Who is proposing it
> * What does it solve
> * What would it look like
> * Prior art (in Perl and other languages)
> * Relevant research and all previous discussions
> * Reference branch (if available)
> * How would this interact (best we can tell) with different features (or
> * What could it break
> * What follow-ups would this include or require
> The idea was to include all the relevant information for discussing this
> idea and any previous discussions that revolved around it. If a
> proposition were to supersede one, it would cover that as well. This
> would allow opposing RFBs to be presented and discussed. This would
> allow providing an RFB to improve upon a previous one. We would then be
> able to store all of them in a relevant repo (or a branch like we do
> with maint-votes) and update them as necessary.
> Unfortunately, we did not complete it to the point of presenting it to
> p5p. Perhaps it is time to review. I am very much in favor of a proper
> procedure that aims to provide as much information and reduce both the
> bike-shedding and the splintering of discussions.
> Secondly, on experimental:
> I greatly sympathize with AEvar's point on what experimental means and
> should mean. I view experimental as "we can change or remove it at
> will." We put it out there with a strong Alpha phase warning. We are
> warning it might change or be removed and you are taking it upon
> yourself when using it. However, I think Dan has expressed a position I
> find similar to mine, which is reserving our will in the aforementioned
> "at will" to "we do not have to." The fact that we can break does not
> mean we should. Breakage should be avoided whenever possible and
> eliminated when unnecessary. This situation was unique.
> Our concern at the end is not the language. It is the people who use it.
> If it were the language, we would remove all warts we don't like and
> implement all the niceties. We do not do this because it is the usage of
> the language that matters to us more than the language itself. This is
> also why we have the experimental flag, so we could see whether it works
> not only for the rest of the language semantics and syntax but also for
> its users. This is why we deprecate.
> It is then advisable to always reconsider when changing an
> experimentally flagged feature causes such disruption for the users.
> Laws were not meant to be blindly followed.
> There are two things we can learn from this: 1. The feature attempted to
> address a real need. People needed smart match to the point of using it,
> even in what was realized to be a broken feature, to the point of its
> change causing such a problem. We have underestimated the need that
> drove such code to be written. (This, of course, can be said about a lot
> of other situations - and should be said of them.) 2. The initial
> attempt at smart match was evidently taking too big a bite to chew. At
> least this we already know (which led to experimentalizing it and the
> continuing discussions for changing it).
> I would like to maintain the value of "experimental" but we should
> reserve the right to be judicious of when to exercise it and when to say
> "Yes, we could make this change but in this case, we shouldn't." (This
> time in a single sentence, so it's a tad harder to quote out of
> context.) And I would like to reserve this right for almost everything
> we can, to allow us more flexibility for the benefit of the users of the
> language, rather than the language.
> On 12/29/2017 05:47 AM, Leon Timmermans wrote:
> > The language development that we've done in the past more than a
> > decade has been largely ad-hoc. It seems to me that a lot of it rather
> > boiled down to "Someone with a commit bit had time on their hands, and
> > no one on the list who was online that week protested too much". A lot
> > of those features weren't all that successful. The most successful
> > features were fairly simple (defined-or, s///r). I don't think that's
> > a coincidence.
> > Fundamentally there are two main problems here.
> > I'm not aware of any other major open source language that quite dumps
> > new features on their users like we do. As long as I've been on this
> > list I've never seen a true outreach to our users that allows them to
> > give feedback in this process, they kind of just have to wait until
> > release time to see what they'll get. I don't think it's on purpose,
> > but it's rather puzzling to me how we painted ourselves that deeply
> > into an echo chamber. We don't need a full PEP or JCP to do better here.
> > The other major thing that I'm missing are clearly design
> > requirements. This isn't particular to language design, pretty much
> > any ambitious design needs them. For example, in the recent smartmatch
> > situation we didn't accurately define what things we actively wanted
> > to break, and what things we didn't want to break. Late in that
> > discussion changes were introduces with compatibility consequences
> > that weren't immediately recognized as such; having good requirements
> > provides safeguards against that sort of situation. This may or may
> > not involve a first round of asking users about their needs. As a
> > bonus, I suspect that requirements are less susceptible to
> > bikeshedding discussions as they're more abstract (famous last words;
> > the universe will probably just invent better bikeshedders).
> > Only after that one can actually design the feature. And once again,
> > they may reduce bikeshedding as suggestions that don't satisfy the
> > requirements can usually be put aside. This should lead to something
> > that we can present to our users which may lead to further
> > modifications; reality is probably iterative.
> > After that, "Someone with time on their hands" can actually implement
> > it without the risks that were previously associated with it. This
> > phase really ought to be boring for everyone except that person, and
> > shouldn't need to follow other rules than any other change.
> > I strongly believe that such a deliberate process will greatly improve
> > the quality of our language design as well as make these discussions
> > on p5p more pleasant.
> > Leon
> > P.S. Did I mention less bikeshedding enough? Less bikeshedding.