Front page | perl.perl5.porters |
Postings from December 2017
On Fri, Dec 29 2017, Leon Timmermans jotted:
> 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.
Perhaps we should reflect on the process we've had already? Timeline:
1) 1987-2000ish: The process is well defined, unambiguous and clear. We
call it Larry.
2) 2000-2001: The RFC process for "perl5 is kinda warty" starts:
https://perl6.org/archive/rfc/ 5.8.0 comes out around this time, not
much happening in feature development. Larry departs.
3) 2001-2004: The process in #2 yields a language that's incompatible
with Perl 5, first via the Apocalypse documents
(https://perl6.org/archive/doc/apocalypse.html) then via the
Synopsis (https://design.perl6.org/)
4) 2005-time(): We've been sort of sailing on autopilot as you've
described.
It seems to me that the most straightforward thing to do would be to
simply restart the RFC process, with the goal of eventually producing
something like the Apocalypse/Synopsis documents, except this time
around we'll need to limit ourselves to being compatible with Perl 5.
Thread Previous