chromatic

Aaaaaand without the technical or political fallout of "let's make a VM for ALL the dynamic languages!"

I remember Larry being really keen on that idea. The quote went something like "If everyone complains that CPAN gives Perl an unfair advantage, let's give everyone access to CPAN."

http://www.perl.com/pub/2003/07/16/soto2003.html

Given the reception to the past year's worth of discussion around "Get ready to party", it seems irresponsible to me to continue with these semantic distinctions, as they're lost on the intended audience.

This historical revisionism continues to be tiresome.

Some people will tell you to trust them. I, on the other hand, base my expectations on the history of the project and the actions of the people involved. I don't believe you can turn 15 years of disappointment and underperforming into something usable based on an arbitrary deadline enforced by yet another marketing announcement.

I've asked you multiple times in multiple places not to speak for me. Your assertions here are nonsense.

Please cease and desist.

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).

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.

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.

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...

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.

After almost 15 years in development, surely that lack should indicate something.

Sure, but in the world where I write software, my teams need code with a working ecosystem of documentation, tooling, libraries, trained or trainable developers, deployment and monitoring, and stability. I can get that from Go, Scala, and Clojure (haven't looked at Elixir).

Looking at P6's laundry list of features may be interesting from a language geek perspective, but it doesn't help me solve real problems for the foreseeable future, and there are plenty of interesting languages further ahead in the queue of things to learn.

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.

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.

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.

You say "It's better to build a specialized VM", I say "Emscripten, Clojure, Niecza, Truffle, and Jakudo."

... then don't write it in a language with negligible documentation, negligible tooling, barely-there library support, nearly zero users, and a roadmap based on the promise that, after almost fifteen years of working on the "It'll be ready when it's ready!" principle, sufficient volunteer mindset will change to "Let's ship a production-ready release to meet a hard deadline!"

I have strong opinions that people in situations similar to mine had no intent of contributing to "stagnation" or "death". Quite the opposite.

When the process of change and renewal is shut down or nobody contributes to it, everyone starts wandering off and the project dies.

Certainly. I also think that a project which actively chases away contributors ought to account for that eventually.

No. I have my doubts about yet another announcement and nothing I've seen since I stopped contributing suggests that the project will provide anything I need that I can't get better elsewhere.

http://use.perl.org/use.perl.org/articled5d3.html?sid=00/07/...

That's not entirely fair. Some of us doubters spent a lot of time, energy, and resources trying to help it move forward before deciding it wasn't worth it.

Not everyone thinks that ticking off a list of feature checkboxes satisfies the most important adoption criteria.

I'm not sure how an appeal to PHP as lowest-common-denominator of language sanity argues against understanding the return values of functions you call.

Baloney.

Yes, that's common. List processing via variadic arity functions is an explicit feature of Perl.

I've fixed that bug in code as far back as 2000. There've been discussions on that anti-pattern on PerlMonks for at least a decade.