Discovering the minimum viable utility of a programming language is a difficult exercise. Certainly in 1994 few people would have expected that the obvious successor to Perl 4 would eventually need multi-megabytes of extensions to add a full object system rivaling CLOS plus Smalltalk, an asynchronous event system, a high-powered object-relational mapper with pervasive laziness, and an abstraction mechanism for HTTP? Yet that's the state of the art in Perl in 2011, and we're all the better for it.

If you read carefully between the lines of my criticism of the current state of every Perl 6 implementation I've used as well as what the people who claim that "Perl 6 is usable right now" write, you may find that we approach the problems we're trying to solve from two different angles. We even agree on one of those vectors.

When someone like Moritz Lenz writes "You can use Rakudo or Niecza for real programs now!", I think it's fair to rephrase that as "Any of the leading Perl 6 implementations implements enough structure of a complete and useful programming language that you can implement your own code."

I can agree with this sentiment. I even go a step further; I don't mean to water down his assertion or to put words in his mouth. If you analyze Perl 6 right now in terms of the Perl 6 RFCs, it's clear that Perl 6 even as currently implemented has advantages over Perl 5 when you compare features on a matrix.

(I've since come to believe that you're dooming yourself to potential technical excellence and popular obscurity by focusing on features instead of Getting Stuff Done.)

To rephrase, Perl 6 may certainly be a better programming language than Perl 5 in that Perl 6 includes features Perl 5 should have had years ago. If design patterns are signposts of missing language features, Perl 6 is the Christopher Alexander of programming.

If that's sufficient for your purposes, great. (You still have to deal with performance issues and regressions, and licensing concerns with the Mono dependency of Niecza (Niecza fans, be honest. How is my business supposed to pay Novell anymore for indemnification per their patent licensing arrangement with Microsoft—you remember, the Microsoft that sued TomTom for patent infringement?), and the schism between Parrot and Rakudo on the Rakudo side, as well as the history of Rakudo undergoing lengthy and repeated and compatibility-busting rewrites of core components, but after eleven and a half years, you ought to know you're an early adopter by now. (Rakudo fans, be honest. How long after nom became the main development branch did it take to get all of the Panda modules passing tests again? Oh, they're still not? QED.)

The other vector from which to approach problem solving in Perl says something like "You know, if I'm already leaning heavily on the CPAN to download Plack and an IMAP server and an OAuth implementation and AnyEvent and several testing distributions, Moose really isn't that big a deal anymore." In other words, maybe it is rather silly that in 2011 Perl 5 still doesn't have much of an object system in the core and that it could really use real function signatures, but the Perl community is awfully good at making the important stuff on the CPAN just work, and Perl 5 without the CPAN is pretty anemic for solving big important problems anyway, so grab perlbrew and fire up cpanm and after you've finished your cup of tea, you're all set anyway.

The Python community has dealt with the same schism between Python 2.x and Python 3.x, where Python 3 is arguably a better language, but only superficial polyglot magpies and Usenet personas care solely and forever about language qua language, and everyone else eventually needs to use a library or a framework or a tool written by someone else.

I thought I wanted a better language to solve my problems, but as it turns out, right now I can't have both, and I want to solve my problems more than I want a better language. A good enough language which lets me solve my problems is better than a great language in which I'm practically unproductive.

This is one of the few times when I agree both with the backwards compatibility people and Python programmers. Mark your calendar.

After a very pleasant conversation with the criminally underrated VM Brasseur at this year's Open Source Bridge Conference, I decided to improve my copywriting skills. Certainly I've been accused of perpetuating content-free, slick marketing on the Perl world before, so why not undercut that libel a little bit by figuring out how to communicate better with real users and real customers?

This lead me to several books, chief among them the worth-ten-times-its-price The Copywriters Handbook.

The high point of the book so far—a technique I've used on three projects in the past week to great results—is to distinguish between technical features and customer benefits.

In other words, while experienced Perl masters might say "Perl 5 is great because you have access to the CPAN", that's a feature. The benefit is that "80% of most programs has already been written". While it's technically true that the Modern Perl book covers primarily Perl 5.12 and 5.14, the benefit is that "the book demonstrates the current ways to write great code". While the as-yet unlaunched value analysis site a couple of us are launching for small investors has the technical feature "updates analysis after market close every day", the benefit to customers is "gives you the best advice possible whenever you check it".

Listing features in terms of features (for the sake of their own obvious technical good, of course) and not expressing them in terms of what they mean for users is where a lot of my previous evangelism for Perl 6 went wrong, of course. It's easy to list off multiple dispatch and continuation passing and gradual typing as if you were competing for a Fields medal in multiparadigm integration, but when I code, mostly I just want the code to work.

On the other side, I suspect that a lot of the reason that experienced Perl 5 programmers don't really care when non-Perlers sneer "Does it have function signatures yet?" is that (even though it'd be grand not to have to write my ($blah, $blahblah, $blahblahblah) = @_; all the time) it doesn't really matter. It's a minor inconvenience compared to the ability to get stuff done.

