blog post draft

gistfile1.txt

It's been quiet.  Too quiet.

Interest in Parrot has waned over the past 18 months.  The most recent flurry
of activity happened when Allison Randal brought up the fact that The Parrot
Foundation was in shambles and suggested shutting it down.  This naturally
brought up the state of Parrot itself and what the future holds for it, if
anything.  The situation is perhaps less than ideal.  The short answer is that
Parrot's immediate prospects are iffy at best, but there is at least one niche
where Parrot still has a chance to shine.

The surface problem with Parrot is that there’s a lack of people who can find
the tuits to hack on it these days.  Different people have their own analyses
as to why this is happening.  My best answer is that Parrot doesn’t have a
compelling value proposition.  Hosting every dynamic language was pretty
revolutionary around the time Parrot was started more than a decade ago.  Today
that’s no longer the case and the bigger language runtimes like the JVM, CLR
and JavaScript (not a VM but a very poplar compilation target) can run circles
around Parrot on most of the axes that matter.

Those of us who care about Parrot need to find a way to make it matter and to
do so quickly.

Rakudo is the current most complete and active language implementation that
runs on Parrot, and even it is moving toward running on many backends.
Parrot’s best bet is to focus exclusively on supporting Rakudo and give it a
reason to stick around.  If supporting all dynamic languages was ever a good
idea for Parrot, that’s no longer the case.  The reality of Parrot’s effective
niche has become much harder to ignore.  The best move is to adapt accordingly.

Parrot has been inactive (among many reasons) because its developers can see
that the goal of hosting all dynamic languages isn’t realistically attainable given Parrot's current resources.  With a new
and more tightly defined plan, Parrot has a fighting chance to find a useful
niche.

 

Parrot's new niche and reason for existence needs to be to support Rakudo and
nqp until those languages either fail, succeed, or have no further use for
Parrot.

This will be a liberating shift for Parrot.  The official policy is now “make
nqp and Rakudo better”.  Within that constraint, any change is welcome.  In a
bit more detail, the two goals by which any potential change should be judged
are:

1) Does it provide a benefit to Rakudo, especially a measurable non-theoretical
benefit?

If a change makes Rakudo happy, sold!  This includes requested features,
optimizations, bug fixes and the like.

2) Does it make Parrot’s code simpler without increasing complexity elsewhere?

Some of Parrot’s problems come from the decade of accumulated cruft.  A simpler
Parrot is more approachable and easier to maintain and debug.  Simplicity
should be pursued as long as that simplicity doesn't mean shuffling complexity
elsewhere.

That’s all there is to it.  With simple and immediate rules rather than a slow
and deliberate deprecation policy, half-done features that were kept around for
years “just in case” can safely be removed.

Another implication of all this is that our deprecation and support policy are
going away.  In fact, they’re already gone.  They were well-intentioned, but
appropriate for a project in a much more mature and stable state.  Our new
support policy is “we’ll try to fix bugs and keep nqp running”.  We’ll continue
to make monthly releases, but they will not be labelled as “supported” or
“developer” as in the past.

Observers of Parrot will note by now that this isn’t the first time that Parrot
has tried something radical.  This isn’t even the first time that I’ve tried
something radical.  It’s reasonable to ask what’s different this time that
gives us a chance for success.  The answer is that we’re no longer trying to be
all things to all languages; we’re trying to be one thing to one language
that’s already our customer.  This will still involve a ton of work, but the
scope reduction shrinks the task from Herculean to merely daunting.

So here’s where you, the reader come in.  Whether you’ve hacked on Parrot in
the past or came for the lulz and accidentally got interested, you can help.
The big goals are to make Parrot smaller and faster.  Here are a few specific
ways you can help:

Grab a clone of Parrot and nqp.  Build and install them.  Already there?
Great!  The next steps are a little harder.

Remove code paths that nqp doesn’t exercise.  This can be single if statements
or it can be whole sections of the source tree.  Tests are the same as code; if
the nqp and Rakudo’s tests don’t exercise them, out they go.  Tests exist to
increase inertia, but are only useful to the degree that they test useful
features.  When in doubt, either ask in #parrot or just rip it out and see what
happens.

Profile and optimize for nqp.  If you like C, break out valgrind, build out a
useful benchmark and see how fast you can make it run.  If you find some code
that doesn’t seem to be doing anything, you’ve just found an optimization!

Learn nqp and Perl 6.  There’s been a lack of tribal knowledge about nqp’s
inner workings ever since Parrot started distancing itself from Rakudo.  We
need to reverse that tendency so that nqp is regarded as an extension of
Parrot.

Overall, the next few months will be interesting.  I don't know if they'll
result in success for Parrot, but I'm willing to give it one more shot.