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

Re: Revisiting smart match

Thread Previous | Thread Next
David Golden
December 25, 2017 15:53
Re: Revisiting smart match
Message ID:
My 2 cents:

0.01: I really don't like the proposed keywords and think the bikeshed
needs more paint.

0.02: I don't object to removing a feature marked experimental after 5
years, even if it breaks stuff.

Arguments that "people on old perls will suffer when they upgrade" don't
carry a lot of weight with me, as that population has already demonstrated
they don't upgrade often or they'd have seen the warning.  As a volunteer
driven-and-funded community project, I don't think the Perl core should
hold itself hostage to distros that ship ancient perls.  (Unlike toolchain
and high-river CPAN modules, which I think *do* benefit the community with
a longer support window.)

I think it's generally accepted wisdom now (in several dynamic languages
communities, not just Perl) that people should run applications using their
own interpreter, not the system one.  So who suffers if a newer Perl breaks
stuff?  People who don't follow the wisdom?  They can learn why it's a
widely used pattern.  Sysadmins who have scripts they want to "just work"
on newer OSes?  They're sysadmins... I expect them to be able to install
their own Perl and use it if they need to.  Newbies?  They aren't using
experimental features anyway.  DarkPAN?  Who knows, they don't tell us, and
they don't pay for support... but they do pay their own sysadmins who,
again, can work around these issues and probably aren't going to jump 5+
years of OSes and Perls without testing anyway.

Five years of warnings not to rely on something is plenty.

I'd also be fine *removing* given/when/smartmatch entirely in the next
release even if there isn't a replacement.  There's no need to rush the
replacement if the design is controversial.


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