I'll let whiteknight, chromatic and others debate the question of Parrot's maturity -- or whether 'maturity' even makes sense in this context. Let me mention some ideas that came up during my conversation with Andrew last Saturday which he didn't dwell on in his blog post.

Incomplete Design
Whether or not Parrot is mature, I think most Parrot developers will agree that its design is incomplete. Our design is kept in Parrot Design Documents which appear in our repository in docs/pdds and docs/pdds/draft. 11 of our PDDs are sufficiently incomplete that they have never made it out of draft stage.

But Andrew suggested that quite a few of the 'official' PDDs are actually out-of-date and/or incomplete. They no longer reflect the current Parrot implementation. Andrew suggested that this poses problems both for Parrot developers -- they don't provide a guide for implementing as yet unimplemented Parrot subsystems -- and for Parrot users -- they don't provide a stable, mature API on which outside developers can build projects.

Andrew went on to wonder, Are the PDDs capable of being forward-facing documents which drive the implementation rather than reflecting (inadequately) what we have already done? Are the PDDs worth the time and effort needed to maintain them?

Neither Andrew nor I pretend to have answers to these questions. But these questions forced me to realize: I have never read all the PDDs. And I'm willing to bet that you, the reader of this post, haven't read them either!

So, I know that I'm going to have to start reading the PDDs and coming to my own judgment about their adequacy. I know I'll be discussing them with project architect Allison Randal. And before long I will probably be suggesting that we have a design committee to conduct a thorough study of our PDDs and to overhaul them where needed.

If it helps at all, pdd31_hll.pod is intended to be forward looking, describing an API for how things should work as opposed to describing existing practice. It's intended to replace pdd31_hll_interop.pod, which was never accepted as being the right way to go. I think that all that remains for pdd31_hll.pod to become "official" is for someone to declare it so.

Regardless, pdd31_hll_interop.pod should be deleted, which I've now done in r49249.