[btilly]

Learn Perl 5. Perl 6 is an interesting research project for future directions that it doesn't look like the programming world will go.

Most of the weirdness of Perl goes away when you read $ as "the", @ as "these" and a hash lookup as "of".

[perigrin]

That's not exactly fair to Raku. A more fair critique (and keeping with the theme of this thread) is that Raku is less focused on integrating with the Unix command line than it is on tool building putting it closer to Python than Perl(5) in the spectrum of things. This was a specific design influence dating back to the first days of Perl 6, so it makes some sense.

[btilly]

That's not exactly fair to Raku.

I know that Raku supporters disagree with me, but that has been my considered opinion for several years. And this has been something I put a lot of thought into.

Let me lay out the case.

What are the key ideas invented or promoted in Perl 6 / Raku that people get excited about?

- Object-oriented programming including generics, roles and multiple dispatch

- Functional programming primitives, lazy and eager list evaluation, junctions, autothreading and hyperoperators (vector operators)

- Parallelism, concurrency, and asynchrony including multi-core support

- Definable grammars for pattern matching and generalized string processing

- Optional and gradual typing

I got this list from https://www.raku.org/. It is what Raku people think is interesting about their own language. (So I don't get to bring up things I really don't like, like twigils.)

Some of these ideas are mainstream, some not. According to Tiobe (yes, not to be taken seriously but it is accurate enough), the top languages today are Java, C, Python, C++ and C#. Let's eliminate from the list of Raku features anything that is supported by at least 2 of them to come up with things that are novel in Raku while not being broadly adopted today. The list gets much shorter.

- Roles (OO programming)

- Junctions, autothreading and hyperoperators (functional programming).

- Definable grammars for pattern matching and generalized string processing

- Optional and gradual typing

How many of these will be widely adopted by top languages in 25 years? My best estimate is 1. Could be none, could be 2, I'd be shocked if there were 3.

I say opinion, but it is a fairly well educated opinion. Here is my argument about each.

- Roles. They have been around for some years. The only language where I have seen them used heavily is Perl 5. Nobody else seems excited.

- Junctions are mostly a bit of syntax around any/all which is pretty convenient already. Autothreading and hyperoperators are a cool sounding way to parallelize stuff, but getting good parallel performance is complex and counterintuitive. I don't think that this is a good approach.

- Definable grammars are an interesting rethinking of regexes, but parsing is a difficult and specialized problem. I don't see an interesting approach in an unpopular language changing how the world tackles it.

- Optional and gradual typing sounded great when it made it into the Common Lisp standard. But over 30 years later, only Python supports it of the top 5. And it isn't widely used there. I see nothing about the next 25 years that makes it more compelling than in the last 25. (Though Raku's implementation is far, far better than Perl 5's broken prototype system. But that is damning with faint praise.)

So use Raku if you find it fun. You'll get a view into an alternate universe of might have beens. But I still believe that the ideas that are new to you won't be particularly relevant to the future of programming.

-----

It is hard at this date to make what a similar list would have been for Perl 5 at a similar stage. People were excited about CPAN. Perl people kind of took TAP unit testing for granted and didn't appreciate exactly how important it was. Perl people liked the improvements in regular expressions but probably couldn't have guessed how influential "perl compatible regular expressions" would become across languages. Ideas we were excited about like "taint mode" went approximately nowhere. And some ideas that Perl helped popularize, like closures, were ones that few Perl programmers realized were actually supported by the language.

However it would be a true shocker if Raku was anywhere near as influential on the programming landscape 25 years from now.

[zimpenfish]

> Junctions are mostly a bit of syntax around any/all

A quick look at Raku junctions makes me think they're basically a slightly tarted-up version of Icon's generators and goal-directed execution (which is no bad thing, of course but hardly novel.)

[lizmat]

Then you definitely did not grok it. What I gather from https://en.wikipedia.org/wiki/Icon_(programming_language)#Go... is that Icon's goal directed execution is more like `react whenever` in Raku (https://docs.raku.org/language/concurrency#whenever)

