All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

In case my parrot comment didn't stab you enough:-)A way of properly doing objects might actually speed things up a lot. If you could have a class with defined attributes so that when you access those attributes you don't have to go through a hash (or array even) you can get some decent performance improvements for object heavy systems (as fields.pm hints at).

Admittedly this doesn't affect boring benchmark applications, but it does help people whose day job it is building large scale apps with perl, and it

This sounds like a lot of work. If someone want to volunteer to write such a thing, then great, patches welcome - although they should be warned that there can be no guarantee in advance that code will be accepted.

But I don't think that any of the current maintainers have a sufficient itch to scratch personally, so I cannot see such a project happening "by itself".

A right. I didn't pick up on this as an approach to solving the "make perl faster". I was seeing the requestor's desire more to be to make their existing perl code faster (at least, without substantial re-writes). And this seems more like a way to make new code faster.

In turn, such an approach might have the same "speedup" as pseudo-hashes. Offhand I don't know the URL to the analysis, but someone [Schwern, IIRC] demonstrated that the real 15% speedup that pseudo-hashes provided for use fields over regula

Thinking of Perl 6 being ready in 3 years is dreaming. Sorry, but someone has to say it.Classes need not be accessed through the hash API. I think of a class (or object) as another xV type, rather than another extension on SVs. But I know zip about the perl core - I'm purely speculating based on the little work I have done in XS.

I remember Schwern's analysis, but I also remember it being rather flawed because there's lots in later perls that slow it down (most notably unicode) that weren't taken into consid

I am sorry, but v6.pm [cpan.org] works today; the underlying support modules (Moose, Pugs::Compiler::Rule, ModulE::Compile) are useful in production; Perl 6 is just another CPAN module, and we are working to make it useful for production in this Christmas.

But you can use Moose or any other support modules without the v6.pm syntax sugar; if so, then it's ready even sooner.

We were talking about different things here (perl 6 being a fully finished and working perl 6 on its own interpreter). But saying v6.pm is working today is a long way off saying it's a finished perl 6. The perl 6 schedules have been way off from the start and I think my expectation of us being ready to transition people to perl 6 in 3 years is probably about right given what I know of the current development stage (unless there will be a Blue Peter "and here's one I made earlier" phase;-)).In no way do I m

Frankly I think the Perl 6 on its own interpreter idea doesn't work at all.

It's true that Perl 6 will run on multiple interpreters (including Parrot, JavaScript and more), but it's the perl5 interpreter that will get us to an incrementally-deployed production soonest.

That is, the transition to Perl 6 will be no different to, say, the transition to DateTime.pm; modules start using it, or part of it, when it makes sense, but it doesn't need to be an all-of-nothing process.:-)