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

Re: Two Kinds of Perl

Thread Previous
Leon Timmermans
March 30, 2021 23:49
Re: Two Kinds of Perl
Message ID:
On Wed, Mar 31, 2021 at 1:20 AM Paul "LeoNerd" Evans
<> 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."
>      --
>   * 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
>     'forever')?"
>      --
>   * 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.


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