develooper Front page | perl.perl5.porters | Postings from December 2017

We need a language design process.

Thread Next
From:
Leon Timmermans
Date:
December 29, 2017 03:48
Subject:
We need a language design process.
Message ID:
CAHhgV8jX+pPgFLZ56wssLh7bNAZ092kTe5DWfnCEbcrbCi0cEQ@mail.gmail.com
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 Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About