Front page | perl.perl5.porters |
Postings from March 2021
Two Kinds of Perl
From: Paul "LeoNerd" Evans
March 30, 2021 23:19
Two Kinds of Perl
Message ID: email@example.com
Over the past few days we've seen several comments from various people
- both here on the perl5-porters mailing list, and other places, that
all point towards the same central theme. This theme is the idea of
there being "Two Perls": a shell-script-like "babyperl", and a full
applications programming language perl.
I can't hope to hit on all the instances here - I'm quite sure I will
have missed several cases of this. Apologies to anyone I have missed -
I'm sure I'll see some "me too"s in replies ;) But a few cases that
come to mind are:
* Leon Timmermans, who tweeted:
"A lot of people have only ever encountered the quick-and dirty
kind of perl can't imagine that the you can write large
applications using the same tool. They fail to see that these
things can be the same language for computers but different
languages for humans."
* Andrew Fresh, who emailed:
"There are likely thousands of scripts written by the previous
sysadmin who knew just enough perl to make it work that are in a
similar condition, and the people left to fix it would just know
that "perl broke their stuff", in my opinion, for no good reason."
* Alexander Hartmaier, who emailed:
"What do you think about a dumbed down Perl 5 variant for system scripts,
oneliners, etc. that is used when no version is specified in a
package and which will be supported longer (I don't dare to write
* It has been encoded in the "current" (i.e. latest) set of ideas
from PSC, who specify that even if the "line-zero" defaults
change, they will be exempted from `perl -e`. That suggests we have
two different places - shell one-liners in -e, and real code in
By saying "line-zero", I want to adopt James Keenan's terminology
of the "line-zero" plan, as meaning that changed-defaults will
apply even from "line-zero", i.e. from the start of the file, even
before a `use VERSION` declaration has been seen.
I want to add my own example here. A while ago I wrote: "Will we
convince Google that when they provide the language API bindings for
their GCP they should make a Perl one? No."
Privately on IRC someone (whom I won't embarrass by naming them here
but they can speak up if they want), asked me seriously why not? My
They just Do Not Like Perl. Or, it's less that they don't like
it, and more that they view it as another sort of shell script
language. If your bash script gets longer than about 10 lines,
rewriting it to Perl is fine... when it gets to about 50 lines,
rewrite it in "a proper language"
I once talked about my adding Futures to perl, while I was working
there. I got a laugh - not so much an insulting "why on earth would
you do that??" sort of laugh, but imagine the sort of laugh you'd
get if you said you were adding futures to bash, or awk, or
somesuch. One of those.
In the mind of a typical Google engineer, there's no more point
making a GCP binding for Perl as there is for bash/awk/sed.
This is all starting to suggest that we have two kinds of Perl, not
just one. We have so successfully presented to the world the power of
Perl as a fancier, more powerful shell scripting system, that they
haven't noticed it can also be used for building big applications.
The "line-zero" plan would seem to make this worse. It might make
applications programming slightly nicer by making the perl interpreter
behave more as you'd want in a big application, but it does so at the
cost of making shell-script perl worse, or even breaking it entirely
(as well as breaking many of the existing pieces of code written in it).
In contrast, the "use-VERSION" plan would strengthen this situation and
turn it to our advantage. Consider a message to those, typified by
Google in my example above, who believe that there is just "perl as a
shell script", that Perl isn't suitable for real applications
programming. Tell them that one line of `use v7;` can turn this shell
script of a language into a real application-programming language, with
function signatures and try/catch and proper objects and types and ....
whatever features we go adding.
We need to view `use VERSION` not as a speed bump and an impediment to
writing code, but a powerful shiney "Look at what we can do when we
turn this switch on" marketing feature. Think of it like the TURBO
button on a late-90s PC.
I'm sure people could come up with a much better and less click-baity
"Turn that shell scripting language into a real applications
powerhouse with this One Neat Line"
but I think it summarizes my point nicely ;)
I think we all want to ensure that we can get a properly powerful
programming language out of this.
* Christian Walde writes
"I want future Perls to be as bold as possible. I want Perl v7 to
change as much as it humanly can. I want it to be brutal, a sledge
hammer. I want it to include every possible default change we can
remotely justify. I want it to change so much as to get close to
being a new language as the major version bump indicates."
* Dan Book replies:
and goes on to mention things like the `signatures` and
`unicode_strings` features; both of which would be great to enable
by `use v7` but cannot for compatibility reasons be enabled by a
We need to look at who is, and isn't, using Perl currently and consider
whether actually `use VERSION` would help us provide a better Perl for
both of these use-cases, as well as give us a great way to build a lot
of marketing and promotion around that by pointing out that both kinds
of Perl even exist.
I strongly believe that "use-VERSION" is the way to do this, and that
"line-zero" is not.
Paul "LeoNerd" Evans
firstname.lastname@example.org | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Two Kinds of Perl
by Paul "LeoNerd" Evans