All the Perl that's Practical to Extract and Report

Navigation

use Perl Log In

pmichaud (6013)

pmichaud (email not shown publicly)http://www.pmichaud.com/Patrick Michaud is the pumpking for the Rakudo Perl 6 compiler. He holds a Ph.D. in Computer Science and was formerly a Professor of Computer Science at Texas A&M University-Corpus Christi. He is currently a software developer and consultant focused on open source development and applications, including Perl, PmWiki, and Linux.

"Perl 6 'finished'" isn't the story I want to tell

Here, I'll explain since you don't seem to get it. When people ask "When will Perl6 be finished?", they want to know when there will be a Perl 6.0 release.

Actually, I really think I do "get it", although I admit I may not be clearly expressing that. Later in the same comment thread gdonald follows up with:

Seriously, the Perl6 spec isn't even nailed down yet? What is the hold-up on that? Design by committee?

To me, that sounds an awful lot like a variation of "When will Perl 6 be finished?", especially the "What is the hold-up..." part. In short, the thread quickly went from "you don't seem to get it" to ultimately saying something very like the question I used to start my original post.

Neither this reply nor my original article are intended to imply that people shouldn't be asking such questions or that they're wrong for doing so. I call out gdonald's messages not because I wish to ridicule him or prove him wrong, but simply because I think they illustrate well the "disconnect" that exists in discussions about Perl 6, and why I'm hoping to change the discussions to something more useful than "finished" and "not finished". Because the end result of the "finished/not finished" discussion is often:

Seems like Perl6 might be going the way of GNU/Hurd, eternally under development, and never to land.

I don't believe that Perl 6 will be eternally under development -- but I am concerned that the perception of "eternally under development" is potentially a significant blocker to continued progress on Rakudo and Perl 6. That's one of the major issues that Rakudo Star is intended to address.

I also completely "get it" that for most people the real thing they want to know is "When can I start using Perl 6?" in the sense of "apt-get install perl6". But I think even that question has many hidden assumptions that must be exposed before there can be any sort of useful answer. Indeed, the answer changes depending on who is asking the question and what they want to do. So another purpose for Rakudo Star is to illuminate the development process and our ongoing status so that people can begin answering that question for themselves.

As the quotes above illustrate, somewhere there's an implicit assumption that the specification should be finished already. When we then say that the spec isn't finished (and it isn't), people often conclude that Perl 6 is suffering from a "design by committee process flaw" that is preventing the specification from being finished, and in turn that's what is blocking "apt-get install perl6". I think these misconceptions arise from assuming a "waterfall" development model where it's a one-way path from specification to implementation. But just because (unlike Perl 5) Perl 6 has a spec that is separate from its implementations doesn't mean the specification comes first.

Looking back, it's not too surprising to me that people have assumed a waterfall model of development -- those of us working on Perl 6 haven't given a good public picture of the true story. The various development roadmaps we've provided have been accurate as far as they went, but they didn't really give insight into the underlying processes. And for many of us, myself included, we're only now learning how to put words to parts of the process to be able to tell others about them. Here's my version...

For the past few years, changes to the specification have been made almost exclusively in response to the concerns and issues that have come about from compiler implementations and application programs written in Perl 6. For example, while implementing a feature in Rakudo we often discover a place where the specification is self-contradictory, so the specification is changed to resolve the contradiction. Or, someone will be using Perl 6 to write an application, and as a result we find places where the specification is deeply sub-optimal and needs to be cleaned up. These days it's very rare that the design team says "wouldn't it be nice/better if Perl 6 changed to do X" on its own initiative; our discussions are nearly always "implementations are having trouble with this part of the specification, what do we need to change to improve that?"

So the specification isn't finished, but that's mainly because it's evolving in response to implementations and applications, and not due to a tendency to over-design it. Because the specification is evolving based on implementation issues, simply freezing what exists now as "6.0.0" will make things harder on implementors, not easier. In other words, freezing the existing spec will paradoxically delay implementations of Perl 6, not expedite them.

We are rapidly entering a phase where what we will need most is for more people to be creating real use cases in Perl 6, testing the soundness of the design and implementation. That is, we need to see more applications to be written in Perl 6 so we can harden the specification even further. For many people and applications Rakudo is ready for use today, but there are still enough issues that I'm hesitant to call it anything other than a "development release" for a more general audience. The problem then is that many people rightly take "development release" to mean "not ready to use yet", and that's also counterproductive to what we need.

This is where Rakudo Star comes in, and this is what I mean by "a useful implementation of Perl 6". It's intended to recognize that a Perl 6 release can be useful to many even though it may be incomplete. It's intended to provide a bright line where we can say "here's what is working now" and "here's what is not working yet". It's intended to help people determine when Perl 6 has been sufficiently realized to be ready for their needs. And it's intended to make it possible for more people to start writing programs in Perl 6, because one of the things we are needing is real-world use cases to test, refine, and extend the existing design.

At the same time, we need to be very careful about using the label "finished" or "1.0" for anything that isn't all of what has been promised for Perl 6.0. (See KDE 4 development for why this is a bad thing.) In fact, I'd like us avoid the notion of "finished" altogether. Instead, I want us to regularly deliver something that is useful and usable, make it clear what we are delivering, make it clear what we're not delivering, and enable people to see when Perl 6 is likely be ready for them (as opposed to "ready for all").

Ultimately Rakudo Star is intended to give some justifiable support and clarity to phrases like "Perl 6 exists" and "you can now write usable applications in Perl 6", without the distractions that arise from the "When will [Perl 6 | Rakudo] be finished?" sorts of questions. It's not that I think people are somehow wrong for asking these questions -- I think I do very much understand what leads people to ask them -- it's just that I'd like us to start finding ways to move our discussions beyond the "finished / not finished" trap that we seem to have fallen into. I'd like to help us all escape this trap because (1) I don't think it reflects reality, and (2) if "Perl 6 is finished" remains the primary criteria that most people use to decide whether or not to write applications in Perl 6 (and the criteria that we hold ourselves to), then we'll never get there.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Please Log In to Continue

I heard that about a year ago, a language that had been in use for something like twenty years added a bunch of new keywords, broke binary compat, and even changed some of its operators. Next, there's talk of changing how it handles Unicode, changing the set of first class data types...

The top five things holding me back from using Rakudo for anything but experimental playing with Perl 6 are (in order of imporatance):

1. lack of lazy evaluation2. s/// is not implemented3. it cannot be installed ("removing or moving the build tree will cause the binary to stop working")4. I cannot easily tell what parts of the spec are implemented and which are not5. The REPL has executes every line in its own scope making lexical variables (and therefore the REPL itself) next to useless.

All of these issues are slated to be resolved by the time Rakudo Star is released. Indeed, I expect that all of them except for #4 will be resolved by the September 2009 compiler release.

#2 can already be done in current versions of Rakudo, just use.subst() instead of s///. The s/// form should be available when we start using the STD.pm parser in Rakudo, currently planned for December 2009.

That makes me happy. It would be nice if there were an article about what is planned to be (or not be, if that is shorter) in Rakudo Star. Of course, it is entirely possible there is already a road map on a public site that I have not seen yet, and there is still a lot of time until Spring.

I am not worried about the spec (and therefore the implementations) changing or growing; I am worried about how much of what is currently spec'ed will be implemented by the deadline. A Perl 6 implementation that can't

It would be nice if there were an article about what is planned to be (or not be, if that is shorter) in Rakudo Star.

Patrick and I discussed this at OSCON. Our rough plan is that I'm going to be helping track and communicate what is in Rakudo Star, and what isn't, and how close we are to having those things ready to go.

Even Perl 5 isn't "finished" though. If the original Perl 5 had been the ultimate destination then everyone would have been sat in the same place for the last 15 years.

Perhaps it's better to imagine the Perl 6 spec as being analogous to what people might have envisioned for, say, Perl 5.10. The original Perl 5 didn't implement all the features from that "spec" (like given/when, or say), but it was still usable. The Perl 6 spec will inevitably evolve in the same way that the Perl 5 implementation has, and

Actually, what I want from Rakudo right now is just more speed (like 10-100x the speed it is now) so I can run it and crash it faster/more often:-). I guess to be comparable to Perl5 we need like 1000x times the current speed, but I'm willing to settle for less.

