Perl 5.11.0 Released

jamie points out that Perl 5.11.0 was released yesterday, as well as a schedule for future 5.11.x releases, planned for the 20th of every month. Jesse Vincent encouraged testing of the new (development) version, saying, "If you write software in Perl, it is particularly important that you test your software against development releases. While we strive to maintain source compatibility with prior releases wherever possible, it is always possible that a well-intentioned change can have unexpected consequences. If you spot a change in a development release which breaks your code, it's much more likely that we will be able to fix it before the next stable release. If you only test your code against stable releases of Perl, it may not be possible to undo a backwards-incompatible change which breaks your code."

Comments

Wow. . .

[ibmjones]

It must be real good if it goes to eleven.

Re:Wow. . .

[Jeff DeMaagd]

Is anyone hosting a Perl 5.11.0 House Party? Will there be deviled eggs?

Also try Perl 6

[Norsefire]

While you're being adventurous and testing Perl 5.11.0 I also suggest trying a Perl 6 implementation. Rakudo Perl (running on the Parrot VM) is one of the most actively developed right now. Not as solid as Perl 5.X yet, but certainly getting there.

Re:Also try Perl 6

[Norsefire]

1. exists

People have been using Perl 6 for years now. It certainly exists.

2. has stable specification

"Stable" is a biologist term, it means "dead". The problem with a set specification (the "waterfall" model) is you discover after something was implemented that it was a bad idea, the whirlpool model prevents this.

3. has stable releases

Rakudo has a release every month. The "big" release is coming next April.

Other stuff that is out

[sakdoctor]

Kernel 2.6.31.1
PHP 5.2.11
Apache 2.2.13
Debian 5.0.3

Keep up with all those thrilling point released with slashdot.org

Perl has died in industry.

[Anonymous Coward]

For software of any appreciable size, Perl has unfortunately died in industry. People just aren't using it for anything more than 10-line throwaway scripts.

Perl 6 was something those of us in industry had been anticipating with glee. We expected it to modernize the Perl platform, and make it a contender against Java, .NET and C++ for large-scale software development. But we also expected we'd have that around 2005. It's nearly 2010, and we still don't see much real progress on that front. Rakudo just isn't a production-grade product yet.

I'm sad to admit it, but instead of waiting for incremental Perl 5 releases for the next decade until Perl 6 is finally mature enough, the company I'm with has started to migrate from Perl to Python. Unlike the Perl community, the Python community has shown with Python 3 that they're capable of working together to create a major release with many new features in a relatively short amount of time (especially compared to the Perl 6 effort).

Rewriting our approximately 3 million lines of Perl code into Python has actually gone reasonably well. Although I was a staunch defender of Perl, I do have to give Python its kudos. Every day it looks more and more like we've made the right choice moving away from Perl, and towards Python.

Re:Perl has died in industry.

[Fnord]

Ok, I actually do use perl professionally, but even I realize there are some serious problems with it. The reality is a middle ground between you and the grandparent.

But we also expected we'd have that around 2005.

You were expecting it the same year the very first implementation (Pugs) was started? That was silly of you.

Pugs was started in 2005 as an attempt to inject life into what looked like a dying project. The language spec started in 2000. In five years they hadn't nailed it down. In ten years there still isn't a working implementation.

It's nearly 2010, and we still don't see much real progress on that front. Rakudo just isn't a production-grade product yet.

Unless lives are at risk, Rakudo is stable enough for production (although you may want to wait for the April "Rakudo Star" release).

That is EXTREMELY wishful thinking. It may have changed in the last couple months, but I tried this perl 6 code out earlier in the summer:

my $blah = "blah";
$blah = $blah.reverse;
print $blah;

and that SIMPLE code resulted in an infinite recursion error.

I'm sad to admit it, but instead of waiting for incremental Perl 5 releases for the next decade until Perl 6 is finally mature enough

Perl 6 != Perl 5. They are two VERY different languages. Perl 5 and 6 will continue to be maintained in parallel.

Perl 5 has problems inherent with the language that inhibit large scale use, and this is coming from someone who works on a multi-million line perl 5 project. Recent frameworks have tried to address the problems by grafting perl6 like features onto perl5, but they always impact performance, and are never perfect. And goddammit, I've still found no way around the broken behavior of the SUPER keyword.

until Perl 6 is finally mature enough, the company I'm with has started to migrate from Perl to Python.

You're complaining about maturity and yet you're using Python?