Junctions autothread. What does that mean? Using a Junction as an ordinary value, will cause execution for each of the eigenstates, and result in another Junction with the result of each of the executions. An example:

    # a simple sub showing its arg, returning twice the value
    sub foo($bar) { say $bar; 2 * $bar }

    # a simple "or" junction
    my $a = 1 | 2 | 3;
    say foo($a);  # executes for each of eigenstates
    # 1
    # 2
    # 3
    # any(2, 4, 6)

Documentation: https://docs.raku.org/type/Junction

[b2gills]

Multi-threading and Junctions auto-threading are NOT the same thing.

Calling it auto-threading has lead many people to the wrong conclusion.

(It is possible that auto-threading may be done multi-threaded in the future, but it doesn't do it currently.)

[b2gills]

Roles take the place of all of these:

- Java interfaces

- abstract classes

- C++ templates

- Python mixins

- Smalltalk traits

So are you telling me that you haven't used any of those?

---

Roles combine all of those features very simply.

    role Interface {
        method hello-world ( --> Str ) {...}
        # the ... means it needs to be implemented by consuming class
    }

    role Abstract {
        has Str $.name is required;
        # adds an accessor method of the same name

        method greet ( --> Str ) {...}
    }

    role Template[ Real ::Type, Type \initial-value ] {
        has Type $!value = initial-value;

        method get ( --> Type ) {
            $!value
        }
        method set ( Type \new-value ) {
            $!value = new-value
        }
    }


    my $value = 42 but anon role Mixin {
        method Str ( --> 'Life, the Universe and Everything' ){
        }
    }

Roles were heavily influenced by Smalltalk traits. Rather than being limited to those uses, Roles were expanded to include all of those other use-cases as well.

---

Really Roles are a better method of code-reuse than inheritance.

    role Animal {
        method species      ( --> Str  ){...}
        method produces-egg ( --> Bool ){...}
    }

    role Mammal does Animal {
        method produces-egg ( --> False ){
            # most mammals do not produce eggs.
        }
    }

    role Can-Fly {
        method flap-wings ( --> 'flap flap' ){
        }
    }



    class Bat does Mammal does Can-Fly {
        method species ( --> 'Bat' ){
        }
    }

    class Bird does Animal does Can-Fly {
        method species ( --> 'Bird' ){
        }

        method produces-egg ( --> True ) {
        }
    }

    class Platypus does Mammal {
        method species ( --> 'Platypus' ){
        }

        method produces-egg ( --> True ) {
            # override Mammal.produces-egg()
        }
    }

Of course a simple example doesn't do this ability justice. It really shines on large code-bases.

For a better example see: “Curtis Poe (Ovid) - Roles versus Inheritance” https://www.youtube.com/watch?v=cjoWu4eq1Tw

That is of course about roles in Perl, which doesn't have all the same features. All of the points do apply to Raku roles though.

---

Raku has so many good ideas it would be a waste if other languages didn't copy at least some of them. I of course can understand if a single language doesn't want to copy all of them at the same time.

It would definitely be a waste if no other language tries to combine regular expressions, parsers, and objects like Raku grammars have done.

At the very least Raku regular expressions are easier to understand than Perl compatible regular expressions. (Note that I very much DO understand PCRE syntax, having used it heavily in Perl for many years.)

Compare the Raku grammar for JSON https://modules.raku.org/dist/JSON::Tiny:cpan:MORITZ/lib/JSO... to the Perl version https://metacpan.org/release/JSON-Decode-Regexp/source/lib/J...

I would like to point out that when JSON started allowing any value as a top-level result, it actually made the Raku code simpler. https://github.com/moritz/json/commit/9888329771730574967197...

[lizmat]

Perl 6 was indeed an interesting research project. Raku is much more than that.

BTW, now that Perl 6 has been renamed to Raku, you can drop the "5" from "Perl 5", and just call it "Perl". Saves on typing!

Re: learning Perl: by all means, but don't let that stop you from learning Raku as well.