Front page | perl.perl5.porters |
Postings from June 2020
Re: Announcing Perl 7
Thread Previous
|
Thread Next
From:
David Mertens
Date:
June 29, 2020 00:16
Subject:
Re: Announcing Perl 7
Message ID:
CA+4ieYWzERXW1v8y-b=m+UL_f+GzaE77W_CadEgSJbrOOw0BqQ@mail.gmail.com
While it's fun to get into the weeds, I am convinced that any technical
problem can be solved by the fine people on this list. I have faith in the
Perl community's creativity and resourcefulness. That means that the more
important thing is to make the decision. Sawyer has done this, and has
explained why he made those design choices in his talk.
Now we have the fun of implementing a practical solution.
Up to this point the discussion has focused on trying to solve technical
issues at the language level. Must we? Can't we solve some of these with
tooling?
As an example, consider a distribution written targeting Perl5 (which is
all of CPAN at the moment). When you try to install it under Perl7, EU::MM
or M::B know that you are installing it under v7. With a little metadata
(and sane defaults) these tools can be told the distribution targets Perl
5. In that case they can do all kinds of stuff for us. Perhaps they can add
shebang lines to the top of every .pm and .pl file with a command-line
switch indicating Perl 5. Perhaps they can add the "use compat::perl5â line
(however it is spelled) at the top of each module/script. Perhaps all Perl
5 modules are installed with the suffix .pm5, and Perl 7 is taught to look
for those alongside .pm and .pmc. Perhaps all files with a .pl5 extension
are parsed with Perl 5 compatibility, and the tooling automatically
switches .pl to .pl5. And finally, the tooling can be more conservative
than the language when it comes to defaults. No targeted Major version?
Tooling can assume Perl 5 until 2040 for all I care.
In short, I don't believe that CPAN-compatibility needs to be solved at the
language level. Giving new users all the shiny bits out of the box *for*
*free* is really appealing to me. This is do important to me that I will
step up and help with the tooling if that is the route that makes the most
sense, and I bet I'm not alone.
David
On Sun, Jun 28, 2020, 3:13 PM Eric Wong <p5p@yhbt.net> wrote:
> Todd Rinaldo <toddr@cpanel.net> wrote:
> > > On Jun 26, 2020, at 4:56 PM, Eric Wong <p5p@yhbt.net> wrote:
> > >
> > > Scripting languages like Perl, Python, Ruby, Tcl have
> > > significantly less room to evolve than compiled languages once
> > > they've reached critical mass.
> > >
> > > JavaScript is an exception. For most users it's shipped with a
> > > complex browser which requires constant updates, anyways. I
> > > can't say I know much about NodeJS, but I do hear about debacles
> > > (e.g. "leftpad") and stay clear of it.
> >
> > You left out PHP which has added/removed stuff regularly as it
> > has bumped versions. To my knowledge their user base has grown
> > not shrunk as they made those changes.
>
> True, I don't know much about PHP, but my limited understanding
> is that it's far less used for tooling (build systems, packaging
> systems, CLI tools) than the others. It's certainly not part of
> default OS installs the way Perl and Python tend to be.
>
> Honestly, I think Perl could appeal to newbies (and maybe
> returning old schoolers) who've been bitten by the Python 2/3
> mess.
>
Thread Previous
|
Thread Next