Front page | perl.perl5.porters |
Postings from December 2017
Re: Revisiting smart match
From: Matthew Persico
December 26, 2017 17:42
Re: Revisiting smart match
Message ID: CAL20dLBfrmLcN+kR2Him+0o031tgDyiKWZ+YDeoW11zQWNPWtA@mail.gmail.com
May I contribute my opinions from outside the echo chamber?
I'm 53. I've been using Perl since '98. I went to the Bronx HS of Science,
the Cooper Union, and I've worked in finance for the last three decades. In
short, I am not rocket scientist, but I'm not a script-kiddie either. On an
IQ bell curve, I'd like to think that I fall *somewhere* on the right hand
side, even if it is at the top of the arc.
I have never heard or read the words whereis and whereso in my entire life.
That as my initial reaction. I've seen *wherefore*, but only in the context
of those stupid Foo Day proclamations from your local government.
And the more I think about it, over the last hour of preparing a response
to this thread, I still can't recall their use.
Try looking them up in Merriam-Webster on line. 'whereso' comes up as
archaic. 'whereis' comes up as the idiom 'put your money where your mouth
If Perl is about making easy things easy and hard things, possible, then
these keywords fail. Spectacularly. For a US citizen. Imagine someone whose
first language is not English.
Can we chose some other keywords? I don't need to give the Pythonistas
around me some REAL ammunition against me in my daily defense of the Perl
language and its philosophy and we are not supposed to be the
'ooooh-let's-see-how-comp-sci-clever-we-can-be' folks. I can easily see all
the good work in trying to straighten out the smartmatch mess being drowned
out in ridicule over the choice of keywords.
On Tue, Dec 26, 2017 at 11:05 AM, Tom Molesworth via perl5-porters <
> On 25 December 2017 at 23:52, David Golden <email@example.com> wrote:
> > 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.
> Generally-accepted in some circles, perhaps, but I'd suggest it's by
> no means a universal standard - for beginners especially, my
> experience is that the system packages are seen as the safe option. My
> sample size is small, but I find that most people use system Perl, and
> the same applies to Python, node.js and bash.
> > 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.
> Proliferation of Perls aside... I don't think that last one is a fair
> assessment of the impact:
> - if it's an old perl, this is *not* an experimental feature (as
> mentioned a few times elsewhere).
> - we were recommending given/when and smartmatch in the FAQ until very
> - in my experience, "how do I check for a value in array" and "how do
> I spell switch/case in Perl" seem to be common questions for Perl
> newcomers which end(ed) up with a smartmatch-related answer.
> "Very recently" includes Perl 5.26.1, which *explicitly recommends*
> given/when in the current text:
> Note that it does mention Switch.pm as being discouraged... yet makes
> no mention of impending changes in newer Perl versions.
> I think this can be taken as an authoritative learning source for Perl
> programmers - it seems premature to change the feature when the
> officially-sanctioned examples will break?
> The standard recommendation for new features - e.g. async/await, which
> I am very much looking forward to - seems to be "do it in CPAN, and if
> it's popular or important enough, we can consider moving it to core".
> How feasible would that approach be for either smartmatch, or some
> form of switch/case? (I'm not convinced that the two concepts need to
> be so tightly integrated as they have been so far - not that I'm a
> target user, I don't see much value in either of them in the first
> place for the code I tend to write).
> Just to be clear, I don't agree with the stronger negative opinions
> either: from my perspective the new smartmatch approach seems like a
> significant improvement, and if we'd started with this I think it'd be
> a great addition to the language.
Matthew O. Persico