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:30
Subject:
Re: We need a language design process.
Message ID:
68b781d8-6c70-dc25-72aa-e491e2f15de8@gmail.com
Reviewing the smart match thread again, I think my response on smart
match should fit in this thread, but separate from my previous email on
PEP/JCP and experimental.
A probably unpopular opinion (but hey, that's what I'm here for), but I
think this was blown out of proportion. (Insert a person quoting only
this sentence, entirely out of context.)
Smart match has been problematic for years. We have been vocal about it.
It has moved to experimental years ago. It was then discussed at lengths
(raised several times by rjbs) and reviewed on an open mailing list
again. Then a branch by Zefram that encompassed what the discussions
included was provided for comment. Also, open to everyone. In the end,
without much comments (other than "whereis" and "whereso" which were
declared still very much open for debate), it was merged. The merge was
not a "done" tick off of the feature - "this is perfect." It was to
allow us to review possible breakage. The breakage started piling up. We
reverted it. The discussions, work, merge, and revert were all done
before any level of freeze.
There are several things we could have done differently and better (and
if you like to quote, feel free to quote me acknowledging stuff we can
improve on): We could have surfaced it outside p5p. I intend us to do
this in the future. (I think some of us hit an exhaustion phase, which
is also why the threads received relatively less traffic than you would
expect of something so intricate.) We could have asked Andreas to smoke
the particular branch to find said breakages. We could have attempted to
merge this even earlier (although we did not hit freeze yet and our
coding and testing resources are, unfortunately, limited). We could have
the communicated this change to request more feedback.
Otherwise, I think we did a few things well. We discussed this numerous
times. A branch was offered for review. It was merged. Feedback was
received, and change was reverted. Again, all before any freeze. This
did not reach production, only a single dev release, and that's it. So
yes, much could be learned and improved here, but it is not the disaster
we are making it out to be. I would like to keep this in perspective.
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