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

Two Kinds of Perl

Thread Next
Paul "LeoNerd" Evans
March 30, 2021 23:19
Two Kinds of Perl
Message ID:
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
    real files.

    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
reply was:

    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
headline than

  "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
    line-zero plan.

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

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