Even so, it's important to acknowledge which parts of Perl get the benefits-not-features idea right. For example, consider the module POD skeleton format, where a one-line NAME explains what the module does, then a SYNOPSIS shows an example of working code, and this all happens before a description and detailed technical walkthrough of how to use it. When this format works, it works well.

My experience so far has been that the exercise of comparing features to benefits takes some time, but yields great results. Try it yourself; it's easy. Grab a piece of paper and make two lists. On the left side, write all of the distinct technical features you consider worth mentioning. When you finish, write on the right side a benefit from the customer or user point of view corresponding to that technical feature. Sometimes there's overlap, and that's okay.

When you finish, you should be able to do three things. First, you should be able to identify distinct themes in your benefits. Sometimes these will surprise you, and that's good. Second, you should be able to rank the benefits for each particular audience by priority. If you have multiple audiences, so much the better—you've unlocked an extra-credit achievement. Finally, you should be able to write better prose explaining why your product or project matters to each audience by arranging the benefits in a logical order. (Your skill as a writer matters a lot here, but even if you're still learning how to write effective persuasive prose, the act of thinking in terms of customer benefit is already a huge improvement.)

Now imagine if the Perl world could practice and polish this skill in our technical communications. Sure, it's marketing and obviously evil, but don't we pride ourselves on helping people do the things they want to do?

Because Rails was a sufficiently easier onramp for simple database-backed web programming than Java and sufficiently cleaner than PHP.

I'll let you ponder that for a second, until you're no longer composing angry responses to this article. When you've convinced yourself that that's indeed correct, the next paragraph is one blank line away.

I've oversimplified, of course. Luke Kanies (creator of puppet) told me directly that he wrote Puppet in Ruby because he wanted to learn Ruby. (I won't claim that Adam Jacob told me anything similar, but I can believe it.)

If Rails was Ruby's killer application in 2005 and 2006, Rails brought new attention to Ruby, and that new attention brought Ruby to new places. The Internet will certainly debate whether Rails is Ruby's primary driver right now, and the Internet incessantly debates whether Ruby or Python or Perl or shell or whatever is better or more popular or more fashionable for non-Rails tasks such as administration or automation, but in 2011 your eyebrows don't automatically raise themselves when you run across an automation tool written in Ruby as they would in 2005 or 2004 or 2001.

The sudden popularity of Rails brought a second wave of popularity for Ruby for non-Rails.

I suspect you don't see the same popularity for command-line PHP because no one adopts PHP because it's better than something else. People adopt PHP because it's easier than everything else.

