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

Re: We need a language design process.

Thread Previous | Thread Next
Leon Timmermans
December 30, 2017 17:52
Re: We need a language design process.
Message ID:
On Fri, Dec 29, 2017 at 6:57 PM, 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.

I think you missed my point. That is not really a replacement for
actual communication to our end-user base.

A conversation I had the other day with Salve did make me realize I
forgot an important stage in my post: user testing. Let some users
from outside our echo chamber play with it and then ask them what they
thought of it and look at what they did with it. Use this as input in
the iteration process.

Essentially, we're using experimental status for that now. This is
like a REPL to the community with a roundabout time of a full
year/release cycle (if not longer). We should strive for something
faster with more effective ways of communication.

As far as I'm concerned pulling an experimental feature entirely
should be an ejection seat, not a normal feature of the airplane.

> [smartmatch]
>>                         Late in that discussion changes were introduces
>>with compatibility consequences that weren't immediately recognized as
> 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.

Splitting when into whereso and whereis meant that it is no longer
possible to write code using the switch feature that works on both
5.26 and 5.28. That gives a completely different kind of transition
than was the case before.

>>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.

I don't mean to waterfall at all, I said "reality is probably
iterative". I do mean that we need to explicitly say "this is what
we're trying to do, and this is what we shouldn't". We tend to focus
too much on the "how" and too little on the "what".


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