It’s 2011, and the big 3.0 release of Parrot is due out in only a few days. This does, or it should, represent something of a new era for Parrot development.

What are we going to see in 2011 with respect to Parrot? There are a handful of things each that I would like to see, and that I think we actually will see.

First, the things that I think we actually will see:

  1. Parrot is going to get smaller. By that I mean we are going to be pulling non-essential bits out of libparrot and moving them into alternate front-ends and into other ecosystem projects. Things like Parrot’s OpenGL bindings, The Parrot::Embed bindings for Perl5, and other items like the Complex (and hopefully the BigInt/BigNum) PMCs will be moving out of core and into their own new repositories. Far from being a death knell, I fully expect this move to bring new life to these bits of code. I also think we are going to see some of Parrot’s user-facing interfaces become much more lean, but functional and robust.
  2. Along a similar vein, in terms of community and leadership I expect Parrot to be making fewer promises, but to be more faithful in delivering the things we do promise. If we say it, we mean it. If we don’t believe it we won’t say it. Simple.
  3. We are going to see radical changes, in most cases radical improvements, to Parrot’s serialization system and it’s packfile types. Packfiles are going to get a shiney new API, and we are going to make them much more usable. By the end of the year I fully expect HLL compilers to be generating packfiles directly instead of generating intermediate PIR and then compiling that down to packfiles.
  4. A lot of code is going to be refactored and even rewritten to be more readable, more maintainable, and more hackable. This is going to happen across the board, and will be driven by several key developers.
  5. We are going to see a renewed interest in testing, verification, and continuous integration.

These are things that I know are going to be happening in 2011 because they are happening now and I know some trends are going to continue because the people in charge of them are going to make them happen.

What we have above are things that are going to happen, but those few things aren’t really enough to fill an entire year’s worth of development from our team. There are a number of things that I am hopeful will happen, and I am confident that we have the manpower and motivation to deliver if we try:

  1. A new GC. In the category of eternal vaporware we have two favorite candidates: Duke Nukem Forever and Parrot’s GC. I think 2011 can be the year for both of them. We want it enough, from there it’s just a simple matter of writing some code.
  2. IMCC will be out. With the packfile improvements I mentioned above, I think its just a matter of time before we finally rip IMCC out of libparrot and treat it as being an optional add-on for bootstrapping purposes only. I think NQP and PCT will continue to be written in PIR. I think we will see a lot more development of libraries and things in NQP and Winxed because of this shift.
  3. Lorito. I don’t think we are going to see the whole-hog conversion of Parrot to Lorito, but we are going to see some definite movement in that direction. I think it’s entirely reasonable, if packfiles improve and IMCC is extracted from libparrot, that we will see PIR ops rewritten as Lorito ops and at least a rudimentary JIT provided for it. I don’t think we will see things like core PMC types rewritten in Lorito, nor many (if any) parts of Parrot’s internals.
  4. A new Object Model. Even if we want to steal the new object model from Rakudo, there’s still some work to do to evaluate it and make sure it suits our needs, and also some design work necessary to figure out how it fits in with the rest of our system. This is not to mention the implementation work that still needs to be done on it, and then the work required to get it merged into our system. But, I think it’s very possible we get the new MOP merged into Parrot, and I think everybody will win a little bit because of it.

There’s a list of general things that I think Parrot will do and will probably do in 2011. Here now is a short lightning list of things that I want to do personally, in Parrot and in my related ecosystem projects:

  1. I want to add new “generator” types to Parrot-Linear-Algebra (PLA). These new types will be a matrix of subroutines that we can extract values from for particular inputs. Think about the difference in linear algebra between matrix A and matrix A(t).
  2. I want to add LAPACK bindings for PLA, so we can do non-trivial operations like finding matrix inverses, eigenvalues and eigenvectors, performing transformations, etc. This is where the real power of this project will become apparent.
  3. I want to get working on a new JavaScript implementation for Parrot.
  4. I want to expand ParrotSharp and make it a much fuller-featured interface to Parrot. I want people to be able to use Parrot from C# in a very natural way. Then, when the binding are mature enough, I want to expand this to cover HLLs as well so you can embed any HLL that runs on Parrot into C# seamlessly.
  5. I want to rewrite Parrot::Embed to use the new embedding API. Along the way I think Parrot::Embed will grow significantly in capability, because the new API is much more capable than the old one.
  6. I want to cleanup and refactor several subsystems in Parrot including the PCC system and Exceptions.
  7. I want to start working on a comprehensive testing library. This will probably be based largely on the working bits of the Kakapo test framework, though it will probably become larger than that.
  8. I would like to start a comprehensive rewrite of Matrixy. All the necessary infrastructural parts are in place now to support the function call semantics of the language. I would like, as much as possible, to write it in something better than PIR, and eventually migrate it so it is completely written in Matrixy itself except for the parser (which will probably still be written in NQP). With PLA providing the lion’s share of data type semantics and primitive operations, I think we can write most builtin library functions directly in Matrixy.

In terms of my product management role, I’m focusing my efforts now on testing the hell out of Parrot in anticipation of the 3.0 release. Thereafter, I want to test, expand, and use the embedding API a lot, and review the old embedding API and the extending API.

In terms of the Parrot Foundation Board of Directors, I think we have a lot of work to do this year, which I will talk about later.

2011 is going to be a very busy and eventful year, and I’m excited to see what all we can accomplish.