(I also don't know how to characterize Node.js, except that Netscape tried it back in the '90s and it didn't work, and it reminds me of the AOLServer dilemma, except that Node.js has a little more shiny for some reason. Maybe a JIT and something resembling a working module system will do that for you. Then again, Perl 5's second wave came because system administrators already had a pretty decent language for system administration, and isn't it easier to write web programs in this than in shell or C? (I own a book about web programming with the Korn shell. I am not making this up.))

Again, I'm thinking about Perl 6 and writing about something else, just to focus your attention on the principle, rather than the thing itself.

Conventional thinking during Perl 6's beginning claimed that Perl 6 would be the natural evolution of Perl 5, just as Perl 5 was the natural evolution of Perl 4. The RFC process demonstrates this—we want a better object system! Better threading! Improvements here! Improvements there! More consistency! Fewer edge cases!

Even the early talk of Parrot and Ponie bore this out. At some point, Perl 5.12 was to run in Parrot, and the two languages would merge together.

Some people are happy that didn't happen. I admit I don't understand their view, but I'm honest enough to admit that they may have a point. I want a language with a great object system, with malleable control flow, with macros, with native grammars, with optional typing, with an optimizing compiler, with better garbage collection, with a great native interface, with serializable bytecode, with proper language introspection, and with finally and ultimately function signatures, and, yes, access to the CPAN.

I don't have 14 years of legacy code to worry about, in part because I have App::perlbrew, but in part because I run my code on the latest stable releases of Perl 5 as they come out.

Maybe Perl 5 will gradually become Perl 6 over the next decade or so and solve that problem, but I have to write and deploy code on October 14, 2011, so that doesn't really help right now.

Maybe I'm wrong, but I think we can safely discount Perl 6 as becoming popular by being a better Perl 5. Some people might use it that way, and that's great for them, but the use cases for which that's possible are very limited right now, and there's no obvious critical mass with which to improve the situation. That's the source of great disappointment to me, but it is what it is.

If you're looking for the pragmatism of Perl without some of the language flaws of Perl 5 but with access to the CPAN, Perl 6 isn't it right now. That's what I wanted, and that's exactly what I don't have, and that's disappointing.

There is another path.

I first used Ruby in late 2000 or early 2001. Dave Thomas told me about this Rails thing in August 2004. Rails took off in January 2005. While I don't believe that the web will eat all software ("The script on this page is taking a long time to recompile your IDE. Would you like to stop it or continue waiting?), Rails did offer those poor plebes in the J2EE and PHP worlds something far better than what they had.

As long as people are willing to invest their time and energy in developing Perl 6—with the full knowledge that it's very unlikely to be the natural successor to Perl 5 in Perl 5's niche without dramatic changes in the ecosystem—there is a chance that Perl 6 can stand out in front of the next revolution (or the next, or the one after that, or...) and be sufficiently better at something that the ancillary effect is popularity for other tasks.

Thing is, you can't easily predict what that will be or when and especially why. You can't optimize for that based on user feedback.

Even so, I trust Larry's instincts and good taste. I believe him when he says he believes it's possible to avoid Worse is Better and, for once, get a Better is Better cycle.

Yeah, I'm frustrated and disappointed that eight and a half years of working on Perl 6 and Parrot haven't produced software that I can use productively. (Sunk costs. What can you do?) Sure, they've produced dramatic improvements in Perl 5—improvements so fundamental that we use them every day and can barely remember the world without them—but they haven't produced the kinds of revolutionary improvements the language needed in 2000.

Yet I can still write great software in Perl 5, and I haven't come across anything better in gestalt.

I hate the phrase "Perl 6 is just a research project for Perl 5", because it's silly and wrong. (If it were true, Perl 5 would do a much better job of actually borrowing features from Perl 6, rather than surface syntactic polish applied over rickety and fractured semantics). Yet I think the best way to explain what Perl 6 is, as it stands today, is as a revolution in search of a cause.

It's a good language, even great in a lot of ways. I look forward to using it, even though I'm not going to find the problem for which Perl 6 is the world-moving fulcrum. Hats off to the unreasonable people who do.

Eric Ries's the Lean Startup contains a great deal of wisdom (and his Build chapter is the best non-code metaphor for test-driven design that I have encountered). In particular, he argues that the only way to figure out what customers are willing to pay for is to try to sell them something. The best predictor of why people will give you money is what people give you money for.

Yet you're here to read about Perl and programming.

My rant a couple of months ago about Why My Side Project Doesn't Use Perl 6 came from deep frustration. After eleven years of development and more than a year after the long-awaited Rakudo Star ("finally ready for early adopters!") release, it was incredibly frustrating to discover that, even as someone with commit access to the entire Rakudo stack from specs to tests to Parrot to NQP to PCT to Rakudo itself, the whole thing just wasn't ready for me to use even in a simple side project.

The biggest users of Perl 6 (via Rakudo) code right now are, as far as I can tell, Rakudo itself (via a stripped-down bootstrapping mechanism), a single blog written in Perl 6, and Rosetta Code chrestomathy examples.

Yet I'm not here to bury Perl 6.

I've spent some time writing JavaScript, and I can't understand why people say there's a nice language in there despite its flaws. (In my mind, it's mostly decent, despite its flaws.) I suppose that's like saying "Wow, Python supports functional programming!" if you learned Java because Scheme was too scary or "Ruby is basically Smalltalk!" if everything you know about object systems comes from realizing that PHP continues to get it wrong.

