[kbenson]

That's... an odd way to start a response in which you are very obviously being uncharitable yourself in assessing the motivations and actions of real people. What's more, you are doing it as a non sequitur.

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?

[chromatic]

After the first Rakudo Star release, I personally volunteered to spend my Parrot time fixing bugs which affected Rakudo, improving the performance of Rakudo, and adding features for Rakudo, in that order. I offered several suggestions (including native registers, better profiling, object system improvements) and was repeatedly told not to work on them. I will say this, though: there was no friction to working on the profiling system (though it went unused). This happened to other people as well.

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.

[kbenson]

Ah, we've had this discussion before. No need to rehash it here, I think I was clear before, and I don't see you changing your stance.

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.

[chromatic]

I believe some of the "historical baggage" lumped on Parrot and, by extension, its developers came from deliberate design and project decisions of the Rakudo developers. I'm happy to lay out what I believe the Parrot team did wrong (and have done so in detail elsewhere), but I've long grown tired of the historical rewriting that goes on in the P6 world.

[pwr22]

Could you link to your elsewhere. I'm keen to learn more of the P6 history, good and bad

[chromatic]

I wrote my experiences with Parrot in specific:

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

[kbenson]

I assume your second whiteknight link was meant to be this[1]. It's interesting comparing his view of Parrot with yours. He may share some feeling with you about Perl 6, but it appears his conclusion about why Parrot didn't work out is quite different. It appears he goes out of his way to explain that Perl 6 did what it had to to get past Parrot's failings:

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

[pwr22]

Thanks for sharing. I never knew you were so involved back then or that people were being treated that way