http://www.perlmonks.org?node_id=1190570


in reply to Re^3: Think Perl 6 (new book)
in thread Think Perl 6 (new book)

It's Java and Python that have lowered Perl in use, not perl6.

Python has no doubt eaten into some of the space that was Perl's. They are quite similar in many respects and the choice of which to choose for a project will have little to do with the technology and more to do with available code and the programming team's preferences.

But Java? Nah, I don't buy it. Java and Perl are about as far apart as you can get in terms of both language and implementation. Pick any project and you won't find anyone hovering between doing it in Java or in Perl - the spec will dictate the language every time if that's the binary choice.

Secondly, Perl6 hasn't lowered Perl usage yet. But it will, and not from a technological standpoint because Perl6 will always suffer from the same implementation problems as Java due to its architecture. No, it will have a detrimental impact on Perl usage purely because of its name.

My anonymous brother jested above about Perl7. If there ever is to be such a beast I hope that TPTB learn their lesson from the Perl6 naming disaster and choose to call their new language something else entirely. Python4 would be an amusing name for it.

Replies are listed 'Best First'.
Re^5: Think Perl 6 (new book)
by raiph (Deacon) on May 19, 2017 at 13:02 UTC
    "Perl6 {will lower Perl usage} not from a technological standpoint because Perl6 will always suffer from the same implementation problems as Java due to its architecture."

    I found this sentence in your post confusing given what you said before. So I seek clarification. Are you saying words to the effect that:

    • "Perl6 does not suffer from the same implementation problems as Java so ..."; or
    • "Perl6 does suffer from the same implementation problems currently but that's temporary so ..."; or
    • "Perl6 does suffer from the same implementation problems as Java and always will; nevertheless ..."; or
    • something else?
    Thanks in advance if you have time and care to clarify which you meant.

      For clarity: Perl6 does suffer from the same implementation problems as Java and always will. Nevertheless ...

      In my post I didn't use the word "always" because who knows what will happen? Maybe in 5 years Rakudo will be abandoned and the standard Perl6 implementation will be quite different. But I've seen nothing to suggest that, looking from the outside.

      AFAICS, Perl and Perl6 will always have orthogonal use cases. It's only the Perl6 name which will damage Perl's usage and that is a real shame.

      Update Oct 2019: I'm pleased to say that there is finally a new name for this language (Raku) which we can all hope will go some way to mitigating the damage already done to Perl and ensure that no more is done in future.

        Thank you. So I'm now thinking your overall opinion might be stated as something like "It seems that Perl 6, or at least the Rakudo Perl 6 compiler, will almost certainly always suffer from the same implementation problems as Java, or at least javac, due to its architecture, for many of Perl 5's most popular use cases."

        Are these problems you see specific to particular VMs like the JVM? Or do you see the same sorts of problems applying even to, say, LuaJIT and its VM, for much the same reasons?

        If LuaJIT's VM is OK, what are the main things about it that makes the LuaJIT project a fundamentally different and potentially acceptable architectural approach, in your view, for the use cases you focus on?

        If you think that some VMs, in some scenarios relevant to you, can be a good thing, what are the main things that lead you to think that MoarVM misses the mark?

         same implementation problems as Java and always will.

        Interesting, why?