I've been thinking about how, if Dart is not the language of the future, what the language of the future might be, and what Larry says about evolution versus revolution.

Arc turned out not to be the language of the future either.

Gradual improvement is well and good, and it's starting to serve Perl 5 pretty well. The ability to shed cruft and mistakes and poor designs holding back future improvements (a real metamodel! slimmer memory footprint! JIT! safe exceptions! function signatures! multiple dispatch! safe sandboxing! cheaper and easier parallelism! implementations on other backends!) is crucial.

Feedback makes that happen.

Sure, you can predict that a project which relentlessly focuses on one and only one hot thing (Write a blog in 15 minutes! Manipulate DOM elements on the client! Deploy a dynamic web page just as easily as writing HTML!) will have a success, but real revolutionary success comes from making a new niche, like web development in 1994.

As much as I'd like to argue that you can iterate your way to a revolution through carefully gathering and considering real user feedback, I don't know that that's the case.

I worry that once you release a programming language with minimum viable utility, you ossify early decisions of design and implementation such that you can't quite yank the floorboards out from underneath any users you have, lest they stop being users and stop providing feedback.

Somehow you have to balance the desire to preserve an existing community with the need to attract new members to the community, and that may be the hardest problem in programming language development.

If you read Dan's Parrot post-mortem, you see those two tensions. Parrot's two biggest technical failings from the start were writing the wrong code and keeping it around. The revolution of Pugs wasn't that Haskell is magic or that all Perl needs is the superhuman effort of a superhero (though Audrey certainly gave it her best shot), but that there is no substitute for working code.

Parrot doomed itself for a decade because there was no serious working Perl 6 implementation for years. (There were three half-hearted attempts, each a rewrite of the previous.) Parrot lumbered along implementing things it thought Perl 6 might probably need without getting real working feedback by actually running Perl 6 code. (Dan's been out of Parrot longer than he was in Parrot, and some of that wrong code is still around, because you can't yank the foundation out from under people's houses without some structure and warning and planning.)

Yet I'm not here to praise or bury Parrot either.

If I'm right that normal people adopt languages to get stuff done, you have to take a pragmatic approach. Make something radically better at getting something revolutionary done, and you have a chance.

(PHP is radically better at making simple web pages than just about anything else, even though the language itself is just about the worst thing imaginable. Similarly, Java is radically better than C++ because of garbage collection and a break from the PDP-8 type system of C, and also it was cheaper than Smalltalk, at least until Oracle bolts a coin slot onto the JVM.)

In conclusion, I don't know.

On paper, Perl 6 is a nicer Perl than Perl 5.

In practice, none of its implementations reach the Minimal Viable Utility stage for me, a fairly normal and fairly positive early adopter. I don't know if that's good or bad for Perl 6.

It's good in the sense that it gives Perl 6 freedom to experiment to find its revolution. It increases the technical possibility that it won't fall into the "Wow, that's all Python 3000?" or "Arc? Scheme with some renamed builtins?" or "PHP 5 is the new PHP 6" or "That's all the better they could do with Go?" or "17,000 lines to write 'Hello, world!' in Dart, and they misunderstand OO so badly that they think Java interfaces are a good idea?" trap.

It's bad in the sense that I'm not sure that any of the big three Perl 6 users right now are representative of the kind of revolution Perl 6 needs—plus after eight years of trying to get something useful shipped, it's hard to work up the motivation to donate even more time and effort toward that always nebulous someday.

Sure, Pugs demonstrated that writing tests for the specifications was incredibly valuable. By no means should anyone diminish that.

Sure, Rakudo demonstrated that a serious implementation of Perl 6 on Parrot helped focus both projects.

Yet ultimately, both Parrot 1.0 and Rakudo Star were more fizzle than sizzle, and I think that's because neither one rose to the level where normal people (for however you want to characterize the kind of people you'd consider normal users) could do useful things.

