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

Seriously?

[bsDaemon]

5.10.1 just came out like a week or so ago... there seems to be a slightly accelerated rate of Perl development lately, which is nice as it proves it's not a 'dead' language by any stretch... and with extensions such as MooseX::Declare, it really gives some of the more modern, OO-based dynamic languages like Python or Ruby a run for their money in their traditional sphere as well, I'd say.

and first post i think.

Re:Seriously?

[Thing 1]

I personally know of exactly one company that uses Perl at the moment, and that's only for text cleanup.

I call BS (or, less confrontationally, perhaps simply "you know of very few companies"). Microsoft uses Perl throughout their build environment.

Re:Seriously?

[Myopic]

I'm sure you are just being a wag, because obviously anyone concerned about the stability of a production system like that wouldn't make foolish mistakes such as changing the version of their runtimes or libraries or platforms.

You don't mean to seriously suggest that you would rewrite 50,000 lines of code rather than just, you know, *do nothing*, and not update anything?

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.

[Blakey Rat]

Ok, but why would that result in infinite recursion? Correct or not, that code still exposes a bug.

Re:who uses PERL

[FooAtWFU]

Also, the AirWave Management Platform is in Perl (with C/XS/etc as appropriate in certain places). It sells for thousands-of to millions-of dollars, depending on your licensing and support needs. It's basically the only wireless network NMS out there which supports multiple brands of access point (Aruba, Cisco, HP/Colubris, Meru, Proxim, Symbol/Motorola, Foundry...) and its main competitor is basically Cisco WCS, which only manages/monitors Cisco devices.

Perl's take on object-oriented programming seems a little "fake" to some people: "what? you just bless hash references into a package named with a string? that's crazy!" But it works, and it works fairly well, and it is in fact very well-suited to development in this wildly heterogeneous environment.

It would be better if it wasn't so huge

[trparky]

Perl would be a whole lot better if the damn interpreter wasn't so freakin' huge and didn't take almost fifty MBs of RAM to load. 50 MBs isn't that much to speak of unless you're not running MOD_PERL and you have several Perl scripts running at the same time and your poor server is brought to its knees.

Re:Perl has died in industry (mod away, kids)

[uassholes]

My attitude comes from frustration. When I compile a C program and statically link it, it just works. Better yet (at least in a lot of cases) when I "compile" (in the Java sense) a Java program, it not only "just works", it does so on a great many platforms (even Windows since the courts enforced MS to comply with Sun's Java licensing agreement).

But I gave up on Perl because CPAN never worked properly on Solaris (I know about the gcc version, don't get me started). So it seems after the Perl kids grew up, the next generation adopted Python. I'm sick and fucking tired of trying to figure out if a certain "program" writen in Python need to be run with Python 2.4, 2.5, 2.6, or what the fuck ever, but now there seems to be a new generation for which Python is your Dad's scripting language, so they're onto Ruby.

And when the Ruby kids grow up, what's next? Can't we have some software that if it runs now, it will still run ten years from now, like Cobol, FormTran, or C?

I'll bet you consider those to be antiquated don't you? And yet programs in those languages are being run all over the world to do serious stuff, and will be for a long time, and your OS may be written in one of them.

My first computer in the 70's had an interactive BASIC interpreter that was great for playing around with programing. The scripting languages that have sprung up since them are acestors of that BASIC interpreter, and must be very educational for the younger generation, but IMHO are not suitable for production software.

Re:Great! Another language to learn!

[mikehoskins]

OK, then there's Ruby. It preserves the best pieces of Perl, Smalltalk, Python, and Lisp.

Perl's `qw(one two three);` actually works in Ruby as `%w{one two three}` but many constructs are semi-close to Perl.

It is considered to be in the Perl family of languages but is a supremely cleaned up / ultra powerful OOP language, in the Smalltalk vein.

In general, Ruby is as pragmatic as Perl, if not more so. It has a cleaner, more readable syntax, and code is very/most often shorter than a Perl equivalent.

As an ex-Perler myself, I'm not looking back. Ruby is a far more powerful language, and I can read other's code (and even my code, 6 months later).

Ruby exceeds Perl in web development, a la Rails (or Merb). It comes with many "hackers' libraries" built in, such as Expect, Erb, and Net::. Ruby Gems has Rubyforge, Raa, and GitHub as sources, which are functionally similar to CPAN. However, Gems is cleaner, without all manner of compilation and portability issues (and less code rot).

Ruby's lambdas, open classes (monkey patching,) and method_missing() make Perl hackery look anemic and juvenile, by comparison. If you need a different way to program, try building a DSL in Ruby, which is similar in functionality to Lisp's macros, just without S Expressions.

In short, Ruby is a better Perl 5/6 than Perl 5/6....

Re:What do people use Perl for?

[AniVisual]

Molecular biologists and bioinformaticians use Perl extensively for manipulating databases of long chains of DNA and proteins. Perl excels in this regard, due to its string manipulation prowess.

Re:Great! Another language to learn!

[harry666t]

my @months = qw( January February March April May June July August September October November December );

How about:

months = "January February March April May June July August September October November December".split()

Python's full grammar specification fits on two pages of A4.