Front page | perl.perl5.porters |
Postings from March 2021
Re: Two Kinds of Perl
From: Leon Timmermans
March 30, 2021 23:49
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
> 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
> -- 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.