I know, I know it's really difficult to start a revolution, especially when you don't know where it will end up, but very especially when you don't know what it will be. I know you want to give yourself all sorts of escape hatches and valves to help guide your evolution into a revolution....

... but at some point, I have to get work done, and if the shortest distance between here and there is using a lesser tool and if I'm not sacrificing too much future to do it, I have to hold back a tear and wish that Perl 5 had native method signatures or multiple dispatch or malleable control flow with continuations or macros.

(What about Niecza? I really shouldn't have to explain this, but IRC commentary on how I'm a bad person cannot seem to get this right. In mathematical terms, the set of things which are not promissory estoppel contains the opinions of everyone who isn't legal counsel or a director at Microsoft opinion about how it's safe for my business to use Mono. See also Microsoft Sues TomTom. If you live in a country without the threat of software patents, or if your livelihood otherwise can't be threatened by the possibility of a lawsuit against your use of a project in a way a known patent aggressor with patents on fundamental technologies you use and threatening indemnification agreements with now-defunct licensees doesn't like, good for you. We take your well-intentioned legal advice under advisement.)

class IceCreamSundae;

method add_toppings(Array @toppings)
{
    ...
}

Ignore class and method. Concentrate on Array. What does that mean?

You can easily assume that this method adds zero or more toppings to an ice cream sundae. Again though, what does that mean?

Does the method access the Array as a queue? As a stack? As a linked list? As a double-ended queue? With standard iteration? With indexed iteration? Is it destructive? Does it hold references to the elements of the array, thus increasing their lifespan with regard to garbage collection?

Sure, you can make cheap and easy type checking work in this case (it's a big patch in Perl 5, but it's not an impossible patch), but what does this code mean?

If we're going to use languages where we don't have to worry about the precise layout of our data structures in memory (because C has the type system of PDP-8 assembly language), we should aim for something more specific and useful and denotative than "Everyone knows what an array is!"

Well-factored programs walk a tight balance between overspecifying their interfaces, thus too-tightly coupling themselves to specific representations, and launching architecture astronauts into space with the unuseful Gordian-knot complexity of too much genericity.

... but it's tempting to use the language's core primitives, because everyone knows what an array means even though no one knows exactly what you're doing with it, which is really the important part of what a good type system can specify.

(Yes, I've written Haskell code. I appreciate Hindley-Milner and consider myself privileged to have corresponded with Dr. Milner about language design in depth. That doesn't change the fact that I can write trivial mathematical code in Haskell which looks obviously correct both to readers and the type checker but which generates infinite loops due to simple arithmetic principles. If you choose the wrong types, you will get the wrong behavior.)

Would that our programming languages encouraged us to express the intention of code rather than making vague promises about its structure.

Using modern Perl 5 for one portion of the project does not necessarily require the use of Perl 5 for all of the project.

I've long been an advocate of Perl 6 the language, so is it worth using Perl 6 for the other part of the project? The big contender is obviously Rakudo, because it is the most active project and runs on a free software stack I can debug myself. (The other possible candidate implementtation, Niecza, runs on Mono, which disqualifies it from my considerations. Your personal technology choices may not be mine. I have no interest in discussing Mono here.)

I posted the other day my list of requirements to use Rakudo for practical purposes. What do I need technically?

This little app must:

• Communicate with a database. I don't necessarily need DBIx::Class for a project of this size, but I do need the ability to work with SQLite now and PostgreSQL later. Without DBIC, I'd have to do more work mapping tables and rows to objects, but the schema is simple enough it's not too onerous.
• Communicate with websites. I do need the equivalent of LWP. While I do use at least one specialty web service consumer module from the CPAN, I could as easily perform HTML scraping.
• Manage regular expressions, not grammars. Part of the project requires HTML scraping. If I were prone to overengineering, I'd write a full Perl 6 grammar for this. As it is, some quick and dirty data munging is more than sufficient right now for this proof of concept.
• Work with a decent templating system. I know there's no Template Toolkit system for Perl 6 right now, but I don't use all of TT's power. I need only a few features: variable interpolation, loops, conditionals, and subtemplates. If I had to reinvent a template system or work around it I could, but why would I want to? (I am in no mood to reinvent HTML escaping or to correct UTF-8 encoding either.)
• Work with dates and times. I use Perl 5's DateTime. Never again will I reinvent date or time handling. Never.
• Deploy easily. I use Dist::Zilla to manage bundling and testing. The simpler the work to deploy new versions and corrections, the more frequently I will do it. Again, Dzil does far more than I need, but what it needs I hate to give up.

