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

Re: on changing perl's behavior

Thread Previous | Thread Next
Chris Prather
March 28, 2021 07:32
Re: on changing perl's behavior
Message ID:
On Sat, Mar 27, 2021 at 8:51 PM Philip R Brenan <>

> We talk about new users and having a better language to better serve
> them.  But there are no new users!  I used to mentor people in Python and
> Perl.  But there is no longer any demand for Perl mentoring.  Every time a
> change is made to better serve the new user it conveniences no-one but
> inconveniences many people who have displayed long term loyalty to Perl and
> drives a few more of them away.  Just as: "adding new programmers to a late
> project makes it later" adding incremental new features to a dying language
> simply hastens the date of its demise.

I almost entirely agree with the premise here. For as long as I can
remember as a Perl programmer, we've chased the dragon of developer market
share. In the beginning of my career (late 90s, early 2000s) it was coffee
cup throwing and hand wringing about how Java and PHP were taking our
natural niche on the web; later it was Python, then Ruby, then Javascript,
and now Python (again): we need a killer app, we need a killer feature, we
need a unique selling proposition. After 21 years, I'm pretty sure that
there isn't a silver bullet (to borrow from Philip's allusion).

Yet, I've come to the conclusion: Not evolving with the needs of the people
who are currently writing new Perl code on a regular basis — the people
either maintaining existing applications or building new ones — gives them
little incentive to continue writing new code in Perl on a regular basis.

> The parable of the dereferencing operators illustrates this all too well:
> what was wanted was *a push 1 *but what we got was: *push $a->@*, 1 *.
> Please go and explain how that works to a new programmer and see if they
> prefer it to *a.append(1)*

This wasn't the first conversation about postfix dereference, but
is pretty whole cloth about the syntax. I assume this isn't an attempt to
re-litigate the past but to make a point about features being added to the
language. While the comment here is focused on just this one feature, I
think the history of references in Perl  is a better illustration.

Perl 4 only had symbolic references. To create a multidimensional array
you'd use an associative array where keys were joined by $;, which defaults
to a nonprinting character (\034, the ASCII file separator?). So `$foo{qw(a
b c)}++` would increment the value of `$foo{join($;, qw(a b c)}`.

I assume that adding "hard" references in Perl5 caused a reasonable amount
of conversation, the feature at the least caused compatibility issues
similar to $* and following was noted in `perltrap.pod`: *The construct
"this is $$x" used to interpolate the pid at that point, but now tries to
dereference $x. $$ by itself still works fine, however.*

Porters made changes to Perl's referencing again in 5.001 by legalizing `${
foo }` as equivalent to `$foo` even outside of  string interpolation. I
assume this was to ease the writing of the still recent and likely popular
Perl 4 style of  symbolic references, in "perl-as-a-better-shell" style

The next major change that I'm aware of is David Golden's patch to "auto
dereference" in the case of push/pop/keys etc. The rational David provided
was (quoting from
): *In various venues and forums, I've heard people express the desire for
perl do the "obvious thing" when providing a reference directly to such
functions that act on containers.*

The feature was provided because David was attempting to listen to users
and add features to respond to them. Yes, the history of auto-deref is
long, and tumultuous; the feature, eventually explicitly labeled
"experimental", was ultimately removed in 5.24. It wasn't removed entirely
because of it's failure to deal with the complexities of Perl's ...
flexible ... syntax, but also because a new feature had been added to the

Rik was pretty explicit, in the link above, about his reasoning for postfix
dereference syntax: *Perl 5's references are fine, but sometimes
dereferencing them is not. We end up switching between postfix and
circumfix syntax to dereference structures. [...] Blech.*

Taking the example of `a push 1`, the right hand side would still need
circumfix dereferencing `a push @{ $one->{thing} }`: exactly one of the
problems Rik identifies as lacking in auto-deref. Postfix dereferencing
wasn't designed to attract new developers to Perl; it was designed to solve
a problem that had been identified 3 years earlier for existing Perl
developers, the need to deal with at least two different syntaxes for
dereferencing complex data structures in certain contexts, that hadn't been
adequately solved yet.

Rik is one of the most prolific Perl developers I know; Rik is also one of
the most conscientious authors of Perl I know. He thinks strongly about
readability and coherence in his code. The postfix dereference syntax is
admittedly much more Perl-ish in the ways Perl is notoriously impervious to
MD5 decryption with. But is in my opinion a more elegant solution than
auto-deref because it: exposes rather than obscures that a behavior is
happening, is discoverable by mirroring existing  constructs, and operates
in a more consistent and universal way.

We are too far behind the curve for incremental changes to have any
> significant effect other than annoying more people so that they leave too.
> Only the most radical of changes can help us now.

As far as chasing the dragon of market share, then I entirely agree that
incremental change has no benefit. I don't think Radical change would
benefit us with that either. *I don't think people who don't currently use
Perl have any commercially compelling reason to use Perl.* I disagree that
incremental change will only serve to annoy people into leaving too, I
think people are going to leave no matter what. Our only option is to
understand the people who are staying with Perl and make sure we serve
their needs.

*"Now, here, you see, it takes all the running you can do, to keep in the
same place. If you want to get somewhere else, you must run at least twice
as fast as that!" -- *The Red Queen, Alice Through the Looking Glass

I think there is a solid point about the nature of `/usr/bin/perl` and the
need for consistency there. Perl cannot break applications like `apt-get`
which have worked for decades, it needs to at least maintain the status
quo. Maintaining the status quo isn't enough either, we need to improve the
lives of the people who are currently writing Perl code so that there's a
compelling reason to keep Perl around. Otherwise when the current
developers hand things off, the new developers won't be as ready to keep
Perl around.

Rik writes:

> [T]he first big question is: Is there a general agreement that there are
> kinds of changes we've made (or will make) to the language that we can ease
> into making the default, through some multi-step process?

I think the only possible answer to this for perl5-porters is yes, because
if the language can't stay relevant to the evolving needs of Perl
developers, then eventually the choice of defaults won't matter.


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