I hope that Perl 6 doesn't fall into that trap. And I'm confident that it's not going to, because the differences between Perl 5 and Perl 6 are much larger than those of python{2,3}, thus offereing a larger incentive to migrate stuff.
Perl 6 - links to (nearly) everything that is Perl 6.

I think that won't be the case with Perl 6 as they have found a way integrating existing CPAN modules with Perl 6 code. You are actually very right in pointing out this fact, Its not just a bare interpreter. The word production ready actually has a lot of meanings like availability of sufficient documentation, standard libraries, spec completion, stability etc. But you have to start some where like Python 3 did, there idea is to really backport the Python 3 stuff into 2.x. In their case they have something to migrate to, in our case our migration target isn't yet ready. So the focus should be first on spec completion first not migration.

they have found a way integrating existing CPAN modules with Perl 6 code

Wow! Really? Does anyone have a link to that?

the only thing you can learn from that is that you have to port all the(important) Perl5 modules --> Perl6 early so when it's out people won't be able to complain about this. but since Perl6 is still in development devs will face serious bugs that they won't really be able to fix themselves because they don't know the internals of the compiler in order to fix those bugs.

It will be very disappointing if Perl 6 releases without a standard library. At the least all the standard modules with Perl 5 have to be available with Perl 6.

oppinion on Perl6's production-readiness

oppinion on Perl6's production-readiness

Note that this is not what's been discussed in the reddit thread (but rather if it's practical).

Anyway, it's not yet production ready, for most values of "production" that you can come up with.

I do occasionally solve problems in Perl 6 where it's much better suited than Perl 5, but usually when I want something stable that will still work in 2 years without any maintenance, I use Perl 5.

Rakudo is now in need of early adopters to shake out bugs, and to tell the developers which areas need the most work to become "production ready" (which can mean a whole lot of different things depending on othe use case).

Perl 6 - links to (nearly) everything that is Perl 6.

Depends on your definition of "production ready", but I would not yet use it in any mission critical applications. And with Perl 5.12 now out, I do not yet see a pressing reason to switch to Perl 6 yet.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

The questions I'd like to see an answer to--were we allowed to ask them--are:

• Can any current implementation of Perl6 do everything that Perl5 can do without extensions and modules?
• If not, what is missing? And why? (That is: what is the limitation preventing it.)
• How's the current performance?

Thank you for asking a sane, answerable and non-FUD question in this thread :-)

I can only talk about Rakudo, but I'm quite sure it's the most usable compiler these days.

Can any current implementation of Perl6 do everything that Perl5 can do without extensions and modules? If not, what is missing?

No. Rakudo mostly lacks IO to be a proper superset, as well as concurrency.

And why? (That is: what is the limitation preventing it.)

For IO: priorities, spec uncertainties, and a champion.

Rakudo development so far has focused mainly on language features, and a few contributors that are too scared to hack the guts (like me) have filled in many built-in functions. But with IO it's not that easy, because you have to interact with parrot in scary ways (or so it seem to me). The specification for IO stuff is currently in the weird state of being both over engineered in some areas, and under engineered in others. So it would take somebody with quite some experience to implement the sane parts, adapt the spec where it's insane, and expand it where necessary.

Concurrency support mostly blocks on parrot, which doesn't expose threads to HLLs in a usable way (has a few blocking bugs, and has had them for quite some time). Still there is hope: We've received a quite good google summer of code proposal to fix up threading. Nothing is decided yet, but I have hopes that it will be funded.

How's the current performance?

Bad. You should expect Rakudo programs to run 100 up to 1000 times slower than comparable perl 5 progreams.

Perl 6 - links to (nearly) everything that is Perl 6.

> > How's the current performance?

> Bad. You should expect Rakudo programs to run 100 up to 1000 times slower than comparable perl 5 progreams.

Did you mean "prog-dreams"? ;-)

My 2?to this discussion:

The most interesting parts of the Perl6 project were:

