Comment by eddyg | Hacker News Reader

Comment by eddyg | Hacker News Reader

Parent Full thread

Why wouldn’t the future focus be on Raku at this point? Perl is (was?) a great language, but Raku offers so much more.

Of course Raku has the “expected” things from Perl like classes and all the fantastic regex and string manipulation features.

But Raku brings:

* Optional/gradual typing (and unlike Python, declared types are enforced)

* Pattern matching, where different function definitions can be defined for different input values, like Haskell

* Multiple dispatch, so different function bodies can be defined for different sets of argument types (like pattern matching, but based on types, like Julia)

* Lazily-generated sequences, like Haskell or Clojure

* Lisp-like AST macros

* A built-in syntax for defining grammars and generating parsers

Not to mention junctions, autothreading, hyperoperators (vector operators), asynchronous operations, parallelism, concurrency, and multi-core support. The list goes on and on...

It’s unfortunate that so many programmers I talk to aren’t even willing to consider looking at Raku, even though it has a lot to offer.

But I am confused by this “future” where Perl wants to continue on to v7, v8...

I'm a little ignorant about Raku, so take my comments with a grain of salt, but...

Saying Raku is the future of Perl is like saying Objective-C is the future of C. Or Ruby is the future of C. Or Python is the future of C. Or C++ or... really most languages out there, because most of them are built on top of or branched from C.

Yet we're all quite capable of recognizing that each as its own place and path and future. They didn't replace C, and Raku didn't replace Perl.

And, of course, Perl built on what came before: C, AWK, shell scripting, sed, BASIC, LISP... and Larry Wall never pretended otherwise.

So I think Raku is a very interesting project, but calling it the future of Perl seems mistaken. Raku is the future of Raku.

> I'm a little ignorant about Raku, so take my comments with a grain of salt, but...

That makes two of us. Albeit, I began working with Raku in 2015, when it was still called Perl 6. What follows is just my opinion, so take my comments with a grain of salt.

> Saying Raku is the future of Perl is like saying Objective-C is the future of C.

This isn’t true. From the beginning, Perl 6 was always envisioned as the successor language to Perl 5. The reasons given for this were myriad: Perl 5 would benefit from having a more regular syntax (e.g. `$this{}` would become `%this{}`), a decideably parseable implementation [1], first-class OOP support in the standard library, as well as gradual typing and a concurrency/parallelism story, amongst many other things.

Objective-C is more of a bolt-on addition to C. It’s less a separate programming language from C than it is a potentially useful paradigm for programming in C. Objective-C was never designed to “replace C” the way Perl 6 was designed to replace Perl 5.

> and Raku didn't replace Perl.

Well, it should’ve. Other than nostalgia attached to graybearded Perl developers of yore, you can see ITT the writing is on the wall for Perl 5. IMO Perl 5 looks clearly destined to the same fate as Sed and Awk: a CLI “power tool” — critical to infrastructure in unappreciated ways — but ultimately disposable and not a serious solution.

Raku is to Perl 5 what Perl 5 is to Awk, IMO.

In my view, it was deeply unfortunate certain loud minorities from Perl 5 were able to derail Perl 6, as if that would be the thing that could save Perl 5 from its destiny of utter irrelevancy.

[1]: https://news.ycombinator.com/item?id=5770531

Thanks for the context! There's a lot in here that I didn't know.

That said, I do think that as soon as you rename a branch (example Perl 6 became Raku), it stops being a replacement. It's not even a branch at that point, it a fork. It's a new entity entirely, with all the pros and cons that this entails.

If the goal was to replace Perl, it shoulda stuck with Perl 6 as the name. No?

While Raku was envisioned to be the successor to perl... I remember going to the Perl Conference back in '00 and thinking "Oh, Neat!" and being excited about Perl6.

And I waited. And I waited. And I waited.

The mindshare of improving perl5 and making it competitive with the emerging application servers and compelling for a web development platform rather than Java wained.

