http://www.perlmonks.org?node_id=835419

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

There's a discussion on the reddit about Perl6 and I'd like to know your oppinion on it.

Replies are listed 'Best First'.
Re: The current state of Perl6
by cdarke (Prior) on Apr 19, 2010 at 11:41 UTC
    There is an interesting parallel with Python 3, which was released around Christmas 2008. Python 3 code is not backward compatible to Python 2, but there are much fewer differences between Python 2 and 3 as there are between Perl 5 and 6. Mostly the code got tided-up and deprecated features removed.

    So, is everyone using Python 3 now? No. The reason, according to the Python people I have spoken to, is the lack of third party modules. They like Python 3, but just can't use it. Let's hope that 'we' learn from that mistake before repeating it.
      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?
          A reply falls below the community's threshold of quality. You may see it by logging in.
      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.
Re: The current state of Perl6
by CountZero (Bishop) on Apr 19, 2010 at 10:28 UTC
    Our opinion on Perl6 or our opinion on the discussion on Reddit?

    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

      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

Re: The current state of Perl6
by Anonymous Monk on Apr 19, 2010 at 10:45 UTC
    I think Rakudo is doing pretty good progress off late, I generally browse through the IRC logs when I get time. And what looks to be clear is that some time between 2011 and 2012 you must see a production ready release.

    The problem 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. You must also distinguish between such a release and the completely standard library being available. I think the spec for that is not yet nailed. So it will take time and the only way is to either help them or wait in patience. It will happen some day.

    Meanwhile books are being written and a early adopters release called Rakudo * is planned in some weeks from now. All this is definitely good progress.
      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?".
        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.
Re: The current state of Perl6
by BrowserUk (Patriarch) on Apr 20, 2010 at 05:01 UTC

    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?

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      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

      A reply falls below the community's threshold of quality. You may see it by logging in.
      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
Re: The current state of Perl6
by JavaFan (Canon) on Apr 19, 2010 at 11:32 UTC
    Being production ready is very subjective. Noone can answer if Perl6 is ready for your production environment, except the people knowing your requirements. Perhaps a current implementation of Perl6 is production ready for you. Perhaps there will never be an implementation of Perl6 that's production ready for you (but used in production by many others).
      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.

        A reply falls below the community's threshold of quality. You may see it by logging in.

        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."

Re: The current state of Perl6
by Anonymous Monk on Apr 22, 2010 at 23:48 UTC

    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
Re: The current state of Perl6
by Anonymous Monk on Apr 21, 2010 at 02:38 UTC
    It has been mentioned that pugs project has been unmaintainable,
    but it was a good project going at a pretty good pace and was successful in getting lots of people interested,
    Here is one of the reason why it did not go further
    also none of the perl6 devs do not mention fglocks work.
    These were capable people who were given the cold treatment

      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. :-)