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)
Well, as I wrote the article and I'm reasonably confident I'm not a fool, I guess I'd better respond.
Larry hasn't finished yet. There's another 30 Apocalypses due. So that means some things are conditional, and I've got to guess which way Larry is going to jump. So I do. And if I'm wrong, so what, it's still fun trying to read the tea leaves.
"as an integrated, improved replacement of the classical shell/sed/awk/grep etc. toolchain"
x t ) answers this so well:
.22
/alternate|options/ in regexes. Use gsed, awk or perl.
.45
Agreed, that's very true in some situations. I don't want to reinvent the wheel when the sed faq ( http://www.dbnet.ece.ntua.gr/~george/sed/sedfaq.t
6.5. When should I ignore sed and use Awk or Perl instead?
If you can write the same script in Awk or Perl and do it in less
time, then use Perl or Awk. There's no reason to spend an hour
writing and debugging a sed script if you can do it in Perl in 10
minutes (assuming that you know Perl already) and if the processing
time or memory use is not a factor. Don't hunt pheasants with a
if you have a shotgun at your side . . . unless you simply enjoy
the challenge!
Specifically, if you need to:
- heavily comment what your scripts do. Use GNU sed, awk, or perl.
- do case insensitive searching. Use gsed302, sedmod, awk or perl.
- count fields (words) in a line. Use awk.
- count lines in a block or objects in a file. Use awk.
- check lengths of strings or do math operations. Use awk or perl.
- handle very long lines or need very large buffers. Use gsed or perl.
- handle binary data (control characters). Use perl (binmode).
- loop through an array or list. Use awk or perl.
- test for file existence, filesize, or fileage. Use perl or shell.
- treat each paragraph as a line. Use awk.
- indicate
- use syntax like \xNN to match hex codes. Use perl.
- use (nested (regexes)) with backreferences. Use perl.
Perl lovers: I know that perl can do everything awk can do, but
please don't write me to complain. Why heft a shotgun when a
will do? As we all know, "There is more than one way to do it."
>All the things you say about Perl 6 I can say
>about Python but now rather than tomorrow
Well, that's not true. The MT support in Python is rather limited, and python's Garbage Collector is like perl5's one.
On the other hand, I am was not comparing perl to python, but perl5 to perl6. So yes, many of this thing were in python or ruby. This means to me that perl was lagging behind in some areas, and so it did need this rewrite.
I like python. I like perl too. And i will like perl6 more than perl5.
>What is it with Parrot? Why can't we stick
>to the JVM?
Oh, Parrot and JVM are rather different. Stack-based vs Register-based. Designed for static languages vs designed for Scripting languages. They are totally different in the inners, and parrot is (will be) much more suited to scripting languages.
There will be probably a JVM port of Perl though. And there is people developing tools for translating Java bytecode to Parrot bytecode and the reverse.
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.
Look at this: http://www.ebb.org/perljvm/
I find languages like C++ and Java to be less "personalized" and therefore easier to maintain.
BTW, I find VB...um...frustrating. It's amazing how much you miss things like inheritence and polymorphism ;^)
> Have *you* ever tried to write CGI in a fully
> object-oriented language?
It's nice to be able to throw all the DB access crap into a class and use it willy-nilly throughout your code...also makes it easier to reflect changes in db...same goes for connections to backend servers...etc.
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