Speed doesn't really matter for this application. It's a batch process which runs once a day and takes 10 seconds in Perl 5, mostly because I haven't done any work to exploit the embarrassingly parallel nature of the processing. If Rakudo ran it in ten minutes, that would be fine. (With that said, the data set will probably eventually scale by two orders of magnitude, so improving the Perl 5 version's parallelism is useful but would likely help a Rakudo version less.)

Memory use does matter, because I've deployed this application to a shared server and want to be a good citizen.

The stability of Rakudo as a target platform also matters, because I've set up this program to run without manual intervention for days, weeks, and even months. I understand that one of Rakudo's goals is to produce new and better versions every month or so, and I understand that me babysitting a Perl 6 version of this little app would provide valuable feedback to Rakudo developers...

... but I can't justify turning a fire-and-forget tiny side project into the tip of a spear intended to open the tent for further, larger projects.

I could work around the lack of most of the few modules I need. (Database access is the only real sticking point.) Yet even for a small side project—a toy project, even—with minimal needs, I find myself not wanting to use Rakudo because I'd rather spend my small side project time working on the small side project and not trying to get the technology stack beneath that small side project to stay put.

The conventional wisdom in #perl6 seems to be that Perl 6 needs more people playing with it to find bugs and more people building its equivalent of CPAN to attract more people to play with it. In my experience, Perl 6 needs something at a lower level: Perl 6 needs an implementation which provides what Rakudo Star was supposed to be. A year after the release of the first Rakudo Star, Rakudo isn't it, at least for me.

Maybe your project is different, and maybe your needs are different from mine. All I know is that while I'd liked to have used Perl 6 for this project, it didn't work out, and that's disappointing.

... but listen to a tale of two intertwined projects with a seemingly-sane and published deprecation policy that sounds great but doesn't actually work.

Parrot and Rakudo used to be much closer together. The Parrot repository had a subdirectory languages/ which held several language implementations running on Parrot. This was well and good (How did a lion get rich? It was the olden days!)—whenever Parrot underwent an API change, a simple ack of the source tree could find most places that needed to change, and running the test suites of the projects under languages/ could find the rest.

(Getting people to run the full test suite is a different story, but in that case at least guilt and a good bisection tool work post hoc magic.)

Then one day, Parrot left the Perl-centric world of perl.org and kicked languages/ out of the nest. languages/perl6 went to Rakudo.org and the troubles began.

