Well, at least they're willing to commit to a date when py3000 will be released, how long has perl6 been floating in dev, and we still don't have someone willing to hold themselves to a deadline. I can count the number of coding projects I've seen completed without a deadline, maybe they have one internally who knows.

@Anonymous, committing to a date is silly.

Also, you get to complain about Perl 6 (or any other project staffed entirely by volunteers) not hitting any artificial deadline only after you actually hire someone to work on it.

It is interesting that he specifically mentions Perl 6 as what seems to be an anti-pattern for the way the design should proceed - 'It seems that some participants have forgotten the mantra "Not Perl Six."'

I don't even know if Perl6 is all that applicable to a discussion on Python3000. Perl6 had a least a fairly well focused plan, but also included a lot of things into it (probably too much). So much so, that Perl6 language features are appearing in Perl5 already.

Perl6 encompasses a new virtual machine, with a just-in-time (JIT) compiler (this is called parrot). Parrot is optimized for dynamically typed languages, so a lot of Python hackers are looking at Parrot as possible replacement for CPython at some point.

And before more Perl-bashers start up, components of the Perl project (like Parrot) make their way into, or directly improve the other dynamic languages, like Python and Ruby.

I can't wait for Parrot to be finished actually, as I think it will usher in a new age of dynamic languages, where all code executes fast, and scales to SMP. Though Ruby threading semeatics may be hard to implement, as currently only one Ruby thread ever runs at a time. Threaded Python programs will work as they do now, but with no giant lock around the kernel, they will get really fast on SMP servers.

Unquestionably language redesign is difficult. But I think Guido is exhibiting a goodly portion of pragmatism in this pursuit. He really appears to be breaking things up into chunks. Focus tightly on Python 3000. Don't overhaul the language at this point. Let people start planning for Python 4000 and the major overhaul. I have a better feeling about specific milestones being reached with this plan. I've only looked in from the outside with the progression of Perl 6, so I can't really say whether this is or is not what is happening in the Perl community. I would definitely prefer for the Python 3000 migration to not drag on too long, though.

Jeremy: the ongoing Perl 6 effort basically started in 2000 - and we're still a ways off from seeing a finished Perl 6. There are a lot of internet trolls making noise about this. Personally I don't think the situation is ideal either, but it is my understanding that in all of this time, none of the design leads has had the fortune of being able to concentrate on the design work without the distractions of a day job, much less of getting paid for it.

Consider now that Perl 6 started much like Py3k: as a modest cleanup of a pile of warts that would be possible after accepting a break in backward compatibility. And Py3k seems to be following the same direction as Perl 6 subsequently did: freed from backward compatibility concerns, it gradually turned into a ground-up rethink of the language. It's no wonder that it has taken so long.

If Guido succeeds in splitting the development into near- and far-future branches and the near-future branch produces deliverables soon, the far-future branch will quite likely wither.

The Python community isn't lazy like the Perl community. The Perl community just like to talk about reengineering instead of doing it. Perl 6 is going to be stable in 2020.

@JD, please feel free to shame us all by posting a link to all of your contributions to Python 3000. It's not difficult to find a list of all of my contributions to Perl 6 and Parrot.

BTW - where are we on delivery of Perl6? I understood it was hoped that the end of 2006 would see a key delivery? This is a genuine enquiry, from one who has fond memories of Perl5.

Sorry, I didn't include my name in my initial post. My point is, I work for a company that has been a perl5 shop for quite some time now. Not having a completion date for any project in any engineering field, where you're delivering a solid product, does not inspire confidence. This is not to bash perl, personally I think perl is a good language that is simply old, and like all things old in computers, needs a new replacement. It's getting more and more difficult for us to justify developing new projects in perl5 because of all the hoops you have to jump through to get certain things done, that do not exist in more up-to-date languages. I think perl6 addresses alot of these issues. If I knew the first place to start on working on a language I would commit my time, however I do not.
My point to the initial post was this: I'd say they're having a good time reigning things in and handling the design fo Py3k, because they can actually give a soft deadline. That's a good sign from an engineering point of view, because when you can't give a deadline if you're lacking man power, knowledge, skill, or organization and all four are important on anything of this magnitude.

- Marlon

@Marlon, I appreciate the clarification.

Still, I think even a soft deadline is silly, unless Guido's deadline accounts for the fact that you can't predict volunteer labor. That's one of the difficulties of Perl 5, Perl 6, Gtk+, NetBSD, and many other projects too numerous to name.

I don't see how Python 3000 or Python 4000 can possibly avoid it.