perl 3 was a language that was useful for production work.Through the point releases of perl 3 and perl 4 that language got extended drastically - always in a 99.9% backward compatible fashion for each step, and always being useful for production work.

perl 5 was only 99% backward compatible, but turned the language upside down and extended an order of magnitude, and, after the first couple of point releases worked the kinks out, was useful for production work (in an order of magnitude larger number of areas

I really liked the description you gave during the Rakudo BOF on YAPC::EU. Maybe we should use it
as a subtitle of Rakudo:

Rakudo, implementing a useful subset of Perl 6

Later I thought that by using the name Rakudo we can actually avoid the Perl 5/6 trap and the "when is Perl 6 going to be ready?" trap.

Maybe the disconnect between Rakudo and when is "Perl 6 going to be ready" could be increased by giving small and increasing version numbers to the Rakudo releases - even starting by the next one - and h

If people are going to put thought and effort into understanding if Rakudo is useful for them, I'd like them to do so based on the ratio of planned and implemented features important to their work, not on lengthy explanations of magical version number schemes.

It would be a shame to fall into the magical version numbers trap while trying to avoid the magical version numbers trap. ("Rakudo 0.2 in April? Those fools! Can't they release software? Everyone knows that software isn't usable for anything until

Well color me contradictory and call me flame-bait, but I'm really annoyed by
the original blog posting, as well as this follow-up article. Am I the only
one? In truth, you've answered a lot of questions for me. But it leaves open
some more.

What first got me going was when people don't ask the *right* question, your
seeming to come off like someone who responds to the question, "Can I have a
cookie?" with "Don't you mean *MAY* I have a cookie?" I'm sorry you don't like
the word "finished" but as you say you

Perl 6 should have a release date. You prioritize what will go into that release, you implement it, and then you release it.

I believe that this is exactly what the Rakudo Star announcement says we are going to do. It names a release date, says that we will prioritize what will go into that release, gives a criteria by which we will come up with priorities, and says we will focus our efforts over the next eight months on implementing those priorities.

Virtually nothing new has gone into the Perl 6 spec for a long time. The big new stuff came along at the beginning - the time involved reflects just how big and new a lot of these things are, and how difficult it is to get everything into a coherent sort of whole. This is not navel-gazing or ADD or being distracted by shiny things. The shiny things are here, they're in the spec, many of them are in the code. Many of them have rough edges and we're still trying to get them to fit together into a nice pattern

Perl 6 is alive. A trek? No. Rakudo is a building site for a fantastic new structure. And building sites look messy, outsiders see activity but cant distinguish it from progress because they are outsiders, the architect's plans are being adapted to reality whilst retaining the overall concept, and the exterior will only be visible and shinny immediately before its ready to be used (and even then the plumbing usually goes wrong on the first day).