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

Re: on changing perl's behavior

Thread Previous | Thread Next
B. Estrade
March 29, 2021 14:48
Re: on changing perl's behavior
Message ID:

On 3/28/21 2:32 AM, Chris Prather wrote:
> On Sat, Mar 27, 2021 at 8:51 PM Philip R Brenan < 
> <>> wrote:
>     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.

I am one of those. I use Perl because it DWIM, gets out of the way, and 
in most cases can accept `fork` over lightweight threading (as in 
pthreads) for utilizing hardware on bare metal - oh and it is 
everywhere, or can be at a moments notice. For small tools/scripts, if I 
can get away with it, I write Bourne compatible shell scripts - that's 
my "other language". Perl is my "large" application language. Nothing 
else comes close to just being there and working. Nothing.

In my eyes, Perl is in the "what can we take away" phase. It is my very 
strong opinion that additional language features are not going to make 
Perl "popular". Not a new OOP in core, not a "tromp/trim" function. Not 
a "say" method. None of these provide any power nor are they going to 
make it popular. Stop chasing other languages and market share. Chase 
application domains, or at least let's create an additional vector to 
chase things like tooling (as I mentioned before). I say this having 
been an astute observer of Perl for some 20 years, and while not a 
"polyglot" because nothing comes close to Perl for me; I am a student of 
the history of PLs and follow them on a higher level. Perl is unique in 
all aspects. Do not lose this.

Java, PHP, and JS were a threat to Perl because Perl was filling that 
gaps because it could. Perl is more "XP" than Java up to the point you 
wish to have a GUI app. Think about that. JavaScript is a powerful tool 
because of fiat browser support. No wonder nodejs is popular, some 
browser UI jockies woke up one morning and decided they wanted to work 
on more interesting things. It makes sense no-browser JS would be 
popular; Perl has far better modules, frameworks, package management, 
and environmental switching tools (perlbrew vs nvm). So what, server 
side if Perl's turf. Tomcat? Joke compared to mod_perl even (and yet 
there's an attempt to bury it alive.)

Focus on making Perl stronger for distributing applications or embedded 
uses (I don't hear anyone saying, look how great Lua is for blah blah 
blah; focus on closing the "last mile" for XP. All these other languages 
have endless funding from corporations and monopolistic distribution. 
The browser will be dead before anything is released anyway, and by that 
time we will have recreated JavaScript? Fight the next war, not the last 

At the end of the day: getting Perl in the most hands possible using it 
in as many ways as possible is going to necessarily drive language 
development - and it will.

Finding significant, compatible changes to Perl that will bring people 
in *and* make current users happy is not possible. Perl is what it is, 
for better or for worse. Is awk worrying about chasing Rust? Does TCL 
care about nodejs? Is C losing sleep over any of this?

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

Listen, I am not trying to dissuade language design decisions or 
discussions, but my Sweet Lord, please wake up anyone who thinks stuff 
like this ^^ is going to steal 25% of the Rust mind share. The minutia 
of this is invisible to even seasoned Perl programmers.

In additional to fostering (at a high level) tooling around distributing 
Perl applications, has anyone taken a serious look at what's going on 
with perl and linux/BSD distros?

* OpenBSD is the only one that keeps it base (that should tell you 
something - good)
* FreeBSD took it out of base YEARS ago
* FreeBSD is the only freenix that supports more than one version of 
perl (4 at least count) and has a means to have them all installed at 
once; even if the /usr/local/bin/perl is symliked to only one at a time 
(they do the same for python2,3 and ruby, etc)
* pkgsrc (NetBSD) supports a LARGE number of systems, yet provides only 
one version of Perl (fairly up to day)
* Ubuntu - omg, the way it breaks up perl-doc, libperl-dev, etc, etc - 
not good for Perl at all
* RH/Centos - idk even know any more, I think it breaks up the perl 
stuff like Ubuntu but I have not checked

This is definitely going into the Perl advocacy realm, who among us is 
"officially" in charge of nagging Canonical about the way it breaks up 
Perl? Who was on the horn with FBSF when they ripped perl out of their 
base?  Is anyone working with Strawberry Perl or wx-widgets? You want 
Perl apps on Windows? There's your core team, and one of them might even 
be economically viable.

You can see where this is going. My main point: please, for the love of 
God and all that is Holy - stop banking the future of Perl on making it 
more familiar to Language X developers, especially at the rejection of 
your most loyal and fruitful users. You will never capture the former; 
you will forever lost or completely demoralize the latter. Cater to the 
loyal, avoid language whores and immature developers who still jump on 
the JavaScriptFrameworkOfTheWeek^tm or whatever language 
MozillaGoogleUSAgov is funding at the moment.

So where do these discussions and leadership belong? Is P5P the defacto 
outlet for the PSC? E.g., I don't expect what I said above to really get 
anywhere because it's not technical in nature; it's long term strategic.

So who is supposed to be thinking about things like:

* long term vision (high level)
* thanking FreeBSD for supporting several versions of perl (important 
when it comes to "perl7.0.0" as they will add it), etc
* identifying players in "Perl on Windows", "XP GUI", "application 
distribution" and working to support them?

And lastly, while I don't think it is P5P's responsibility to "save" 
things like mod_perl; who is on the phone right now ASF to figure out if 
this really is an issue and what can be done to mitigate the damage done 
by merely questioning if it should be "retired"? As if.

The burden of this list or the main players seems great enough on the 
"technical front" - I hope moving ahead the PSC (or whomever) gets 
ruthlessly strategic about the future of Perl. "Language design" is sure 
one aspect, but so are the things I mentioned above and many more. You 
guys want to fight for the future of Perl? Treat this as a real war and 
don't focus strictly on gold plating your bullets.


> 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 programming.
> 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 language.
> 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.
> -Chris

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