[avar]

This is very nice. Between this and Booking.com's (disclaimer: I work there) 
€100,000 donation just over a month ago TPF is really getting on track for having large corporate sponsorship from organizations who recognize how valuable Perl is for their infrastructure.

I talked to some of the TPF people at Booking.com's donation event and they expressed desires to have more paid-for developers working on the Perl 5 core, and they're really gearing up as an organization for making that happen.

One thing of note for those unfamiliar with the Perl community: Notice how both of these big grants are earmarked for Perl 5 development, not Perl 6 development.

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

I don't mean that as a comment to detract away from what the Perl 6 developers are doing, but to point out that it's a very different pattern than what's happening with the next generation of Python, Ruby, PHP etc. runtimes.

1. http://news.perlfoundation.org/2012/01/bookingcom-sponsors-1...

[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

[muyuu]

Python, Ruby and PHP are converging so much it's becoming totally pointless to keep up with more than one of those, other than availability of tools and runtimes. Looking forward to production-ready Perl 6.

[Loic]

And community. I am using both PHP and Python because of two widely different communities and approaches to solve problems. For example, Python is the language with the largest and most robust collection of scientific software bindings. Python users tend to take a bit more time to implement things, but they do it in a very robust way. Java is pushing a bit, but Python stays the king.

On the other hand, for everything a little bit "web" related, you can find a stack load of easy to use PHP code. They are also usually "pure" PHP, making them easy to integrate in your own framework/system. Usually the PHP community at large is very fast at getting things done in a simple way (sometimes a bit ugly, but this is improving drastically).

Note: This is of course a bit of a caricature what I wrote, but in essence, you cannot ignore the community/ecosystem supporting your language.

[muyuu]

I agree. It's partly what I meant by availability of tools. I actually didn't mean IDE (I'm a basic text editor / vi person), I meant codebase mostly, libraries and whatnot.