Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Chromatic: Goodnight, Perl6
Posted Feb 12, 2013 21:04 UTC (Tue) by martin.langhoff (subscriber, #61417)
I dislike Python's whitespace, but it is so far better in quality and completeness, compared to Ruby. Compare and contrast things like subprocess.Popen(). Python has all the variants, quirks and options you need in real life; just like Perl5 has.
I have not revisited Ruby in depth for a while now. I keep hearing of performance, scalability and stability issues with various Ruby-based tools (Puppet, RoR) so it's hard for me to find clear examples that Ruby has matured into the kind of rock-solid engines Perl5 or Python 2.x are.
Such maturity is truly useful... and dead boring. It's more fun for developers to keep finding new cool things to experiment with, instead of delivering something the world can rely on.
Posted Feb 13, 2013 8:47 UTC (Wed) by alankila (subscriber, #47141)
Some of the blame lands on parrot, some on rakudo. I think chromatic once said that rakudo's generated PIR is so register heavy that it will bring any register allocator to its knees. But, this being undated information it may now be obsolete.
If Perl6 is released as a JVM language, it will go straight into java culture that expects interoperability with all the java libraries there are, and goes against those alternative languages that have found some real-world use: rhino, clojure, jython, scala, gosu... Perhaps the performance would be acceptable, but I would find it unlikely for Perl to retain its role as unix system glue if the future holds no native implementation.
Posted Feb 13, 2013 23:39 UTC (Wed) by raiph (guest, #89283)
I was a Mozilla contributor in the dark days of doom before Firefox shipped so I'm familiar with such suspicions. :)
> Some simple kick-the-tire microbenchmarks still indicate >10x slower performance than perl5
I'd say 10x is generous even given the >. Many folk would say >100x slower. It was *another* 100x or so slower 2 years ago. 100x was a good rule of thumb a few months ago. SSSSLLLLOOOWWW!
The Perl 6 team has been disciplined in sticking to their overall strategy: get it working, make sure it works right, then speed it up. They are just beginning serious speed up work. In the last few months they have begun regularly landing changes that significantly, sometimes dramatically, speed it up or shrink memory usage.
> releasing it as a very slow and bloated language would be just embarrassing.
Heh. They've already released it. There have been over 60 monthly releases. There are Perl 6 apps that have been running for years. (Slowly.)
> But on the longer term, it can't be kept in this "still in development" limbo forever, either.
Right. I've watched what Larry Wall says since the 90s. He has specifically and repeatedly refused to set a release date for Perl 6 for over a decade. And then, last year, he said it was time to "productize" it over the next "year or two" and a few weeks ago he revealed he's planning to publish his first Perl 6 book in the next year or so. I think that will likely mark 6.0.0.
> I think chromatic once said that rakudo's generated PIR is so register heavy that it will bring any register allocator to its knees. But, this being undated information it may now be obsolete.
I recall seeing someone else mention that recently. But my googles are only turning up this thread. Aiui chromatic hasn't been working on Parrot for at least a couple of years.
> I do struggle to see what role Perl has left
Language development is over! C# to see out the end of the world! :P
I recall folk suggesting lisp had no role left in the 80s.
> I would find it unlikely for Perl to retain its role as unix system glue if the future holds no native implementation.
Do you mean no VM? Perl 5 has a VM.
Posted Feb 14, 2013 11:47 UTC (Thu) by alankila (subscriber, #47141)
As to the question about role, people with Unix heritage are likely to be quite resistant to anything that needs a JVM to run, so that makes Perl 6 unusable for traditional sysadmin tasks where Perl 5 was clear upgrade from bash, awk, sed, etc. I personally appreciate the idea of using JVM, because one really good thing about java is that there's a ton of good libraries written for this language, so that would immediately seed a pretty big "JPAN" for Perl 6. However, in order to *really* benefit from that, the usage of those classes should be as transparent and easy as humanly possible. And of course it requires an IDE that is capable of handling Perl6 while completing java types and method arguments... With 6, is it still true that only perl can parse Perl?
You see, I've griped before about Perl 6's reprogrammable syntax, or about overly complex syntaxes in general. It makes it hard for tools to work out what to autocomplete, where syntax errors are if the expression is not valid, etc. Of course, with reprogrammable syntax I guess any hope for parsing anything is lost unless your parser happens to be a Perl 6 compiler.
Posted Feb 15, 2013 0:23 UTC (Fri) by raiph (guest, #89283)
Perl 6 does not need a JVM to run.
I agree that many who might accept a technically adequate Rakudo/Parrot might balk at a technically adequate Rakudo/JVM that was (perceived to be) proprietary.
> I personally appreciate the idea of using JVM
There will likely soon be a Rakudo/JVM.
> one really good thing about java is that there's a ton of good libraries written for this language, so that would immediately seed a pretty big "JPAN" for Perl 6. However, in order to *really* benefit from that, the usage of those classes should be as transparent and easy as humanly possible.
Rakudo/JVM is supposed to just be a stepping stone to A) completion of the Perl 6 spec (in particular concurrency) and B) porting to other backends. It's not necessarily interesting to jnthn (the guy doing the port) beyond these short term roles. But you're right that it may get more interesting than that. We'll see.
> With 6, is it still true that only perl can parse Perl?
From a theoretical perspective, the situation is basically the same. (Perl 6 has gone further down this road, with features like lisp-style macros that mean that Perl 6, just like Perl 5, just like lisps, just like haskell with Template Haskell, theoretically isn't parseable without a full language implementation.)
From a practical perspective, the situation is much better. One shift is what Larry Wall has phrased as "only Perl 6 can parse Perl 6". Note the extra capital 'P', reflecting the fact that Perl 6 is a specification not an implementation which makes a big practical difference. Another is that Perl 6 is a much more regular language than Perl 5.
Also see http://stackoverflow.com/questions/5916194/can-only-perl6...
> Of course, with reprogrammable syntax I guess any hope for parsing anything is lost unless your parser happens to be a Perl 6 compiler.
Heh. You've let theory overrun your sense of pragmatics.
(Quick test. Perl 6 contains a function is-prime that will occasionally return the wrong answer. Does that make it useless?)
Rob Hoelzro has written a syntax highlighter in python. As far as I know it works without errors on everything that's been thrown at it.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds