develooper Front page | perl.perl5.porters | Postings from March 2021

Re: RFC / POC - more than 32 features

Thread Previous
From:
Sam Kington
Date:
March 24, 2021 20:51
Subject:
Re: RFC / POC - more than 32 features
Message ID:
2BDF8C3D-359E-40A4-B3A9-FFA51BF3B884@illuminated.co.uk
On 24 Mar 2021, at 19:46, Nicholas Clark <nick@ccl4.org> wrote:
> The other problem (and I'd not considered it until LeoNerd mentioned it) is
> that number of combinations of features grows exponentially with the number
> of feature options. Meaning that it becomes hard to test all combinations
> (or even reason about them), making it likely that there would be bugs and
> inconsistencies lurking that burn more time than seeming performance or
> flexibility gains.


If I understand the concept of feature flags correctly, the idea is that you take “probably good” code and release it into the wild, where you can see how it behaves under a wider variety of conditions than you had (a) thought of and therefore (b) tested. You enable the feature flag in some or all of your environments, and if something goes catastrophically wrong you can disable the feature flag and revert to previous behaviour.

IMO, to some degree this is similar to technical debt, where you write code with an implicit

    # FIXME: sort this out in a few releases’ time

comment. And that’s fine in small doses, in the same way that a small amount of debt lets you e.g. buy a car or a house: you’d never have been able to do that by saving money ahead of time! But in the same way that, when you take out a car loan or a mortgage, you need to be confident that you’ll eventually repay it, when you cut corners to ship a feature early you need to make sure your road map now includes “fix that code we shipped in a half-arsed fashion a few releases ago”.

So I think whenever we add a new feature to Perl, the end point is implicitly “this is a good feature; make it non-optional in a future version” (e.g. say and state), or “this was a bad idea; get rid of it” (e.g. lexical $_, smartmatch). Code hanging around behind a feature flag for years should be whatever the language design equivalent of code smell is: it should have been resolved one way or another.

So this is an argument for keeping the limit of 32 features: focusing implementors’ minds on “how many of these things *need* to be features?”, similarly to how sometimes politicians adopt a rule like “if you add a new regulation, you have to go and find an old regulation that isn’t needed any more”.

A good counter-argument is: suppose that we finally ship trim(), and maybe tromp() or other variants. One of the reasons for adding trim, above “all other languages have trim and that makes Perl look bad”, was “this is a comparatively trivial feature to add, and it would be good to have an example of adding a feature to Perl that other people could copy”. It’s possible that the flood-gates could open, and we could have a temporary influx of loads of new features, and we might need to up the limit to cope with this (ideally temporary) increase in features.

Sam
-- 
Website: http://www.illuminated.co.uk/


Thread Previous


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