Chromatic: Goodnight, Perl6
Chromatic: Goodnight, Perl6
Posted Feb 12, 2013 19:33 UTC (Tue) by martin.langhoff (guest, #61417)Parent article: Chromatic: Goodnight, Parrot
Other posters have said, fittingly, "second system effect". There are reasonable reasons for Perl6 to be late, but it is a little bit more than late and the developers seem to have forgotten about deliverying a single easy-to-deploy runtime.
Articles about Perl6 development talk about devs wanting to experiment with this and that, not about being desperate to bring something finished to actual users. This is beyond disappointing.
In the meantime, I have used PHP (I hold my nose, but it ate Perl's lunch over mod_perl+embperl, and webapps like Moodle are solid products). I use Python extensively at OLPC (you couldn't build Sugar in Perl). Ruby is a good thing when I want to feel I am using something Perl6-ish. Yet I go back to Python (whitespace grammar is not for me, can I add curly brackets here?).
I have built programs big and small in Perl5. Country-wide DNS backends for DNS registrars. National election backends for voter rolls and vote tallies. Piles of glue between systems that didn't like each other. Heard of the slightly insane git-cvsserver? It is Perl5!
Will Perl6 be a real usable widely deployed runtime I can build stuff upon? Will {yum,apt-get} install perl6 result in a predictable installed runtime, with known features and quirks, with a decent dependency chain? Perl5 is part of Debian's base IIRC.
My 8-ball says "not likely".
Maybe let Perl6 (and its dev team) continue to run as a research project, and land some useful bits into a Perl7 that is real and runnable?
~m
(Log in to post comments)
Chromatic: Goodnight, Perl6
Posted Feb 12, 2013 20:40 UTC (Tue) by rodgerd (guest, #58896) [Link]
Chromatic: Goodnight, Perl6
Posted Feb 12, 2013 21:04 UTC (Tue) by martin.langhoff (guest, #61417) [Link]
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.
Chromatic: Goodnight, Perl6
Posted Feb 13, 2013 8:47 UTC (Wed) by alankila (guest, #47141) [Link]
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.
I do struggle to see what role Perl has left, if the low end was eaten by PHP and the higher end by other languages. Is it just a bash replacement? Can it compete against any one of the established players? Will it be better than python or ruby for web development? In fact, can any one of our scripting languages survive the onslaught of Javascript as it is fueled by the ever-present web?
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.
Chromatic: Goodnight, Perl6
Posted Feb 13, 2013 23:39 UTC (Wed) by raiph (guest, #89283) [Link]
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.
Or is the problem that you're thinking that Perl 6 will only run on the JVM? It's just another backend. pmurias is working on a JavaScript backend, swarley a Go one, fijal recommends RPython, etc.
Chromatic: Goodnight, Perl6
Posted Feb 14, 2013 11:47 UTC (Thu) by alankila (guest, #47141) [Link]
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.
Chromatic: Goodnight, Perl6
Posted Feb 15, 2013 0:23 UTC (Fri) by raiph (guest, #89283) [Link]
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.
Chromatic: Goodnight, Perl6
Posted Feb 13, 2013 6:13 UTC (Wed) by raiph (guest, #89283) [Link]
I empathize with your sadness in respect to hopes from back then. I, for one, hoped Perl 6 would refresh the Perl toolchain and brand before these became more than the pressing problems I felt they were even in 1999. But it already feels years too late for that.
I can't but help think your feelings of sadness are coloring your perspective on the state of Perl 6 right now.
Too little, too late, irrelevant, whatever, the Perl 6 project is in the best shape it's ever been.
> developers seem to have forgotten about deliverying a single easy-to-deploy runtime.
I assure you they haven't. If this is a reference to the JVM port, I hear what you mean while also disagreeing. If not, what prompts your comment?
> Articles about Perl6 development talk about devs wanting to experiment with this and that, not about being desperate to bring something finished to actual users. This is beyond disappointing.
I do not accept that you really want them to post about how desperate they feel. Illegitimi non carborundum applies.
> In the meantime, I have used PHP (I hold my nose, but it ate Perl's lunch over mod_perl+embperl, and webapps like Moodle are solid products). I use Python extensively at OLPC (you couldn't build Sugar in Perl).
Perl 6 has a well designed internals architecture and the build and packaging options are improving. I expect Perl 6 to become competitive in places beyond the reach of Perl 5.
> I have built programs big and small in Perl5. Country-wide DNS backends for DNS registrars. National election backends for voter rolls and vote tallies. Piles of glue between systems that didn't like each other.
The intent is for Perl 6 to eventually compete in all three scenarios (critical, large, and glue).
> Will Perl6 be a real usable widely deployed runtime I can build stuff upon? Will {yum,apt-get} install perl6 result in a predictable installed runtime, with known features and quirks, with a decent dependency chain?
Without doubt, eventually. This year will see it speed up, run on the JVM, and continue evolution much as before. Maybe Larry will publish his upcoming Perl 6 book.
> Maybe let Perl6 (and its dev team) continue to run as a research project, and land some useful bits into a Perl7 that is real and runnable?
Er, let the team continue? It's a self-organizing volunteer effort. They are unstoppable.
Land useful bits in a Perl 5 descendant? Sure! Perl 6 is all Artistic License (and GPL too I think). Folk are free and indeed welcome to steal or backport as per Moose and cousins.
Chromatic: Goodnight, Perl6
Posted Feb 13, 2013 13:53 UTC (Wed) by martin.langhoff (guest, #61417) [Link]
I truly don't want to be trolling you or anyone here. But some essential principles apply, IMHO.
The team is all volunteer, and that warrants a lot of respect. However, if the team doesn't have as its top goal providing a rock solid runtime that is competitive... then they won't. Filling in Perl5/Python shoes is incredibly hard, and it won't happen while meandering through tasks that volunteers find interesting.
Just like completing a release isn't something that happens "naturally", regardless of the paid or volunteer status of programmers. You need leaders to set clear goals, make hard tradeoffs on the project direction and seduce people to follow them even though the tasks might be boring.
You need release managers to be tough at times and reject fixes, push hard for the release criteria (calendar-based, quality-based, whatever).
My comment about "devs not being desperate to complete a product" speaks about that. Current Perl6 devs seem, by all reports, to be having an interesting time. So perhaps Perl6 is a fun research and (personal) development project. That is swell, and in some cases it can overlap with delivering a performing, working product (see git, for example).
Sometimes it doesn't. Lack of clarity and a strong release ten years into it tell me Perl6 is right now an example of the "doesn't" case.
You say that Perl6 will be competitive, and able to fill in Perl5 shoes. IMHO, the current course won't lead there. Targetting the JVM means Perl6 won't be part of any distro's "base" install, as Perl5 is now on Debian, or Python is on Fedora/RH. It means apt-get install perl6 will show a dep chain that will scare sysadmins. Means you'll start arguing about which JVM to install (with the package manager, with people), and which webserver JVM setup too.
This in turn means that the quirks of Perl6 runtime will be all over the place -- when someone reports a bug, instead of just asking "which perl6 release?", you'll be asking "what JVM? version? using tomcat or mod_java or... ?". It is a horrible place to be, so far up the stack.
And it means that you'll be at most as fast/efficient/performant as Java. That's spectacularly uninteresting to me.
Perl5 set the bar so high it is hard to be competitive in that space. My worry here is not that the Perl6 team carps on how hard it is to get so good. It is that the Perl6 team doesn't seem to be interested in achieving the key goals of what Perl5 achieved.
Perhaps I am a grumpy old man. Don't let the bastards get to you. But also don't forget to decide and tell the world whether your top goal is a fun research project or a useful product. Key distinction between the top goal and secondary goal(s).
(Here, ISTR Larry or Damian saying that Perl6 development was optimized for the fun and enjoyment of the developers. If that is true, then that management style has a risk of forgetting to deliver something of relevance to the outside world...)
Chromatic: Goodnight, Perl6
Posted Feb 14, 2013 3:06 UTC (Thu) by raiph (guest, #89283) [Link]
Aiui you think the only worthwhile Perl 6 deliverable is one that bundles a front and back end in a form that competes with the current perl. I get that and will return to that but first I need to clear up some confusion.
For most of a decade there have been two projects that are distinct though with overlapping concerns. A front end language project (Perl 6) and a back end VM project (Parrot). A few folk are involved with both, but for the most part they are/were separate cultures.
Rakudo is a leading Perl 6 compiler. It has always used Parrot as its VM. After the Rakudo team concluded in 2009 that the Parrot project might not deliver what Rakudo needs in a reasonable timeframe, the Rakudo team began preparing to be able to port to other backends. (Aiui this pissed off chromatic.) By late 2012 the Rakudo team were ready to port to other backends. In November 2012 jnthn began a port to the JVM as a first step in targeting multiple backends. He seems fairly confident he'll have something solid to show at yapcna this June.
In the meantime, the Parrot project kept rolling along. For example, they landed a IO refactor (with regressions) late last year and got a form of threads working a few weeks ago that jnthn says isn't what Rakudo needs. Then a few days ago the Parrot project declared itself stalled and possibly dead. The Rakudo team may need to update their strategy for how they deliver with a solid runtime, but they've had less than a week to react to the news.
Then chromatic writes a post "Goodnight, Parrot" (even though several credible folk have said they want to continue Parrot). Finally, dskoll here at LWN adds insult to injury by renaming this thread "Goodnight, Perl6".
> You need leaders to set clear goals, make hard tradeoffs on the project direction and seduce people to follow them even though the tasks might be boring.
A good description of Larry's brilliant leadership. 12 years in and the productivity is astonishing. Yes Perl 6 was incredibly ambitious but they've basically pulled it off and the result is extraordinary.
> So perhaps Perl6 is a fun research and (personal) development project.
I do see a lot of folk enjoying themselves, learning as they go. I also see a lot of folk doing boring stuff, year in, year out. I see TimToady, jnthn, Moritz, masak, japhb and dozens of others writing amazingly high quality code amazingly quickly. And folk like swarley who's gotten amazingly far in doing a Go port in the less than 2 weeks or so since s/he appeared on the scene.
> (Here, ISTR Larry or Damian saying that Perl6 development was optimized for the fun and enjoyment of the developers. If that is true, then that management style has a risk of forgetting to deliver something of relevance to the outside world...)
Audrey Tang coined the phrase "optimized for fun". In her opinion it was important to do whatever it takes to make devs *productive*. It includes nurturing newbies, creating LHF files (lists of "low hanging fruit"), being liberal with commit bits, encouraging bursts of silliness, whatever gets hackers moving fast and being supremely productive. It works.
Chromatic: Goodnight, Perl6
Posted Feb 14, 2013 3:42 UTC (Thu) by martin.langhoff (guest, #61417) [Link]
Pretty much, yes. Everything else is details I should not know unless I plan to hack on Perl6. Or do advanced debugging/diagnostics, I guess.
All the parrot/rakudo/VMs and blah is internals. Good for an in-depth LWN article, but not for when people like me ask about using Perl6 in production.
It is ok to have fun, while being productive. However, your definition of productive does not seem to include delivering a "product" in the form of a /usr/bin/perl6 in a reasonable timeframe.
This all probably sounds more bitter than I intend it.
So I will say: I like the Perl6 syntax and some of its abstraction ideas. Maybe one day Perl6 will be a language I can use for widely-deployed programs. Current directions don't seem promising to me... but I have been wrong before, and will be more than glad if I am wrong on this one :-)
Chromatic: Goodnight, Perl6
Posted Feb 14, 2013 16:55 UTC (Thu) by chromatic (guest, #26207) [Link]
Rakudo's spent half of its life thinking about switching away from the one platform where it runs at all to another platform which may or may not even work out. I wanted to deploy Perl 6 to actual paying customers.
I'm sure the developers are having fun, but from the potential user point of view, it's a waste of my time to worry about when the software will actually reach a deployable state. The project's history suggests that's not a priority.