Front page | perl.perl5.porters |
Postings from January 2018
Re: We need a language design process.
Thread Previous
|
Thread Next
From:
Sawyer X
Date:
January 1, 2018 12:16
Subject:
Re: We need a language design process.
Message ID:
8679004f-21d6-1969-37cd-6693220dedde@gmail.com
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
misfeatures)
* 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.
Thread Previous
|
Thread Next