|
in reply to Perl 6 feature that scares me the most:
These don't scare but bother me:
1. CPAN modules that will not work with Perl 6/Parrot.
2. 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.
3. Will not appeal to VM zealots because it is too late in the game.
4. Will not appeal to perl programmers because it will probably be bigger, require more typing, run slower than perl 5.
5. They are not really thinking about making extending/embedding easier than XS.
Then again ... I might be completly wrong.
|
Re^2: Perl 6 feature that scares me the most:
by adrianh (Chancellor) on May 30, 2003 at 11:28 UTC
|
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.
| [reply] |
|
|
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.
| [reply] |
|
|
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.
| [reply] |
|
|
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.
| [reply]
[d/l] |
|
|
|
|
|
|
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
| [reply] |
Re: Re: Perl 6 feature that scares me the most:
by broquaint (Abbot) on May 30, 2003 at 11:33 UTC
|
| [reply] |
|
|
While this is not likely to be true at launch, within a year or so Parrot should be happy to load Perl5 code therefore making the majority (if not the entirety, depending on how XS dependant modules are handled) of CPAN available to Perl6.
Implementing that is definitely not trivial. I think it is more likely that they will end up providing *some* support for XS modules, with the recommendation that we use the new system. Some will not be able to rely upon this emulation layer and it will not move to perl6 until they are really motivated. Continuations and closures alone, won't cut it. If it were so, all those proprietary, never seen by CPAN but running in production environments XS modules, were written in Lisp/Scheme by now
| [reply] |
|
|
You're right, a not insignificant chunk of the XS code won't be able to be build under parrot, no matter what we do. We haven't (yet) sat down and gone through the perl 5 API to see what can and can't be thunked to work on Parrot.
Some of it, certainly, can be done with simple macros. Stuff like SvIV or newSViv is a no-brainer, and we will do those. Things like the array and hash access are trickier, but we can probably manage those as well.
Where it becomes less trivial is with things like SAVETMPS and magic, and I'm not sure what we're going to be able to do for that. When we figure it out we may well put together a consistent transition API for both perl 5 and parrot, so people who are interested in moving over can migrate to the transition API as they get time and interest, so their code will require even fewer changes to build on Parrot...
| [reply]
[d/l]
[select] |
|
|
|
|
Re^2: Perl 6 feature that scares me the most: (performance goal)
by Aristotle (Chancellor) on May 30, 2003 at 19:10 UTC
|
| [reply] |
|
|
