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

Re: We need a language design process.

Thread Previous | Thread Next
John Alvord
December 29, 2017 22:32
Re: We need a language design process.
Message ID:
Seems like an experimental feature that has been allowed to remain for many
years becomes a defacto feature... sort of like a British public footpath.
So remove the experimental designation and reduce confusion/friction.

If you want a smart switch feature, you almost have to use orthogonal
keywords. If the value is good enough the new feature will succeed over

John Alvord

On Fri, Dec 29, 2017 at 9:58 AM Zefram <> wrote:

> Leon Timmermans wrote:
> >I'm not aware of any other major open source language that quite dumps new
> >features on their users like we do.
> We've got feature flags and experimental status to manage this.  We mostly
> stopped just dumping new features onto users years ago.
> [smartmatch]
> >                         Late in that discussion changes were introduces
> >with compatibility consequences that weren't immediately recognized as
> >such;
> What specifically are you referring to here?  I don't see anything
> matching that description.  The only compatibility consequence that
> I see that was not immediately spotted was the issue of the "switch"
> feature being on by default for some existing version bundles, which
> interacts with the changes in keywords, but these changes didn't really
> start "late in that discussion".  I also doubt that thinking about it in
> advance would have spotted that issue.  It certainly wouldn't have made
> a difference to the resolution: if the changes hadn't been reverted,
> I was going to tweak the feature flag setup, in exactly the same manner
> that I would have if I'd been aware of the issue in advance.
> >Only after that one can actually design the feature.
> ...
> >After that, "Someone with time on their hands" can actually implement it
> I reject the notion that a waterfall process is a good approach in general
> or that enforcing such a process would solve problems.  Issues often arise
> during development that were not apparent before touching any code, and
> spending longer before touching any code doesn't prevent that happening.
> If you enforce the sequential requirements-design-implementation process
> then that just means that you can't address these problems when they
> inevitably arise.
> -zefram

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