Is Perl 6 Being Renamed?

The type system and multiple get rid of so much “if this then do that” code.

  multi sub eat-pie( Pie slice where *.is-custard ) { ... }
  
  multi sub eat-pie( Pie slice where *.is-fruit ) { ... }

  multi sub eat-pie( Pie slice ) { ... }

  eat-pie( a-slice-of-pie );

That’s just awesome.

There's quite a bit of depth to Perl, yes.

People looking at it for the first time often look at the variables available, the built-in functions and procedures available, the fact that regularish expressions have their own mini language that nests naked inside the main syntax and a few oddities like sigils and sometimes determine there's a huge breadth-first search to learn all of this. People almost immediately go to, "even if I don't need to use all of this, I need to understand all of it to maintain other people's code". If you follow a really unprincipled developer who's showing off, that may be the case.

I've been programming in Perl5 for some part of my job duties since 1998. In high school before that, I was studying two foreign human languages and was taught the basics of four or five programming languages. At university I started a third foreign language and another programming language. All this time I was also learning a bit of programming language here and there on hobby projects. I've learned several more programming languages since, some of which I use alongside Perl pretty much daily.

From my experience the core language of Perl5 contains a subset of the language which could be thought of as its virtual core language. Much of what's built in is used more like specialty modules that are only used when necessary. I think this has a lot to do with Perl up through the Perl 4 days not having great module support. There are other huge languages in the wild. Ada, PL/I, and any shell on a system with a big bin or sbin directory come to mind. It really is, in my experience, a depth-first language with lots of side paths to explore one at a time. I don't have hard data on people learning the language, but I've met many people who share this sort of thoughts about it.

One solid example of a core feature that's really complete but rarely used is formats. You can have output sent through these sieves that are a template language built into core Perl5. They are really handy if you're using Perl to match a format in RPG or COBOL or if you're just generating the sort of reports you might generate from those. You don't ever need to worry about them if you're not working on code that does that. I've written Perl formats two or three times and had to deal with them in maintenance maybe half a dozen times including the ones I wrote. There's a separate manual document on them. They are not part of the core in Perl6/Raku but someone's older program would break if they were taken out of Perl5. https://perldoc.perl.org/perlform.html

There's a separate document for pack() and unpack() which are very handy if you're hand-translating character sets or working with a binary protocol or something. Otherwise you'll not use those, but they are in that huge core language.

The data structures and references in Perl5 look different than in many other languages. There are docs on syntax, and others on referces, and then another specifically on data structures. Perl6 uses similar dot notation to other languages, which is one of the syntactical incompatibilities with Perl5.

One place where the "all those choices" is a real drawback is the number of ways to make and use objects in Perl5. The initial way Larry gave us is workable and performant but a bit ugly and utilitarian. Many CPAN modules brought their own module systems. Then, after the Perl6 team figured out what they wanted to do for objects, Perl5 got a backport called Moose. Moose is nice to use but is a behemoth and uses memory like one. Someone came along and gave us a lighter version named Moo, and then someone gave us Mouse and another group gave us Mo. In the industry and community, Moo is considered the best practice now. It even upgrades just specific objects to full Moose objects if the lightweight version won't do for some reason. So if you can write and maintain Moo code and the original Perl5 blessed data structure objects you're good for most object-oriented Perl code, but far from all. There's also Object::InsideOut, Class::Accessor, and I forget how many others.

One place where Perl6/Raku/Camelia really fixes things is having a really nice default object system. Another place it fixes things is there's really no need to graft another object system on in place of it, because it include a full and fully accessible MOP.

The biggest mistake IMHO was calling the perl language spec for 6.x "Perl". Because it took so long to finish and to get a proper implementation, a lot of people thought perl as a whole was mostly dead.

For the most part, language specs are either bundled fairly tightly with a reference implementation, or have a completely different name. (e.g. ECMAscript, SQL)

The happy-path syntax is pretty straightforward. I wonder if you're under the impression like some that you need to use the arrow syntax or prefixing dollar for every reference, and not just the first? That's not the case. e.g.

    my @a = (
      { first=>1, second=>"b", another_ref=>["y"] },
      { first=>1, second=>"b", another_ref=>["z"] },
    );

    say $a[0]{first}; # Outputs 1
    say $a[1]{another_ref}[0]; # Outputs z
    
    my $a2 = \@a; # top level is a reference too now
    say $a2->[1]{another_ref}[0]; # Outputs 1, arrow only needed at top level
    
    # The following are alternate syntax that I find unnecessary and better left alone (and most do)
    say $a2->[1]->{another_ref}->[0]; # Outputs 1, explicit, entirely unneeded because it's unambiguous without extra arrows
    say $$a2[1]{another_ref}[0]; # Outputs 1, extra prefixing $ dereferences first level ref

Personally, I'm happy with a single arrow that lets me know if I have a reference or not. References are important, because they denote that this data may be accessed elsewhere as well, so I'm happy to have a small reminder. Inner level references needing a bit of care if they are copied is somewhat normal though, most non-toy languages have some concept of deep or shallow copying.

That is impressive!