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

Re: We need a language design process.

Thread Previous | Thread Next
Rocco Caputo
December 31, 2017 20:18
Re: We need a language design process.
Message ID:
I've grafted the thread back together because I think the conversation is getting lost in pruning.

On Dec 31, 2017, at 01:25, Father Chrysostomos <> wrote:
> Rocco Caputo wrote:
>> On Dec 30, 2017, at 20:48, Father Chrysostomos <sprout> wrote:
>>> On Dec 30, 2017, at 15:36, Ævar Arnfjörð Bjarmason <> wrote:
>>>> On Sat, Dec 30 2017, Father Chrysostomos jotted:
>>>>> Avar wrote:
>>>>>> I think in the future it makes sense to hold
>>>>>> ourselves to reviewing these features once they've been unchanged in say
>>>>>> 2 or 3 releases, and for the policy to say that experimental features
>>>>>> unchanged in 3 development cycles must either be promoted to
>>>>>> non-experimental, removed entirely, or have their semantics changed in
>>>>>> major ways.
>>>>> I don't think it makes sense.  If a feature is significantly flawed
>>>>> (and experimental) due to lack of tuits (e.g., refaliasing), do
>>>>> we have to make meaningless design changes to it to avoid having
>>>>> it yanked?
>>>> Not meaningless design changes, but to have some sort of schedule
>>>> (preferably enforced by code, i.e. as soon as we begun 5.25 we start to
>>>> warn/die) giving these experimental features an explicit expiry date.
>>> This would be a good way to discourage people from implementing
>>> new features.
>> I'm okay with that as an alternative to half-baked things remaining
>> incomplete indefinitely.
> Yes, but what benefit would such a policy provide?  Give a practical
> example.  Policies to prevent unreasonable situations that do not hap-
> pen anyway are needless cruft.

The choice as presented above is to either let experiments run indefinitely or to be clearer and more definite about the state of their development.

I voted for the latter even if your claim that it would stifle innovation is correct.  I think it's the better option.

I appreciate your desire that everyone agree on a single, logical, and consistent resolution, but I feel it's unreasonable to require me to debate my vote.

>>>> Consider the situation we're now in. We're about to release 5.28 and
>>>> we've chickened out on changing a supposedly "experimental" feature
>>>> mainly because it breaks stuff on CPAN.
>>> Good.  That means we are involving the *whole community* in the lan-
>>> guage design process.  Yay for popular-vote-by-CPAN!
>> If the Porters want Perl to be defined by popular usage, it behooves them not to release experiments they aren't prepared to support.
> My point was that responding to user complaints or CPAN breakage by
> reverting unpopular changes, especially if it does not seem that an
> alternative will be ready in time for the next stable release, is just
> common courtesy.  You do not need a policy to be courteous.  You could
> call that 'support'.

That seems tangential to what I responded to.

My concern is your voiced support for "popular-vote-by-CPAN".  It also can lead to bad changes being ratified because they're popular.  You probably didn't intend to say that.

On the other hand, if it's generally desirable for popularity to be a deciding factor in some but not all cases, the exceptions should probably be noted.

Rocco Caputo <>
Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About