[smosher]

By now Perl 6 is viewed as best an interesting research project by organizations using Perl 5 in production.

As a member of an organization using Perl 5 (among many other languages), I should probably speak up. Though we haven't donated many thousands to TPF, it may be worth noting that with a minimal set of modules, similar stability and performance guarantee within an order of magnitude Perl 5's, we would be using Perl 6 without question. (With that alone it wouldn't replace all of our Perl 5 code, but we would be using more Perl overall as a result.) In fact Niecza is temptingly close to that status at the moment if you factor interop into the equation.

We have a highly polyglot environment, so introducing a new language to that is something that can be taken in stride. I assume a lot of Perl 6 reluctance comes from unfamiliarity, but for us it's more a matter of overall reliability. I find Perl 6 is better able to represent program logic, and I am sure having it in our environment would improve prototyping and maintenance considerably.

[andrewvc]

Here's the question I have.

Perl5 -> Perl6 is not a natural progression. It's such a radically different language that going to say Python or Ruby is nearly as similar a change. Why's it obvious to you guys?

[smosher]

We have some Python code kicking around, but it hasn't penetrated our codebase very much, and in fact has never made itself integral. We have one very small yet important tool that had an implementation in Python but it was eventually rewritten. While has always been a very important tool, it was never a service. We've never (to the best of my knowledge) had Python in any of our server code, it just hasn't come to pass.

As for Ruby, I think the closest we came was a Redmine install. I don't have enough experience with Ruby to pass any judgments, but to me it feels like a poor compromise between some other languages. I don't think I'd mind replacing our use of PHP with it but it would be a harder sell than I would be in for and it simply wouldn't be worth it, considering the value of homogeneity within the existing PHP projects (or alternatively, the cost of rewrites.) Besides, I see no reason to avoid Perl here, virtually all of the PHP is database driven... DBI is just phenomenal.

Even though we're willing to take on another language it still must be justified. I suppose I have to answer the real question now. My answer is: I don't know about 'progression' (there's certainly a discontinuity) but I think Perl 6 is a natural evolution of Perl—not specifically Perl 5, but a truly 100% organic product of Perl culture. It also has some specific enhancements that solve real problems I have identified in our code which wouldn't be possible without a break of some kind.

[wicket232]

Perl 6 is still "Perlish", in the sense of TIMTOWTDI and DWIMmy-ness. However, after playing around with Perl 6 a little bit, I'm not convinced that it keeps Perl 5's practical simplicity.

I suspect that there's a whole crowd of Perl 5 lovers who just want something practical and simple -- they want a cleaned-up Perl 5 -- and they're scratching their heads wondering why the 6ers are spending so much time working on advanced features.

[draegtun]

I believe the original plan was that you could run perl5 & perl6 together like so...

    use v6;
    .say for 1..10;
  
    {
      use v5;
      say for 1..10;
    }

    # back to perl6

That might (still) be a pipedream however one reality which is working right now is that you can run some perl5 modules from within Rakudo (Perl6 on Parrot):

    use v6;
    use CGI:from<perl5>;

    my $q = CGI.new;
    print $q.header,
        $q.start_html('Hello World'),
        $q.h1('Hello World'),
        $q.end_html;

ref: http://news.ycombinator.com/item?id=2188433