• a JIT compiler tuning the execution nearer to C-speed
• an orthogonal redesign allowing much easier language extensions in the future, while Perl5 is stuck in a byzantine labyrinth of patches and patches of patches.

  Unfortunately for most of the messages I read from the Perl6 team, I have to admit:

  I'm really sorry, but I don't understand... 8-(

  Cheers Rolf

I think lack of contributors is the limitation they have currently.

he specifically asked what features Perl5 has that Perl6 doesn't yet. he didn't ask for the cause it doesn't have them. many contributors with small time-slices are probably not going to make a lot of progress IMHO

with Perl 6 is that the spec is released before hand setting very high expectations.A spec complete production ready release is a very overwhelming task to be achieved in a short period of time

So why don't they break it up in two parts "standard Perl6" and "Perl6 for astronauts". Just kidding but you get my ideea...

So it will take time and the only way is to either help them or wait in patience

Sorry I have no intention in helping(I don't know here in my initial post you've read that I intend to help). No I don't think those are the only options. There is also the option of asking from time to time "is it ready?".

There is also the option of asking from time to time "is it ready?"

You could, but it would only eat into the contributers time since the FAQ covers this in detail. See Re: How much Perl6 have we got? (take 2).

I really don't know the technical complications that go behind building a interpreter (Compiler + VM in case of Perl 6) for a language like Perl 6. When I first read the specification I was overwhelmed. It must be really difficult, else why would they take so much time?

It is a bit frustrating, I agree. For example whenever I've spoken something Perl 6 at my work place the first question is about whether there's a production ready version of it. A negative answer leads to a ridicule that it has taken more than a decade now for this thing to come out.

Understand this from implementers perspective, there are not many people who can hack on things like compilers and interpreters. So they are always running short of people. And since we don't contribute we loose all rights of complaining. Its irritating/frustrating but there is no way out.

c'mon it's not subjective. it's clear as daylight.

Production ready for my business (publishing) is different than production ready for real-time derivatives trading. Production ready for my brother's business (software testing) is different from production ready for a non-profit. Production ready for a web development firm is different from production ready for an ISP. Production ready for a biology lab is different from production ready for an industrial automation shop. Production ready for a sporting good store is different from production ready for a university.

Within those industries, production ready also depends on availability and skill level of developers, maintainers, managers, and consultants, as well as their taste for risk, the amount of ancillary tools and materials, and considerations for existing code and systems.

None of these are binary, off-or-on, simple, single right answer for everyone everywhere questions.

I work in a shop where a majority of the code is not what I would call production ready. Yet it's in production and has been for years; failing on edge cases regularly and failing on normal things mysteriously now and then. The variance of quality of code and systems that are in production in the various shops of the world is astounding and in almost every freelance gig I've had I've seen code that I would never personally allow into production. "Production ready" is a subjective concept which I've seen to mean "hobbled and dangerous" as often, or more often than "solid and safe."

Instead of wasting hours to get a message across on a forum, can some of the Perl6 people talk to the geezers at perlcast or at hivelogic.

Instead of having these quick reports(which are ok also...) we could just have some perlcasts where some important dood/dudess from Perl6 gets to speak their mind and say what's been going on. There's also a site specifically built for programming tutorials.

And after all this stuff happens, bam! people can listen or watch Perl6 all of a sudden and it becomes more real because you don't want the language to be exclusivistic, you want people to use it.

forgot to mention the site for screencasts, it's called showmedo.com

Speaking for myself, well, hepatitis was the major reason I stopped coding for Perl 6, and though it was not anywhere near serious enough to require liver transplantation, it did take me many, many months to recover.

It's true that when I recovered in 2009, my internal trauma blocked my contribution to Perl 6 for a year. However, I gradually grew out of that -- and imvho, reconciliation is the best kind of social sublimation.

So please contribute to fglock++'s Perlito or any other implementations you see fit, but as the trauma is over for both me and chromatic++, please kindly refrain from introducing more drama on that particular setting.

Thank you for your understanding. :-)

Forgot to add this

not related to perl 6 but another contributor being driven away
some more parrot history