in reply to Re^12: Ovid's take on the renaming of "Perl6" (updated)
in thread Ovid's take on the renaming of "Perl6"

Perl5 releases in the 200x years were rare because everybody was expecting Perl6 to arrive.

My memory is that the porter list was already bogged down to a near standstill and it had little to nothing to do with Perl 6 because there was already a complete schism of attitudes and a growing abandonment of Perl 5, not because of the promise of Perl 6 but the lack of agreement on features and backcompat and the open road of Ruby and Python and the corporate enforcement of Java. It was a small handful of devs who sparked the renaissance around 2005 and the following years and—not to take away from the amazing, crucial, gracious work and dedication of folks like dave_the_m—it was entirely framework based. Even a piece of crap like PHP will thrive with useful, easily deployed, applications/frameworks.

Yahoo and Amazon both decided to abandon Perl completely independently of Perl 6. I was at Amazon when it happened and it was a year, maybe 18 months, before Jon Orwant threw those mugs.

Perl 6, to me, is about 10th on the list of Perl 5 problems (with PHP, Ruby, Python, Java, and others taking all top slots) while still in the top set of things that helped it survive. Even today, infighting over Perl 6 is worse than Perl 6 ever was… ECMAScript is the most likely candidate to relegate Perl 5 to permanent maintenance mode.

  • Comment on Re^13: Ovid's take on the renaming of "Perl6" (updated)

Replies are listed 'Best First'.
Re^14: Ovid's take on the renaming of "Perl6" (updated)
by LanX (Saint) on Sep 02, 2019 at 22:02 UTC
    But can you tell how many talents never tried to join p5p or didn't try to suggest improvements because Perl 6 was on its way?

    Ruby was a shock for me after I realized how close it semantically was to Perl 5.

    Top Perl 5 with

    • Smalltalk'ish OOP
    • function signatures
    • better code blocks
    • autoboxing of primitives to wrapper classes
    • basic support for DSL's
    And you have basically Ruby, just twice as fast.

    Update

    And the perception of a dieing language came because such improvements couldn't be forged into a newer version.

    PHP 5 came with a standard OO system while Perl is still promoting dozens of competing CPAN frameworks 1 1/2 decades later.

    A vision and a roadmap would have helped for sure.

    > ECMAScript is the most likely candidate to relegate Perl 5 to permanent maintenance mode

    Not only Perl. And TypeScript is gaining even more speed.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

      PHP 5 came with a standard OO system while Perl is still promoting dozens of competing CPAN frameworks a decade later.

      Long may it continue to do so. I consider this a strength of Perl, not a weakness.

        The learning curve is too steep.

        I remember reading this one perldoc about oop with cows mewing again and again (can't find it anymore), even bought the book Randall Schwartz published at O'Reilly's with that cows without having a clue after reading it thrice.

        This changed only after reading Damian's book on OO.

        At the same time you've already wrote several modules in Python by reading the docs (and ignoring the builtin problems of missing accessors)

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

      Better code WHAT? You mean the insanity with Yeyeieieield? A confusing special syntax for methods taking just one lambda (sorry, code block) while the syntax in case you dare to need to pass two is totally different and even more confusing?

      Jenda
      1984 was supposed to be a warning,
      not a manual!

        Perl has the prototype (&) for code blocks but only as first argument. The rest of your rant is cryptic for me. - lanx

      PHP 5 came with a standard OO system while Perl is still promoting dozens of competing CPAN frameworks 1 1/2 decades later.

      That's just nonsense. First, Perl doesn't promote one, another, or any CPAN OO frameworks. Perl is a language. Second, overwhelmingly most professional Perl programmers I am aware of use Moo, with some sticking to the predecessor Moose. No one I know uses bless, and there is no steep learning curve to

      package MyClass; use Moo; has some_attr => ( is => 'ro' ); sub some_func { uc(shift->some_attr) } # eg 1;
      Maybe you should sit down and spend a couple of hours with one of Gabor's tutorials and gain some relevant skills instead of just yammering about historical meta-questions and adding more and more confusion to the debate through your ill-informed commmentary?


      The way forward always starts with a minimal test.
        > there is no steep learning curve

        Unfortunately, there is. See How Moose made me a bad OO programmer for some examples - I don't agree with everything the presenter says (and you might notice me suggesting a different approach), but the underlying message is true: has means several things at the same time and it's pretty hard to understand it.

        Update: The main problem is that Moo(se) doesn't distinguish between cached constructor arguments and public attributes of the object syntactically.

        map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
        Perl doesn't promote one, another, or any CPAN OO frameworks.

        Sorry to crash the party but the first half of perlootut teaches "Object-Oriented Programming in Perl" while simultaneously saying things like "we strongly suggest you don't build your objects from scratch" at least 5 times. The last section "PERL OO SYSTEMS" then "strongly recommends" using Moose or Moo or Class::Accessor or Class::Tiny or "literally dozens of other OO-related modules on CPAN".

        But I never use anything other than bless to roll my own objects... *shrug*