Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Improving p5p: Perl is going to stay Perl

by marto (Cardinal)
on May 17, 2021 at 19:06 UTC ( [id://11132699] : perlnews . print w/replies, xml ) Need Help??

Neil Bowers has posted Improving p5p: Perl is going to stay Perl, which is worth reading.

Replies are listed 'Best First'.
Re: Improving p5p: Perl is going to stay Perl
by karlgoethebier (Abbot) on May 18, 2021 at 14:56 UTC
    «We just spent a painful year deciding that in fact, we're not going to enable strict by default…»

    Oh my God! See also Little-Endians and Big-Endians.

    «The Crux of the Biscuit is the Apostrophe»

Re: Improving p5p: Perl is going to stay Perl
by parv (Parson) on May 17, 2021 at 22:49 UTC

    Excellent. Nothing would change any time soon.


    The ideas proposed -- at the least the ones I had initially read and then stopped reading further updates when I realized too much baggage that some people prefer to tow for a while longer -- were not in any way were going to change Perl 5 to something else. To look for any significant, meaningful changes in future perl 5 would be inviting hopelessness.

      I'm deeply convinced that "Perl" doesn't exist, or to be more precise, that there is effectively more than one language running on the same engine.

      People can't agree because they fail to realize that they are aspiring to very different goals and ideals.

      It's first and foremost a communication disaster.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery

        I've thought of Perl for a long time like the PL/I or Ada of the dynamic, getting things done languages. Useful, but huge. I forget the exact quote and I can't find it to get it perfect or to credit someone. I don't even remember which language it was originally about, but I'm thinking it was PL/I. It goes something like "It's a number of complete programming languages each struggling to get free".

Re: Improving p5p: Perl is going to stay Perl
by davebaker (Pilgrim) on Jun 30, 2021 at 14:07 UTC

    Possibly naive and unoriginal idea follows, but it strides into the blinding sun of the PerlMonks arena...

    If the principal reason that managers and others don't like Perl is the difficulty of maintaining or extending a Perl script written by an earlier programmer, then what if...

    CritiPerl -- a flavor of Perl in which a program has zero violations of Perl::Critic at the 'brutal' level of severity. If a violation occurs during development, it would fail "perl -c".

    Or perhaps there would be a different severity level that implemented other coding guidelines enforced by Perl::Critic at a new 'critiperl' severity level, which would be based on coding techniques that are "straightforward" in terms of being capable of easy maintaining and extension of the program by later developers (many or most of which probably would be the same as those of CritiPerl's 'brutal' severity level).

    There would be much wailing and gnashing of teeth in developing an agreed-upon critiperl severity level, of course (Perl being Perl), but what if the result were the ability to present an essentially clearer, cost-effective language to decision-makers (e.g., programming instructors as well as managers). It would have the benefit of being understandable by existing Perl programmers, and would be able to use all of the wonderful CPAN modules, whether or not the code inside those modules is CritiPerl-compliant.

    It wouldn't be a new language (though essentially it is, and that's how it could be pitched) because it would be implemented just by saying that "a CritiPerl program must start with 'use CritiPerl'." The naming and marketing would be critical (cough, cough).

    It's sounding a bit like the "use Modern::Perl" route at this point in my thinking. Or a brutal version of Guacamole ("use Guacamole"). Or something like Typescript is to JavaScript.

    CritiPerl wouldn't be a Swiss army knife; it would be more of a Japanese sword. It's easy to figure out how to wield it, and devastatingly effective (especially given the legion of CPAN modules at the programmer's side).

    (Note: Some stylistic-only edits have been made here.)

Re: Improving p5p: Perl is going to stay Perl
by AlexP (Pilgrim) on Jun 29, 2021 at 12:34 UTC

    Does this mean that we will not see perl7 next year?

A reply falls below the community's threshold of quality. You may see it by logging in.