I'm a Perl 6 core developer (compiler, test suite, docs, design documents, infrastructure). Ask me anything :-)
I've been a professional Perl developer for a long time, and I've followed Perl 6 since the first announcements. There is some impressive and really interesting work going on there, but from my perspective it seems to be a new language rather than a new version of Perl. I fully support the development of Perl 6, but I really wish the name would change to something that doesn't involve Perl.
It seems like the usage of the name "Perl" has actually done a fair amount of damage to the Perl 5 language, and the Perl community. Non-Perl programmers don't understand what is happening. To them, Perl 6 is just the next version of Perl, and the long wait for Perl 6 is a sign of problems within the Perl community. To many of them when Perl 6 comes out it will be the obvious choice to use for new projects, since the name implies it is the new version, even though the reality is that Perl 5 will likely be the correct choice for a large number of new projects for many years to come.
Perl has become a punching bag by the uninformed who speak about it as a dying, irrelevant, read-only language. Perl 6 carrying the Perl name has helped reinforce those views, allowing them to incorrectly speak of the lack of new versions, the future versions breaking backwards compatibility, and many of the changes being a strong admission that something was very wrong with Perl 5. When Perl 6 is released there will be a lot of confusion and the common belief will become that Perl 5 is even more irrelevant.
So, why not stop using the name "Perl" and call it something different? Wouldn't it be better for everyone if Perl 6 was regarded as a new and separate language?
It's both, really. If you use it (and after a while of getting used it), it just feels like perl.
> I fully support the development of Perl 6, but I really wish the name would change to something that doesn't involve Perl.
Well, in retrospect, it might have been a good idea to name it something else entirely. But that's too late now, and nobody has been able to come up with a good new name anyway. And the "Perl" brand is still very strong, so we are loath to give it up.
Finally, Perl 5 has many unsolved problems that will hinder its evolution in the upcoming decades. Once Perl 6 has become as fast and mature as Perl 5 is now, we want to provide the future that's closed to Perl 5.
Come now; that was the excuse given five and ten years ago.
the "Perl" brand is still very strong
Some would argue (including the post to which you're replying) that the brand is much less so, thanks to the very line of thinking you're defending.
Perl 6 did not "kill" the Perl brand, the state of Perl circa-2000 "killed" the Perl brand. All the issues @perlgeek just noted, those "killed" the Perl brand. The fact that Python was simply a better option for 99% of the projects that were started around that time (even if half or more went with PHP instead) "killed" the Perl brand.
If Perl 5 as a programming language is so susceptible to "oh but this new version makes it seem that there are deficiencies in the current version", could it be because there are deficiencies in Perl 5? If hiding that fact from others is so important to the "brand of Perl", what does that actually imply?
Please stop pretending that starting a project to build a better Perl somehow killed the camel. It's obvious that this is not true even from a Perl 5 usage standpoint, but it's even more absurd from the standpoint of next year, or the year after...
It's easy to look at the rate of change and the timeline of releases of Perl after 2000. It's easy for me to argue that the announcement of P6 (and the promise that 6.0 would be a successor to 5.10 or 5.12) took a lot of momentum from working on Perl.
I suspect, but can't prove without a time machine and a multiverse, that if the "they're sister languages" line of thinking had been in place from the start, Perl could have avoided its lost decade (5.6.0 to 5.10.1).
I can agree that it had an influence, but I'm sick of the Perl 5 perspectives that a) the language is flawless and only an idiot would choose something else, b) Perl 6 pointed to flaws which don't exist because hand-waving, Rule A, etc.
Perl 5 has fundamental problems. At first Perl 6 was an attempt to solve those problems without a complete compatability break. That proved impossible, so the scope expanded to be a new Perl.
"But it's painting a bad picture of Perl 5!"
Perl 5 painted it's own picture, I'm sorry to say. The toxicity of p5p, the constant "this language is fine why are you making a new one", the over-confidence that Perl 5 is a pinnacle of how you can design a Perl language... these are Perl 5 things, and they belong to Perl 5. Yet I rarely see Perl 5 programmers owning to these facts.
It's just tired. You yourself did a great job in breathing new life into Perl 5, as part of the Modern Perl movement, which takes as its starting point that Perl 5 allows some seriously flawed programming. Techniques and ideas borrowing from Perl 6 are used to make life easier in Perl 5, developed during the "lost decade".
So, I'm sticking to my position that this whole line of thinking is just tired. For outsiders, Perl 5 was a non-starter because of all the flaws with the language, not because another version was in the pipeline that promised to fix those flaws.
FWIW, I program in Perl 5 every day, and I really enjoy the language.
That is great for you as a Perl 6 developer that gets extra attention for the new language by leveraging the Perl brand, but it is absolutely awful for people in the Perl 5 community. Perl 6 gets free press, but Perl 5 gets mocked and public opinion turns even further against it.
> Finally, Perl 5 has many unsolved problems that will hinder its evolution in the upcoming decades. Once Perl 6 has become as fast and mature as Perl 5 is now, we want to provide the future that's closed to Perl 5.
I know Perl 5 isn't perfect, but no languages are. You refer to "unsolved problems" and while I'm sure there are from your perspective, from mine as someone who writes large Perl 5 applications, there are no great issues. I can do everything I need to already, and I can do it really well. I don't need Perl 6, and I won't even consider it until it has a proven track record.
For most people to make the switch, Perl 6 won't need to prove itself as being just better than Perl 5, but it will need to prove itself as the right choice in the full market of languages out there. For at least a few years, and likely many more, Perl 5 will still be the right choice for a lot of work, and Perl 6 will do nothing but confuse people and cause public opinion about Perl and with it Perl 5's market share to sink even further.
First of all, the press for Perl 6 isn't free at all. We get press because we do cool stuff with programming languages. So do the Rust and Nim communities, for example. Please don't downplay our effort. And the comments are full of prejudice against Perl 6 that is rooted in its Perl 5 legacy; so it's not "free" in a second dimension.
Second, in my experience, Perl 6 is only a small part of the ridicule. Mostly it's about Perl being aweful to read (for which Perl 6 bears no blame at all), lousy code quality, unfamiliar looks through sigils, and so on.
> You refer to "unsolved problems" and while I'm sure there are from your perspective, from mine as someone who writes large Perl 5 applications, there are no great issues
Have you ever asked yourself if this is actually true? Would your work be much easier if you had sane threading in some scenarios? Subroutine and method signatures? never had to deal with the bloat that comes from different libraries using different object systems?
I also happen to work on big Perl 5 code bases for money, and with the knowledge of what's possible in a perlish language, I regularly identify pain points that in the end are rooted in missing or deficient language features.
I am looking forward to the future of Perl 6. I really do like some of the things I've seen going on there, and it is fairly likely that in the future I will be happily writing Perl 6 code on some projects. With that said, I am very concerned about how Perl 6 carrying the Perl name will impact Perl 5, but that is separate from my excitement that a new more modern language will be carrying forward some of the Perl styles.
In short, I do appreciate Perl 6 and I don't mean to downplay anything going on there, but my concern is about what it all means for Perl 5.
I'm wondering which unsolved problems you're referring to in particular. (Surely Perl 5 is not the only language which might happen on problems in upcoming decades, and just as surely Perl 6 isn't immune to them.)
* way too many globals in the language, making any sane threading support very hard
* OO (or lack thereof) in core. Yes, there are nice OO modules out there (Moose/Moo), but it's easy to land in a situation where you have several OO modules in the same project. Also, many built-ins still only deal in strings (example: error messages), not objects.
* lack of proper subroutine signatures. The ones in 5.20 are a step in the right direction, but still far away from anything that the competing languages offer
* high exposure of internals to the XS (C) API make it nearly impossible to do substantial rewrites of the internals
* The regex syntax has been extended way beyond its limits of sane extensibility. Yes, Perl 5 now has named captures, re-usable(ish) subrules and all that neat stuff, but the syntax is so arcane that I have to look it up every single time I use it.
* Poor type system. Perl 5's types (scalar, list, hash, code, type glob) simply aren't enough in world where you have to distinguish binary data and Unicode strings, for example. Or subroutines and methods.
The weakness of Parrot VM was it's ambition - to be an efficient VM for all dynamic languages. This may have seemed possible in the past but recent work (i.e. v8, luajit2, etc) has invalidated that; it's much better (and much easier) to build a VM for a specific target than for all possible targets, as there are simply fewer points where you need abstraction. (For instance, NaN is false in javascript boolean context, but not in Perl6). More importantly, MoarVM has been designed and developed by a small set of developers applying all the lessons learned from parrot, while parrot was in many ways an experiment by committee.
You say "It's better to build a specialized VM", I say "Emscripten, Clojure, Niecza, Truffle, and Jakudo."
And as a counter-example, luajit2 was built by one man (mostly) over the course of a few years, and runs very efficiently indeed, in no small part due to the lua-specific choices that have been made.
So what I'm trying to say is that there is a second tradeoff, somewhere between programmer efficiency, runtime efficiency, and running time, and that MoarVM is making a better tradeoff for perl6 than parrot is.
Ha! My experience with Rakudo was "you go to the developer resources you have, tell them not to change anything, then tell them you're going to throw away their work in favor of something you haven't written yet" and then complain when they leave.
Mostly that MoarVM developers could learn from all of Parrot's successes and mistakes, while not carrying any of the historical baggage. That means cleaner design, less memory footprint, faster execution.
> and why were we stuck at Parrot for so long before giving it up?
Rakudo works on Parrot. Why drop support for it?
Once you frame the question that way, the answer becomes obvious: because there hasn't been big changes to the code generation yet that would make continued parrot support painful. Once we reach that point, the situation will be reconsidered.
I think you're being uncharitable. It's clear enough in retrospect that plenty of Rakudo developers wanted to get rid of Parrot years ago, but wanted to couch their "Let's burn it all down and start over" in much more careful terms which allowed them to take advantage of Parrot's stability when marketing P6 to the outside world while using Parrot's concomitant lack of development to prove that they'd made the right choice.
I think you are being uncharitable. It's clear now as it has always been to me that the Rakudo developers wanted a working, fast VM that provides the needed features. Since Parrot couldn't deliver this, it was just naturally to look for alternatives.
Also, it makes me sad that you argue a lot about Rakudo's and Parrot's past, but seem to neglect their current state or the future. Could it be that you care more about how Parrot will be remembered, then about how it does today?
I'm really not sure what you're trying to say here. How is a later project being able to look at what came before and try to determine what decisions were good and bad of the prior project and trying to avoid them being uncharitable, and what does that have to do with whether some people wanted something different long ago?
I've documented this at length elsewhere.
Those specific features we were told explicitly not to work on were on the top of the list of "Reasons Rakudo Must Abandon Parrot". I find that disingenuous, as if Parrot had been set up for failure.
Perhaps I should apply Hanlon's Razor here, but that feels even less charitable.
I still don't see what place it has in this thread. It's irrelevant to the fact that a project could learn from all of it's predecessor's successes and mistakes, while not carrying any of the historical baggage. You have a point you want to make, I get that, but if you feel to need to inject it into something at best tangentially related, at least lay the foundation so it makes sense when people read it.
http://www.modernperlbooks.com/mt/2013/02/goodnight-parrot.h...
I did not write but agree with this view of the Parrot Foundation:
http://whiteknight.github.io/2015/01/14/parrotfoundation.htm...
Similarly, this retrospective from another ex-Parrot developer has similar feelings about the P6 language:
http://whiteknight.github.io/2015/01/14/parrotfoundation.htm...
I personally wrote several parts of "Theme, Pragmatics, and Purpose in Programming Language Implementation":
http://outspeaking.com/words-of-technology/theme-pragmatics-...
... and I had several discussions which led to the writing of "Why Perl Didn't Win" and did some minor editing to it recently:
http://outspeaking.com/words-of-technology/why-perl-didnt-wi...
The P6 folks were developing their own bindings which used the (much nicer) 6model and the (much nicer) P6 native bindings instead. After a while I had to ask myself why I was fighting in the weeds so much, when the P6 people were rising above the problems of Parrot and doing things better? If my writing these things wasn’t helping anybody, why bother with it?
Notice that the P6 folks were having their biggest successes when they bypassed Parrot, which isn’t exactly a roadmap for synergy and mutual success.
He goes on to say he doesn't really like Perl 6, and doesn't believe in it's direction or that it can achieve it's goals. That's fine. Nobody has to like everything.
I have to say I agree with his assessment that Parrot's goals have largely been met by multiple other projects at this point. This post has convinced me even more that not relying on Parrot was the right choice, which is sad because I was a big fan for many years. Parrot was a train wreck. Some people think Perl 6 was or still is a train wreck. But that wreck has been making progress, and may actually arrive at the station. Can the same be said of Parrot? Can you really lay all that blame, or even a majority of it on Perl 6? If people wanted to work on Parrot, they would.
1: http://whiteknight.github.io/2015/01/15/parrottheend.html
What whiteknight didn't say was he'd spent over a year volunteering to port 6model to Parrot and had been repeatedly rebuffed. (He's a much nicer person than I am.) You can find that in the weekly parrotsketch logs too.
Look at the Ohloh logs of contributor activity. You can see them drop right after Rakudo said they were going to abandon the NQP Parrot was using. That's what finally drove people away.
Any post-hoc justification you hear about Rakudo dropping support for Parrot because almost everyone left is silliness. Why work on something when you've been all but told is going to be unused, no matter what you do? Especially when you've been told not to fix the things you wanted to fix.
Looking back on it, it seems obvious they were both doomed, as long as they were locked in that spiral of needing the other to advance to be able to move forward, and not being able to really drive the other project themselves. Think the only way out was to either come together again, not in tighter integration, but as a single project, or to split apart and fulfill their own needs. I think joining was actually the riskier option, there were many people in Parrot with no interest in Perl 6 beyond it's ability to drive Parrot. whitenight is frank and unapologetic in this, as he well should be.
So what if Perl 6 people stalled on giving the okay for Parrot to migrate some implementation details to Parrot? They were both immature projects, feeling their way through how to proceed. There are countless possible reasons for that, but a big one might be that they were unsure of the continued viability of that implementation, and didn't want to waste weeks of some Parrot dev's time to turn around a week after they finished and say "sorry 'bout that, but 6model really isn't going to work and we're going to scrap it for something else."
Then Perl 6 decides to hedge it's bets on Parrot. Sooner than later, because it was always the idea Perl 6 would run on multiple back-ends. Parrot as it existed could have survived that, if it hadn't already been floundering for a long time. They had recently decided to refocus on Perl 6, after realizing that the whole "VM for everything dynamic" thing wasn't really working, at least not as a main dev goal, and they were desperate for a fix. So what would that have done? Make a situation whose viability could best be described as "ridiculously horrible" all better? The best that could be hoped for there was "still pretty fucking bad."
Whiteknight lays out a pretty compelling case that Parrot was slowly imploding for a very long time. I trust his assessment, as he's one of the few people I recall landing major branches in Parrot, and fairly consistently. I understand that you put a lot of time into Parrot, and also Perl 6. Years. But that doesn't change the fact that many of Parrot's devs decided it wasn't worth continuing. Again, I think whiteknight gives a good explanation; the goals of the project had be mainly met already by outside sources.
Was the situation bad? Undoubtedly, or we wouldn't be having this exchange, but I like to think if you asked people involved from both sides candidly whether or not they thought some blame lied with themselves, they would own up to that.
> Any post-hoc justification you hear about Rakudo dropping support for Parrot because almost everyone left is silliness.
Rakudo hasn't dropped support for Parrot. Nobody has said that it will. Parrot isn't deal
> Why work on something when you've been all but told is going to be unused, no matter what you do? Especially when you've been told not to fix the things you wanted to fix.
Because, as should be obvious to anyone following along, Parrot usually did what it wanted anyway, as evidenced by the planned major shift towards treating Perl 6 as a first class citizen again. You can't shift back to Perl 6 without having shifted away. The stories don't line up. You can't be a controlling prima donna and be sidelined, because being sidelined means a lack of control.
You want to know what this looked like from the outside? Parrot was going downhill for a long time, and when they tried to re-hitch their horse the Perl 6, it was too little too late.
You can reply if you like, and I'll be happy to discuss this with you more here, in this thread, but I think I'm done engaging you on this issue here in the future or elsewhere for the foreseeable future (I imagine you're fine with that). I've spent a lot of time over the years here on this issue with you because you've garnered quite a bit of respect from me due to your prior works, but the way in which you see the people involved in this situation and how you assess their motivations is fundamentally foreign to me. I'm not sure anything I've ever said has actually ever made you think about a single point the issue in a different way than you had before, and if I'm not even having that effect, then I'm not really doing anything worthwhile in these conversations.
My problem is that this gets argued both ways. This thread is far too nested anyhow, but here's my complaint.
Yes, Parrot and Rakudo drifted apart. There were poor decisions all around. Patrick and Allison and I in particular talked extensively about how to improve things.
We decided this: I personally volunteered to fix any bug, patch any memory leak, add any feature that Rakudo wanted. I spent a lot of time doing that. Several other people also volunteered to add any feature Rakudo wanted.
Time and time again, we went to the Rakudo developers with proposals and they said "No" or "Not yet". Thus my work was mostly fixing bugs and making minor performance improvements. (The major improvements were in that list. So were major revisions of most parts of Parrot to make it smaller, simpler, and faster.)
Then the NQP rewrite came. Parrot faced using a deprecated NQP for its compiler tools, adopting a deprecated NQP so it would keep working, or rewriting all of its compiler tools.
At that point, I decided that there was no point in working on Parrot and left.
I'll take responsibility for everything I did wrong (or for not doing things I should have done). I don't accept the current party line from Rakudo, however. To wit, "Parrot of course had to be abandoned, because it wasn't meeting Rakudo's needs."
Parrot may or may never have succeeded. Rakudo may or may not have succeeded on Parrot. We'll never know. Yet the claim that Parrot developers weren't interested in making it work with Rakudo is nonsense. In my experience, it was the other way around.
Getting the right trade-offs there was no easy task.
Another challenge was how to make the type system and built-in types so that stuff works intuitively for a Perl programmer, and still has sane rules in the type system.
Finally a thing that's surprisingly tricky is precompilation. You need to serialize types and objects, and then another compilation unit comes, and needs to modify something, so it claims ownership over a piece of serialized data or code. There are way too many nasty corner cases in that area.
Or in other words what is still left to do that is not just routine work, but actually might not be possible (or not possible in the timeframe)?
Or in even more informal language, what's the holdup? :)
In general, I think there's huge latent demand for a relatively fast, "next-gen" scripting language, as even Python is showing its age in terms of the programming styles it doesn't support, and has no plans to.
Will it really be released by the end of this year? Obviously the history of this project induces a healthy bit of skepticism. My two cents would be that the dev team should just release it next week and fix the inevitable warts gradually.
On a related note, should I, as someone who does not know Perl, bother learning Perl 6 yet? Or is it likely to change a lot before release?
I don't think so. Everything I've read in recent years has indicated that the grammar is stable, which implies that the operators and planned feature set are also stable.
If you want to melt your brain, you can take a look at STD.pm6, the official grammar for Perl 6, which is also written in Perl 6:
https://github.com/perl6/std/blob/master/STD.pm6
Recent changes seem to be very minor.
Barring that, there are three major technical things we want to tackle before the release: native, shaped arrays (compact storage of arrays/matrices of machine-sized types), the Great List Refactoring (GLR; mostly about speeding up list iteration and making things more consistent), and some Unicode-related tasks.
Any of those might prove more difficult than expected. I personally see the biggest risk in the list refactoring, because lists are rather central to the language as a whole.
I think that the initial port of Rakudo to JVM was done by jnthn single-handedly. I don't know how PyPy compares with JVM though.
At any rate I think that an implementation of 6model (the basis for Perl6 objects) on PyPy would likely be too slow to really make it worth the effort. ( If you really want to try I'm sure there are People who would help you )
There are currently 3 backends for the Rakudo implementation of Perl6: Parrot, JVM, and Moar.
The fastest one currently is the one designed to meet the needs of Rakudo: MoarVM. (in many benchmarks) It of course makes sense that a VM designed for Perl6 would work better for Perl6.
Some of things it does:
* type specialization. It looks at repeated executions of a piece of code, and if the type of a variable or parameter is stable, it assumes it'll be always that way, and specializes the code for that (for example, always picks a method from the same class). And of course it inserts a guard clause to ensure that if the type should change, it takes the slow (but correct) path
* inlining
* container removal. In Perl 6, things generally become mutable by being inside a container (think pointer), and if the specializer finds cases where that's not needed, it generates better code for them
* reachability analysis and elimination of allocations are being worked on, iirc.
0: MSI installers for MoarVM and Parrot, I assume JVM bytecode it includes is in there as it stated it ships with "experimental JVM support."
1: http://rakudo.org/downloads/star/
Here is the current feature test statuses of the Perl 6 compilers/runtimes: http://perl6.org/compilers/features
Note that the Rakudo-MoarVM runtime is the closest to feature complete, with Rakudo-JVM close behind.
In short, you can expect you'll get whichever runtime you install, and if that runtime is ready for production you can expect that Perl 6 will work on that runtime. MoarVM will likely be the first to be ready for production.
You may have other reasons for choosing a runtime; if you have a Java/Clojure/Scala shop and wanted a powerful scripting language to integrate into your systems, the JVM runtime might be just the thing. If you wanted the fastest Perl 6 for standalone Perl 6 applications, MoarVM will likely be it (I think, I haven't looked at benchmarks, just guessing). The FFI may be easier to work with in MoarVM, if you need C or other compiled external libraries...but maybe not. I'm not at all familiar with how that works in JVM runtimes, but it seems like it would be more convoluted.
http://design.perl6.org/S12.html#Multiple_constraints
It concludes with:
> As a first approximation for 6.0.0, subsets of enums are static, and other subsets are dynamic. We may refine this in subsequent versions of Perl.