You see, back in the olden days when a lion could get rich and the Perl 6 VM was like the Perl 5 VM but a little bit better, the way to extend Parrot was, obviously, write a whole wad of C code. Want to add a new data type? Write a wad of C code. Want to change how a core wad of C code works? Write a whole wad of C code. If hacking on Perl 5 had taught anyone anything (and I can't believe I can write this with a straight face), it's that finding hackers ready, willing, and able to write big wads of C code to work around or customize or extend other big wads of C code so that someone else doesn't have to write C code is a really easy prospect.

Anyhow, the Parrot execution and extension and embedding model has always assumed, as does Perl 5, that the VM should expose a big wad of C functions that extenders and embedders should use to manipulate big wads of C structs and other data types defined in C.

On one hand, customization and flexibility is good. On the other hand, people like me who know both C and Perl write in Perl when we can and C only when we have to for several very, very good reasons.

Imagine a ventriloquist with a Parrot puppet, except he doesn't stick his hand in the puppet to pull levers and flip switches and wiggle his fingers. He has a robot hand, operated by a joystick, and that robot hand is half robot and half organic and it tickles actual organs inside the puppet and the bird goes off and does its thing. Oh, and he's operating that joystick with his toes. Plus he's underwater, wearing a blindfold.

In other words, Rakudo has an intimate knowledge of the guts of Parrot and does some strange and bizarre things. (If you look through the revision history of those parts of Rakudo, you'll see I've fixed some of those strange and bizarre things and I've perpetuated others.)

When Rakudo and other languages left the nest, a deprecation policy came about. Imagine this vaudeville act:

HLL Developer: "Hey, you changed this API!"

Parrot Developer: "You weren't supposed to use it."

HLL Developer: "No one told me that, but regardless, you broke my project."

Parrot Developer: "Oh, sorry. Well here's how to fix it."

HLL Developer: "Wish you'd told me that months ago."

Parrot Developer: "Yeah, we'll do better next time. By the way, what in the world were you doing with that?"

HLL Developer: "No one told me to do it differently, so I just threw together something that works."

You can see where this is going.

Thus began the great Parrot version numbering wars. The end result was that Parrot would have two supported releases every year, one coming every six months. The initial deprecation policy promised no backwards incompatible changes without notification in at least one supported release.

In other words, if a project which was previously in languages/ had moved somewhere else where a well-meaning Parrot developer didn't notice that a simple change broke backwards compatibility, that project had the ability to request a reversion of the change, a documentation of the change as a compatibility change, and a delay of up to six months before making the change...

... depending on when the project noticed.

I've mentioned the idea of technical friction before, but get out your calendar.

This policy didn't only protect languages from unintended changes, it protected languages from desired changes. For example, if Rakudo wanted a new feature in Parrot, and if the best way to add that feature in Parrot meant breaking backwards compatibility (changing the order of search paths, for example), both Rakudo and Parrot developers had to mark their calendars.

The deprecation policy period is now three months, for hopefully obvious reasons.

Even so, now there are at least two projects on separate time tables with separate goals for features and improvements and deprecations. When Rakudo wants a feature from Parrot that Parrot doesn't yet support (or Rakudo developers believe it doesn't support fully or at all or in the precise way Rakudo wants), Rakudo tends to toe the joystick. When Parrot makes a change that exposes the fragility of tickling bird gullets with robot fingers, Rakudo gets to complain. The deprecation policy followed to the letter prevents Parrot from adding the features Rakudo demands at the same time that it prevents Parrot from improving the features that Rakudo uses.

You might read this and think that the problem is the deprecation policy. It's not—at least, that's not the root cause.

I hate the polite fiction calorie-free slogan that "Perl 6 is a research project", because it's a polite way to suggest that Perl 6 is an embarrassing pipe dream no true Perl hacker takes seriously, but implementing Perl 6 has required a lot of research and fits and false starts. (Before you complain next that it's taking a while, you write a performant grammar engine which allows lexical overriding of any grammatical rule or category.) When Parrot began, no one knew exactly how a Perl 6 VM machine should implement several important features. That was also true in 2005. That was also true of Parrot's 1.0 release in March 2009.

Making an effective Perl 6 means continually thinking and rethinking and simplifying and inventing new things.

Now tie an anchor around the feet of a live bird and pretend you're a ventriloquist.

Granted, Parrot's also long had the goal of running other dynamic languages efficiently and effectively. Its endgame is more than merely Perl 6 (and Perl 5). Yet a Parrot that won't run Perl 6 well has failed at its primary goal, and subsequent goals are less interesting.

