Perl 5.16.0 Released

An anonymous reader writes "Perl 5.16.0 is now available with plenty of improvements all around. You can view a summary and all the change details here. With Perl on an annual release schedule, and projects like Mojolicious, Dancer, perlbrew, Plack, and Moose continuing to gain in popularity, are we in the middle of a Perl renaissance?"

Comments

Whatever happened to Perl 6?

[BitterOak]

I love Perl, but I'm curious. Whatever happened to Perl 6? I remember hearing about it way back when I was in grad school, which was a long time ago.

Re:Whatever happened to Perl 6?

[vlm]

became moored in WIP status for the last 6-x years.

12 years, not 6.

The killer is no one in the perl dev community wants it. This says it all "Backward compatibility with earlier versions of Perl is not a goal". The problem is I don't love perl because of its syntax, although some of it is pretty cool, I love it because of the CPAN which does all my work for me. All my problems seem to be solved by combining at most ten or so CPAN modules. Its kind of like how the whole world is built out of only a hundred or so elements... if I wrote a perl program that used 100 CPAN modules, the result would be a new universe would spring into being, like the big bang. Or something like that.

Re:Whatever happened to Perl 6?

[chromatic]

... part of the problem I think is that perl 6 is not ANYTHING like perl 5.

The parts of Perl 6 I like are a lot like Perl 5, and the parts I really like are much better than Perl 5.

... the only reason I still use perl 5 TO THIS DAY is the regex capabilities. They completely ripped that out of perl 6 and re-implemented it to make it more user-friendly, and they did so poorly, IMHO.

I like Perl 6 grammars far, far more than I like Perl 5 regex. That's one of the best parts of Perl 6. Regex as borrowed from Unix and enhanced over the years have accumulated a lot of mutually incomprehensible cruft. Perl 6 cleans that up.

The problem with Perl 6, of course, is that no implementation is anywhere close to practically useful. Almost twelve years after the Perl 6 announcement, there's still no reason to hold your breath.

Re:Whatever happened to Perl 6?

[zmughal]

As far as the matching capabilities of Perl 6, I think they're trying to do something that will advance the state-of-the-art in terms of programming langauge integration in the same way that Perl 5's regex did. The Perl 6 rules are similar to the tricks and hacks that people do with regular expressions to build up full grammars. By separating out the parts into logical components, you will get better readability and reusability. Not only will we get cleaner text processing, but this (along with the VM architecture) will aid the development of DSLs that will extend the language into an exciting future.

Yeah, it's some good Kool-Aid and the Perl community been waiting for a while, but bringing these ideas into a production-ready language isn't trivial. I'm still using Perl 5 because of CPAN, but I feel that Perl 6 will eventually get to the same level especially with a source-to-source compiler. The hardest part would be dealing with native-code bindings.

Re:Hard to get started

[vlm]

Well that was embarassing. you don't want to see projecteuler.com. Try

http://projecteuler.net/

that works a heck of a lot better.

Perl's strength

[Okian Warrior]

Perl's strength is that it's expressive. It's not a language which is easy to learn or which generates heavily optimized code.

In the demo phase, you're not really worried about performance. The goal is to have something showing as quickly as possible, and not worry too much about how fast it runs, or how much memory it takes. Overspec your demo system for the time being (ie - make it really fast and install lots of memory), and once you have a reasonable interface go back and recode it in a simpler language which can be more easily optimized.

Languages which are simple to learn (c++, for example) are generally not very expressive. You end up wasting tons of time debugging issues of memory allocation, library interface details, and datatype conversion.

Languages which are expressive are a little harder to learn, but any individual line in the expressive language does a lot more. Since you are writing fewer lines, and since the fewer lines do more, you end up making programs more easily and in less time.

Yes, the programs will execute a little slower, but as mentioned, this is not important in the demo stage. Your productivity will be much higher.

And there are lots of places where performance simply doesn't matter. Scripts usually fall into this category.

Perl was written by a linguist, not an engineer. As such, it's harder to learn (it's got tons more keywords and context), but once you get the hang of it it's much more expressive. The following single line:

@Lines = sort { $a->{Name} cmp $b->{Name} } @Lines;

unfolds into several lines of C++, plus a subroutine definition with datatype definitions. The following line:

@Files = <c:/Windows/*.exe>;

can be implemented using one of over a dozen possible library calls in C++, but is builtin in perl. You don't have to look up the library call interface specific to your system.

Re:Perl's strength

[Anonymous Coward]

Well put. Except perhaps for the part about C++ being "easy" to learn. C++ is a fucking mess.

Re:Perl's strength

[skids]

In other words, Python is just like Perl, only it is readable and makes sense.

Funny, I found the perl easier to read.

calls C/C++ libraries

[bzipitidoo]

Ultimate glue? That's why I'm interested in Perl 6. It's supposed to be able call C/C++ library functions directly. No more need for wrapper libraries, which is the majority of CPAN. No need for SWIG, which I find bloated.