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


in reply to Re: Perl 6 feature that scares me the most:
in thread Perl 6 feature that scares me the most:

CPAN modules that will not work with Perl 6/Parrot

I would imagine that the perl5 compatability layer will take care of the majority of pure perl modules. AFAIK XS will need a rewrite.

It doesn't really worry me. Important modules that lots of people use will get ported. Modules that I need myself I can port.

It seems that everyone is writing their very own VM these days (ex: java, .net, mono, parrot), which will (of course) run faster, better, etc than everyone elses. There is hardly a practical technical incentive (platform dependency excluded) to choose one VM over the other. Parrot will be just one in the crowd.

There are some specific reasons why JVM and .NET won't work for Perl6 (the need to support closures, continuations and polymorphic scalars).

If others choose to implement languages on top of Parrot too that's just gravy :-)

Will not appeal to VM zealots because it is too late in the game.

And this is a problem why? :-)

Will not appeal to perl programmers because it will probably be bigger, require more typing, run slower than perl 5.

Speaking personally I find the "bigger" bit appealing. The features that are being added to Perl6 are features that I miss a great deal in perl5.

It doesn't require more typing. Typing is optional for those who like it. TMTOWTDI and all that.

So far I've not seen any evidence that it will be slower. Quite the opposite.

They are not really thinking about making extending/embedding easier than XS.

Yes they are. To quote from the perl6 architecture document.

One of the major reasons to revisit Perl was to fix the mess that is XS (the way you extend Perl with C or C++ subroutines).  Perl5 has no API for extension, separate from the functions used to implement Perl, and extending Perl requires hideous amounts of work.  Dan and Larry are aiming to make C extensions as easy as they possibly can be (Brian Ingerson's excellent perl5 Inline modules give some directions for this).  Anyone who has used XS looks forward to its demise.

If you take a look around the mailing list archives you will find people are thinking about this.

Replies are listed 'Best First'.
Re: Re^2: Perl 6 feature that scares me the most:
by Anonymous Monk on May 30, 2003 at 12:17 UTC
    And this is a problem why? :-)

    Because, for example, alternatives might be preferred in real world projects. This means less perl programming for us :(

    The features that are being added to Perl6 are features that I miss a great deal in perl5.

    Maybe after I learn perl6 will miss them in perl5 too :).

    Whether they will help us write better software remains to be seen.

    So far I've not seen any evidence that it will be slower. Quite the opposite.

    So far, parrot cannot handle everything perl5 does.

    As far as typing goes, the Python authors argue that this one of the reasons for Pythons success. I tend to agree.

    If you take a look around the mailing list archives you will find people are thinking about this.

    I'm looking at the lists (actually news) quite regulary.

    The java docs state that any new JVM implementation should start with good ideea of how JNI will work. I think it's a good advice that the Parrot developers should take.

    BTW, why is perl6-porters not gatewayed to nntp.perl.org any more? The last messages date February 2001.

      The java docs state that any new JVM implementation should start with good ideea of how JNI will work. I think it's a good advice that the Parrot developers should take.
      Well, we have looked at the JNI a little, for the Java compatibility library that's being idly pondered, but...

      I think you're badly misunderstanding the advice in the docs. The JNI standard exists now and, since supporting it is required of a JVM these days, you really have to understand it, since building a JVM that can't do JNI well is somewhat counterproductive.

      Parrot, on the other hand, is starting from scratch--we're in the same position the JVM was before the JNI was created, only with the advantage of seeing what the JNI became so we can avoid the nasty bits. (As well as the nasty things Perl 5, Python, and Ruby have done) Exposing an interface is something that I'm thinking about, and it does drive some internal design. (It's a big driving reason for why we walk the system stack as part of the GC, nasty though that is)

      BTW, why is perl6-porters not gatewayed to nntp.perl.org any more? The last messages date February 2001.
      Perl6-porters is dead. All the action is on perl6-internals.
      Because, for example, alternatives might be preferred in real world projects. This means less perl programming for us :(

      True. However, it won't be any worse than the current situation and Perl6 (or indeed Perl5) cannot be implemented in a sane manner on JVM or .NET. If you want to work on those VMs you will have to choose another language anyway.

      Whether they will help us write better software remains to be seen.

      It some areas I don't think there is any doubt that it will. For example, just the addition of submethod means that a whole bunch of code-reuse problems with Perl5 OO code just disappear or become a whole lot simpler.

      So far, parrot cannot handle everything perl5 does.

      True. However, there is nothing in the design of parrot that I can see that will make it slower than the Perl5 VM - and many things that will make it faster. I would be interested in knowing what features of Parrot you think will cause speed problems. I can't see any (and the developers seem to be spending a lot of time ensuring that there won't be.)

      As far as typing goes, the Python authors argue that this one of the reasons for Pythons success. I tend to agree.

      I do as well. If given a choice between a dynamically typed languages like Python/Perl/Ruby and a staticly typed system like Java/C++ I would choose the former any day of the week.

      However, that's not the issue. Perl6 is not becoming a statically typed language. It has optional types that you can use if/when you need/want them. There are some techniques (e.g. multimethods) that you cannot have without some kind of type declarations.

      Perl6's type system gives me more expressive power, and does not take anything away from the language. I can't see this as a bad thing.

      It also might attract new people to Perl6 who are more used to coding in more strongly typed language.

      The java docs state that any new JVM implementation should start with good ideea of how JNI will work. I think it's a good advice that the Parrot developers should take.

      Why do you think they're not taking it?

      As I said, a better way of interfacing to external code is one of the points on the perl6 architecture document and there is lots of active work in exploring what this new API needs to do.

      Is it finished yet? No - but from what I can see good progress is being made.

        Perl6 is not becoming a statically typed language.

        Actually, it's even better: Perl6 will have typed data, rather than typed variable names. Given a reference to an anonymous something, you'll be able to find out what kind of thing it is by looking at the something itself, even if you don't have a variable name associated with it.

        In other words: you don't need to type things - and when you decide to do so, you don't need to cast them. It doesn't get any better.

        Even though typing and traits in general are what scares me most in Perl6.

        Makeshifts last the longest.

      As far as typing goes, the Python authors argue that this one of the reasons for Pythons success. I tend to agree.

      Python is a success?? ;)

      mhoward - at - hattmoward.org