Java became more and more useful over the next decade while perl5 remained static. People wrote some rather impressive libraries - but the mindshare wasn't there. Mod_perl in apache was useful... but BEA WebLogic was becoming more and more useful.

Meanwhile, more and more features and major changes were slated to be part of perl6... and the release date felt more and more distant in the future for where I could actually get something to work in a production environment with perl6 and say to my manager "this should be what we target for new development."

I had changed two jobs between first getting hired as a perl programmer and perl6 being released (though I pity anyone who would have tried to run perl6 in production in '15).

So while Raku is neat... it really lost its mindshare of developers over two decades.

The writing is on the wall for perl5 - I left that in '10 when I was hired as a Java developer rather than a Perl developer.

But the writing is on the wall for Raku too - already. In '00 and even a few years later, there was still enough inertia to say "perl6 is out, lets move our stack from perl5 to perl6". Today? I don't see it. I think there would be a stronger push from perl5 to Java (or other JVM language) or Python depending on the shop.

The last version of perl4 was in '93 when perl5 started work. Perl 5.000 was released October 17, 1994. 5.004 was in '99... and then the long dark time began as efforts for perl6. Four years later we got perl 5.6... and another five years for perl 5.8. Still no perl6.

Raku won't replace perl5 because any place that perl5 is going to be replaced isn't likely going to move to Raku. The effort to move from perl5 to Raku is likely similar to the effort to move to Java, or Python, or Ruby... all languages with greater mindshare and developer stories (and Jetbrains IDEs).

I've left perl. Any scripting that I do now is groovy which leverages my tooling in Java.

In the "well it should have replaced perl5" - that boat sailed over a decade ago when the systems running perl were being migrated to other platforms and languages... and the developers lost faith, had their beards turn gray, and retired.

> The last version of perl4 was in '93 when perl5 started work. Perl 5.000 was released October 17, 1994. 5.004 was in '99... and then the long dark time began as efforts for perl6. Four years later we got perl 5.6... and another five years for perl 5.8. Still no perl6.

Some of your dates are off a bit. 5.004 was in 1997, 5.6 in 2000, 5.8 in 2002, it was only 5.10 that took 5 years after that.

> And I waited. And I waited. And I waited.

I agree Raku took far, far too long to please those who waited.

I'm sad that atweiden talks of Perl being disposable, especially in a thread about its future, and that they imply Raku is not destined for utter irrelevancy. I love both Perl and Raku, but irrelevancy is where we're all headed in the final analysis.

That said:

> The effort to move from perl5 to Raku is likely similar to the effort to move to Java, or Python, or Ruby...

Fwiw:

* You can use Perl libraries in Raku.[1]

* You can use Perl features in Raku.

* Raku has an excellent Jetbrains IDE.[2]

* It has a rounded out developer story -- ecosystem, OS packaging, compiler releases, mass testing, stackoverflow knowledgebase, sophisticated profilers, debugger, and so on.

[1] https://news.ycombinator.com/item?id=26575153

[2] https://commaide.com/

Raku regex performance sucks, for one.

Let's parse some data into a hash in Perl:

    %words = ($input =~ /([^\n\t]+)\t(\N+)/g);

In Raku, equivalent code will be slower by an order of magnitude or more. The only way I've managed to get comparable performance is to write code like this:

    use nqp;
    my str $str = $input;
    my int $pos = 0;
    my int $chars = nqp::chars($str);
    while $pos < $chars {
        my int $tab = nqp::index($str, "\t", $pos);
        my int $nl = nqp::index($str, "\n", $tab);
        %words{nqp::p6box_s(nqp::substr($str, $pos, $tab - $pos))} =
            nqp::p6box_s(nqp::substr($str, $tab + 1, $nl - $tab - 1));
        $pos = $nl + 1;
    }

Generally, the situation has been getting better, though. In contrast to the early days,

    for $input.lines {
        my $tab = .index("\t");
        %words{.substr(0, $tab)} = .substr($tab + 1);
    }

also performs adequately today.

I used Perl for years... Perl missed its transition window.

Randall Schwartz and the community would tell you that “Perl is more popular than ever”, because the rising tide of programmers meant it was used by more people.

The Perl 5 vs Perl 6 created weakness and Python filled the void and won over that segment.

It became the new standard. Now it will be very difficult to dislodge.

Anyway, the entire Perl 6 fiasco will serve as a lesson for future projects.

While confusion around P6 certainly hurt Perl, Python started to conquer over areas previously held by Perl even before that. AFAICT educational establishments didn't like Perl because it embraces expressivity. There's more then one way approach feels good once you grok it, but for the most teachers its anathema - it means you need to explain much more.

Eh, kind of. Perl as a teaching language is obviously terrible, but on the other hand Python outside of academia is basically the DSL to call numpy. I think the problem is, more simply, competition. Now that Perl isn't the only reasonable dynamic language (you have ruby, python, nodejs...), people have more choices, and are ultimately just going to use what they already know as a 'plumbing' language.

See also "IPv6" - the number 6 is cursed.

see also PHP6

Because Raku and Perl5(7,8,9) communities are now two separate worlds and is to be considered two separate languages.

Raku seems like an incredible language which I would learn if I was a capable enough developer to understand the implications of everything it offers.

Raku is neat language, but it's not Perl. You might as well ask if the future is Python.

Perl v7 as I understand aims still to be fully compatible with Perl 5, and function as a bridge towards v8. This is to attempt smooth gradual transition, something that Raku distinctly does not have.

Fwiw Raku does have an attempt at a smooth gradual transition, and in some regards it's a remarkable success.[1]

That said, its approach is profoundly unlike the v7 strategy. My take on v7 is that it boils down to:

* Pulling off such a silky smooth gradual transition that it can continue to be used for /usr/bin/perl without unduly inducing distro and/or user revolt/forking/eoling.

* Setting the stage for a gradual clean up / refresh loosely akin to Python 3 relative to Python 1, but without Python's abrupt incompatibility discontinuities and the consequent decade of contentious and costly transition pain.

[1] https://news.ycombinator.com/item?id=26572531

It wouldn't be much of a future if the large amount of existing Perl code couldn't be utilised.

The original vision for Perl6 included a runtime called Parrot which would have been capable of running both Perl6 and Perl5.

If Parrot had been realised, Perl6(Raku) and Perl5 would have been able to interop similar to how Java and the other JVM languages can.

But without that, Raku and Perl remain incompatible so e.g. the existing large Perl ecosystem can't be leveraged from Raku.

> Raku and Perl remain incompatible so e.g. the existing large Perl ecosystem can't be leveraged from Raku.

Au contraire, they remain compatible along the lines shown in this example from a StackOverflow answer[1]:

    use Text::BibTeX::BibFormat:from<Perl5>;
    ...
    @blocks = $entry.format;

I'll be happy to dialog about this compatibility, but the key thing is to start with an open mind; a recognition that the original vision predated Parrot; and a recognition that Rakoons have never relinquished that original vision even while many of us are delighted that Perl folk are keeping Perl healthy as a separate thing in its own right.

To be clear, the realization of Larry's original vision is not constrained to interop with Perl. Raku has extraordinary potential, some already realized, for pan-language compatibility via its Inlines[2].

The steady improvement of the exemplar Inline[3] for the last 6 years; its evident maturing; its suitability as a solid blueprint for upgrading all the others; all of this bodes well for being able to use a lot of the world's best existing code from within Raku this decade, with Inline::Python quite plausibly shining in this regard within the next 2-3 years.

[1] https://stackoverflow.com/a/45181464/1077672

[2] https://modules.raku.org/search/?q=inline

[3] https://github.com/niner/Inline-Perl5

Reply on news.ycombinator.com