in reply to Re^2: Will Perl 6 Replace Perl 5?
in thread Will Perl 6 Replace Perl 5?

I find that what many people actually mean is
Perl 6 is not the next version of Perl 5
Which is right, of course.
Well, duh, that the latter is true is bloody obvious. Perl 5.10 isn't the next version of Perl 5.8 either.

I can't talk for the people you've engaged in discussion, but when I say that I think "Perl 6 isn't the next version of Perl", I mean it in the same way as if I say that I don't think that "Kurilla isn't the next version of Perl". Nor have I considered Ruby to be a version of Perl ('next', 'different', '...').

Still I can see why many Perl 5 programmers fear
Fear? Noone was talking about fear. And the people I talk to, don't fear Perl 6. Just as they don't fear Ruby. Of Java. Or C. Or any other existing or emerging language.

It's a bit cheap to dismiss people who refuse to drink the Perl 6 Kool-Aid as being fearful.

Replies are listed 'Best First'.
Re^4: Will Perl 6 Replace Perl 5?
by moritz (Cardinal) on Jan 04, 2010 at 14:01 UTC
    Well, duh, that the latter is true is bloody obvious.

    If you say it as clearly as I did, yes. But many people seem to expect that Perl 6 = Perl 5 + X, which it isn't, but which would make it a next version of Perl 5.

    I'm still curious: What criteria would a language (any language) have to fulfill so that you would call it the next version of Perl?

    Perl 6 - links to (nearly) everything that is Perl 6.
[reply]
      What criteria would a language (any language) have to fulfill so that you would call it the next version of Perl?
      For starters, it should be (largely) backwards compatible. For instance, the majority of CPAN code (just to take an example) should run without any problems or differences. That's not true with Perl 6. Operators change names. Sigils change. The regexp syntax is quite different. For loops change. Hash indices change. There'll be syntax changing whitespace. And no doubt there'll be more, but I don't look that often into Perl 6.

      Now, noone has to defend the choices that were made. That's not the point. But I cannot take a Perl 5 program, and gradually add Perl 6 constructs (I'm aware of the plans to be ablet to compile Perl 5 - but that's not backwards compatible - then Perl 5 could be called backwards compatible with sh, because it's able to fire up sh for you).

      There are too many syntax changes to make it backwards compatible in my book.

      Note that I'm not saying 100% backwards compatability should always be achieved. But IMO, the changes with Perl are too much that I won't call "Perl 6" the same language as "Perl".

[reply]

        Largely would be enough. I mean if things that HAVE TO change changed and new things were added, I would happily call the result the next version of Perl. But that's not what happened with Perl 6. Things that should have been left alone were changed just for the sake of change (-> to . ? . to ... what the heck is that? _? ~?); the sigils were totaly rewamped not in what they look like, but what they MEAN ...

        Nope, I would not call Perl 6 the next version of Perl. With or without the 5. I would call it a language vaguely similar, yet dangerously different. A language full of false friends and a language that went overboard with special characters. An overdesigned, overcomplicated language.

        Jenda
        Enoch was right!
        Enjoy the last years of Rome.

[reply]
        For starters, it should be (largely) backwards compatible. For instance, the majority of CPAN code (just to take an example) should run without any problems or differences.

        I'd call such a language a "next version of Perl 5", not a "next version of Perl". And that's how our points of view differ.

        Perl 6 - links to (nearly) everything that is Perl 6.
[reply]

In Section Meditations