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

Re: Two Kinds of Perl

Thread Previous
From:
Leon Timmermans
Date:
March 30, 2021 23:49
Subject:
Re: Two Kinds of Perl
Message ID:
CAHhgV8h22nQ8s1=gXWa1VdgxqG9XxTV6JkG0ST7td0x=pdgwcQ@mail.gmail.com
On Wed, Mar 31, 2021 at 1:20 AM Paul "LeoNerd" Evans
<leonerd@leonerd.org.uk> wrote:
>
> 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."
>      -- https://twitter.com/leon_timmermans/status/1376299682293542919
>
>   * 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."
>      -- https://www.nntp.perl.org/group/perl.perl5.porters/2021/03/msg259423.html
>
>   * 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
>     'forever')?"
>      -- https://www.nntp.perl.org/group/perl.perl5.porters/2021/03/msg259562.html
>
>
>   * 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 ;)

Obviously I recognize the above, but I'd like to highlight an
important facet of this: one of these groups of users is
well-represented on p5p, and the other is not.

Leon

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About