Unlike the Perl community, the Python community has shown with Python 3 that they're capable of working together to create a major release with many new features in a relatively short amount of time (especially compared to the Perl 6 effort).

Perl 6 has many, many more changes than Python 3. It is an entire rewrite of the language from the ground up, they didn't just change the print statement to a function and call it a day.

Rewriting our approximately 3 million lines of Perl code into Python has actually gone reasonably well.

That would have been what, 6 million lines in Python? Now I know you're trolling.

You're being a bit unfair to Python. I'm not a huge fan of the language (if I had to move anywhere it'd be ruby), but python 3 while it didn't change much in the language itself, was a huge boost in performance to the interpreter. There are incremental changes happening to the perl5 interpreter, but nothing major structural can, because the codebase just isn't very maintainable. In fact that was one of the main reasons they decided to scrap it and develop parrot from scratch instead of working from the perl5 base. Try embedding the python interpreter and the perl5 interpreter in a C program, see which one has internals that make more sense.

Not to mention that python is immensely more parsable. There are identical python interpreters in C, on the JVM, and on the CLR. Its been said that the only thing that can parse perl5 is perl5, and that is evidenced by the fact that the parrot project gave up on implementing a perl5 parser.

That's not to say there aren't things python does wrong. Every time there's a point release it seems everyone's code completely breaks, while perl5 is backward compatible to perl1. And frankly, I hate significant whitespace, but that's a personal preference.

Regardess things are not completely happy in the perl world.

Re:Perl has died in industry.

[harmonise]

Perl 6 != Perl 5. They are two VERY different languages.

Then maybe they need to have two VERY different names. Have we learned nothing from the problems caused by Java and JavaScript? It's nearly 2010 and people still think those two languages have something in common with one another. Now we have two different languages with the same name. Did anyone think that that would not cause confusion?

Re:Seriously?

[ThePhilips]

Uhm...

Perl 5 development is stagnant for one simple reason: Perl 5 is near perfect, there is nothing left to be developed there.

Some wanted better Perl with more consistent syntax. That's what Perl 6 is for. 5.10/etc are intermediate releases serving the purpose of facilitating future migration to Perl 6: some ambiguous constructs of previous version are gone in 5.10/etc.

I personally do not care much about 6th - I yet to find any pathological problem in Perl 5 which would persuade me somehow to move to next big thing. Perl 5 is well documented, has piles of modules and examples all over the net. I see no point to move from it.

Re:Great! Another language to learn!

[FooAtWFU]

qw(the list of strings operator) is awesome and is equivalent to a list of strings. The main complication of Perl data types: If the thing you're assigning to, or getting out, is an array, it starts with an @: @states = ("Alabama", "Alaska", "Arizona", "Arkansas"); (or if you don't like typing ",s all day long, @states = qw(Alabama Alaska Arizona Arkansas). If the thing you're assigning to, or getting out, is a scalar, it starts with a $: $states[0] eq 'Alabama' or $states[0] = "Canada". If you want an array reference, the reference itself is a scalar, and the thing you're pulling out is also a scalar because that's all you can put into arrays (which is why complex data structures are arrays or hashes with references to other arrays or hashes inside). $stateref = \@states; $stateref->[0] eq 'Canada'; $other_ref = [qw(manitoba vancouver tiajuana)]; @array_again = @$stateref; @array_again = @{$other_ref}.

And that's really all there is to it, unless you want array slices or something (and who doesn't? @threestates = @states[0..3]).... or getting those out of a reference (@{$stateref}[0..3]).

Oh, and hashes work on the same principle, but with % for the hash, {} for the indexes, () for populating the hash with an even-sized list, {} for the anonymous reference, and you can do @a_codes = @state_to_postal_codes{qw(alabama alaska arizona arkanasas)}

Re:Seriously?

[iggymanz]

and Perl use had dropped to 15% of its former level in the past five years because the perfect number of applications have been developed with it, there's almost no software left to write.

Re:*cough* *cough*

[A beautiful mind]

Perl probably has the best testing culture out there from the major programming languages, including Java on the list. Between TAP, Perl 5 core's large test suite and a myriad of test related modules it has automated testing well covered.

Did you know for example that when you upload something to CPAN, it gets automatically smoked on dozens of platforms and hundreds of different boxes, test reports sent to the author and assistance provided to diagnose platform specific problems if needed?

Manual testing is for the problems not caught by the huge array of automated tests.