The right solution is to invent a time machine and not kick Rakudo out of the nest. (The rightest solution is to invent a time machine and start implementing Perl 6 on Parrot from the first day as a first-class citizen and not a rat's nest of Perl 5 parsing madness which had, to my count, at least two replacements before Rakudo.)

The current Rakudo solution is to add another layer, another project external to both Parrot and Rakudo, which will sit in between the two and abstract away the Parrot specific parts in the hope that someday someone will add another VM backend so that Rakudo doesn't have to be tied to Parrot forever.

If the notion of working around a broken deprecation policy—broken because of too little coupling between two projects so intimately intertwined—is to add another layer of coupling to separate those two projects seems a little strange to you, you're not alone. By my count, that's three projects in a driver's seat built for one. If you can figure out which project is upstream and which project is downstream and how to debug with reasonable each which change where broke which test and who gets to fix it, you're a far, far better developer than I am.

M0 is one of those goals. This small set of opcodes represents the minimum necessary platform-specific code required to implement the rest of Parrot. M0 is a specification. Like Perl 6 is a specification, there can be multiple implementations. The demo implementation is a Perl 5 program, and my C implementation is the second implementation (and hopefully a likely candidate to become part of Parrot itself).

Like Perl 6, M0 is a specification and a test suite.

Unlike Perl 6, the M0 test suite is tied to the original implementation. That is to say, when you run the M0 tests, you exercise the Perl 5 demo M0 implementation.

A small task for the interested is to decouple the M0 test suite from the Perl 5 M0 implementation and make those tests available for multiple implementations. This probably means representing those tests in a form with expected inputs and outputs, perhaps running M0 source code through an assembler to create M0 bytecode, and running the tests against an arbitrary implementation.

Perl 6's test suite has an interesting capability whereby the list of tests contains metadata on which known implementation should skip or try to run but not expect to pass arbitrary test files. The #perl6 channel on irc.freenode.net can give you more details about this fudging process.

This project does easily parallelize across multiple interested people. Coordinating in #parrot on irc.perl.org will help.

As a bonus test, the C implementation should allow optional testing with Valgrind, if installed. All tests should run without memory leaks or invalid memory accesses. (I tested the C implementation by hand, but automating this is essential for further development.) This task is slightly more complex, but should be within reach for any Perl 5 programmer of modest experience.

M0 is one of those goals. This small set of opcodes represents the minimum necessary platform-specific code required to implement the rest of Parrot. M0 is a specification. Like Perl 6 is a specification, there can be multiple implementations. The demo implementation is a Perl 5 program, and my C implementation is the second implementation (and hopefully a likely candidate to become part of Parrot itself).

Like Perl 6, M0 is a specification and a test suite.

Unlike Perl 6, the M0 test suite is tied to the original implementation. That is to say, when you run the M0 tests, you exercise the Perl 5 demo M0 implementation.

A small task for the interested is to decouple the M0 test suite from the Perl 5 M0 implementation and make those tests available for multiple implementations. This probably means representing those tests in a form with expected inputs and outputs, perhaps running M0 source code through an assembler to create M0 bytecode, and running the tests against an arbitrary implementation.

Perl 6's test suite has an interesting capability whereby the list of tests contains metadata on which known implementation should skip or try to run but not expect to pass arbitrary test files. The #perl6 channel on irc.freenode.net can give you more details about this fudging process.

This project does easily parallelize across multiple interested people. Coordinating in #parrot on irc.perl.org will help.

As a bonus test, the C implementation should allow optional testing with Valgrind, if installed. All tests should run without memory leaks or invalid memory accesses. (I tested the C implementation by hand, but automating this is essential for further development.) This task is slightly more complex, but should be within reach for any Perl 5 programmer of modest experience.

M0 is one of those goals. This small set of opcodes represents the minimum necessary platform-specific code required to implement the rest of Parrot. M0 is a specification. Like Perl 6 is a specification, there can be multiple implementations. The demo implementation is a Perl 5 program, and my C implementation is the second implementation (and hopefully a likely candidate to become part of Parrot itself).

Like Perl 6, M0 is a specification and a test suite.

Unlike Perl 6, the M0 test suite is tied to the original implementation. That is to say, when you run the M0 tests, you exercise the Perl 5 demo M0 implementation.

A small task for the interested is to decouple the M0 test suite from the Perl 5 M0 implementation and make those tests available for multiple implementations. This probably means representing those tests in a form with expected inputs and outputs, perhaps running M0 source code through an assembler to create M0 bytecode, and running the tests against an arbitrary implementation.

Perl 6's test suite has an interesting capability whereby the list of tests contains metadata on which known implementation should skip or try to run but not expect to pass arbitrary test files. The #perl6 channel on irc.freenode.net can give you more details about this fudging process.

This project does easily parallelize across multiple interested people. Coordinating in #parrot on irc.perl.org will help.

As a bonus test, the C implementation should allow optional testing with Valgrind, if installed. All tests should run without memory leaks or invalid memory accesses. (I tested the C implementation by hand, but automating this is essential for further development.) This task is slightly more complex, but should be within reach for any Perl 5 programmer of modest experience.