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

Re: Two Kinds of Perl

Thread Previous | Thread Next
B. Estrade
March 31, 2021 00:46
Re: Two Kinds of Perl
Message ID:
On 3/30/21 6:19 PM, 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.

Maybe it's better to consider theses as:

1. [p]erl as a tool in the *nix toolbox

Generally, I write in bourne shell for scripts. My criteria for jumping 
to Perl is not number of lines; shell scripts can be organized well and 
offer an advantage of direct access to *nix glue; Perl necessarily has a 
thin layer on top. My criteria has to do strictly with data structures 
needed. If I can't do it with tmp files and hacking $IFS and starting 
thinking arrays in bash, no thank you. Another hint for me is using long 
command flags. What about DBs? What about them, I interface with DBs all 
the time via command shell scripts - for maximum flexibility, the one I 
prefer is an internal tool written in Perl (not by me, but see #2)

[side note: anyone ever take a look at an 'ed' script? looks familiar; 
though this is never mentioned wrt `perl`]

2. [P]erl as an applications language to create:

a. utilities for enabling more powerful commandline shell scripting

If I decide to jump to Perl for a cli tool; the sky is the limit. I've 
never felt compelled to jump to C or create XS unless there was some 
kind of library I wanted that didn't already have bindings on CPAN. This 
has happened exactly once for me. Regardless, I make sure this tool can 
be used by shell scripts.

b. powerful libraries, web services/applications, gui applications

Not much to say here; I think lots of people spend their time here.

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

Google cares about one thing, and one thing only.

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

I started my career in Perl by turning several hundred line Fortran 77 
"string utilities" into 1-10 line perl programs.

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

I can feel this and I like it. My hang up is not "how to run my old shit 
in the new perl", but actual fear of taking away something powerful from 
perl without replacing it or in a way that seems to retard, not help, perl.

>    * Dan Book replies:
>      "Co-signed"
>      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.

I don't know where these fit; even with my slight reformulation of type 1:


In summary, my only actual real suggestion is to consider, what you are 
calling "babbyperl" is best characterized as "perl as a tool"; this 
includes one liners and those shitty sysadmin scripts people here keep 
talking about. (I'd be careful about pissing them off though :) ).


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