Slashdot Mirror
Perl6 for Mortals
horos1 writes: "Hey all, I just ran across an article over at O'Reilly - Perl 6: Not Just For Damians which covers a lot of the negative commentary posted by slashdot on perl6 'featureitis'. Very interesting read, and IMO makes a hell of a lot of sense."
One of the coolest things about the Perl 6 development is that it leads to lots of improvements available right here, right now with Perl 5.
Attribute for example have been incorporated in perl 5.7.2, and a whole unch of new modules by Damian and others use them in tons of creative ways.
I am not sure this would have been done without the Perl 6 process. It forced the whole community to re-examine the language, take a step back and think of new ways to improve it. This would have been much more difficult if we had not had license to do it freely under the Perl 6 RFC process. This is the kind of things that keep a community alive and creative.
And BTW Perl 6 will still let you write quick'n dirty one-liners, and the first goal of the design of the interpretor is Speed (Larry mentionned "and it'has to be fast" about 25 times in 60 seconds in his last State of the Onion0.
Look, that's why there's rules, understand? So that you think before you break 'em. (Terry Pratchett)
It's a functional programming thing, named for Haskell Curry. The basic idea is that if you have a function with two arguments, f, and you call it passing in only one argument with value x, you get back another function f' such that f'(y) is equivalent to f(x,y). If you call f with a different value of x, then you get back a different f'.
This sort of thing is, if not exactly commonplace, a feature of the likes of Haskell, Lisp, Scheme, Perl 5 (if you did the hard work by hand), and various other programming languages that support closures. The perl 6 syntax is simply about making currying easier to use.
For raw for loops, java is currently faster than Perl5; especially with a JIT. Perl5's biggest strength is in it's complex op-codes (grep, map, reg-ex, etc). This has the effect of JIT optimizing various high-use functions, but leaves basic flow-control to the mercy of performance.
Perl6 keeps the same complex and optimized functions of perl5 (though extracting them to external libraries to make the core clean), but utilizes the optimized byte-code and jit-able features of a java VM. Thereby getting the best of both worlds. In java, a reg-ex engine is most likely written in pure java. In perlX, reg-ex is optimized-c. Since their basic flow-control is now similar they should be comparible baseline.. Thus perl6 can only be faster than java (with equivalent code maturity). There is, however one additional MAJOR difference. Non jitted java is stack based, while perl6 is register-set based (I'm currently pushing Knuth's VM-register set for highly efficient subroutine calls).
Perl6 will NOT be an OO language, dispite many beliefs to the contrary. perl5 programs should be executable AS IS, and perl6 programs will look remarkably similar to those of perl5. There will be a higher performance OO support structure in perl6 than was in perl5 (which used recursive symbolic lookups on each method invocation), but this is completely optional, just as in perl5.
By the way, preliminary benchmarks show that non-JIT compilations of perl6 are faster than both perl5 AND java. We do have a JIT, but it's too rough to trust. But for our current trite benchmark, we're 50% of the performance of even the java JIT (and we avoid the overhead of a per-execution jit-compile).
So along with other posts, I believe that every element of your complaint has now been addressed.
perl6 focuses on speed, and compatability. While trying to reconsile convolution and complexity associated with perl5. Heck we're even supposed to be fully MT capable. Thus in all respects we should be able to compete directly against java and C#(including type-safety). So what exactly is your beef again?
-Michael
-Michael