What's New in Perl 5.6.0

Simon Cozens writes "I've written a summary of what's new in the 5.6.0 release of Perl for this www.perl.com article. " The article does a good job of evaluating what's come out - worth reading if you're a Perl Monk

Comments

Re:Feature bloat in Perl

[Matts]

I think you're not the only one, judging by the python luvers who have moderated you up ;-)

But are you saying that a language designed to do one thing should forever remain just to do that one thing?

You think perl's OO features aren't elegant. I think the opposite - they so neatly fit into the language that it's hard to believe that they are so simple (bless $ref; # whoaa - it's an object now).

Perl does need a _bit_ of a rethink, but that rethink won't be to reduce perl back to just a reporting language - it will be to make perl more powerful. To provide threading or multiple interpreters from the ground up. To provide exceptions built into the core. To make compiled extensions a bit easier. To make classes have named attributes (not the monstrosity that is "use fields"). To make signal handling safe.

These things are being thought about, and are being dealt with, but don't expect miracles any time soon.

Re:More confusion

[henley]

I know I ought to leave this one alone.. I mean the clue is in the misspelling of the One True Religion...er....language name.

But it does allow one to re-iterate the point of the language:

Perl - The Swiss Army Chainsaw of Languages

If you want "clean", "pure" or "compact", move along there's nothing to see here. If, however you're a bit of a divv, programming wise (I'd certainly own up to this one), and/or you don't get the time you might like to code those C/C++ monster environments, and/or you have a job to do *now*, then the extreme feature-itis of Perl may well be for you...

Perl is *definitely* from the same stable of thought that brought you the UNIX environment - give 'em a toolkit and let 'em write their own apps... Except this time the toolkit is embedded within a language, which makes it usable on many platforms.. I've written scripts on AIX which I was able to successfully port to Linux, NT and even OS/2 using a simple "translation" tool - FTP. No source code editing for me, oh no.

And now if you excuse me I note that since I can now run Perl on my Psion, I feel the need for some serious mobile scripting coming on.

With apologies to the rest of the /. crowd for feeding the troll....

Re:Feature bloat in Perl

[jbert]

I'm not surprised you think this if you look at perl as the "Practical Extraction and Report Language". Or as 'just' a sysadmin tool.

What perl is today is the ultimate glue language. Via the modules available (both those shipped with perl and those available via CPAN) you can interface to practically anything (Most network protocols, data formats, APIs, etc etc)

To be honest, 'bloat' in the language is only important for two things:

1) Performance. This is fair enough, lighter interpreted languages will (probably) start up faster. Once the interpreter is running, though, I don't see why an (unused) language feature will impact execution speed.

Also, "premature optimisation is the root of all evil". Most perl scripts are 'fast enough'. Those that are performance sensitive (e.g. CGI under Apache) can generally be speeded up (apache mod_perl).

2) Language breadth. This issue seems to be alluded to by people elsewhere in this dicussion. The mindset appears to be "if a feature is in perl then I'll have to learn it to be able to maintain perl". I can understand why feature bloat is a worry if you think this.

Perl has a huge feature set. The key thing to understand is that you DON'T NEED TO KNOW THE WHOLE LANGUAGE (sorry for shouting, its my main point and this is a long comment - wanted to make it stand out ;-). I think there is a Larry Wall quote along the lines of "Perl's learning curve isn't steep, but it is long".

The point here is that you don't need to know that there is a language feature which will do your job in one line. If you know, you'll use it. If you don't know, you'll write 10 lines of perl instead. (or 50 or so in C to do the same job).

If you are maintaining someone else's code and they use a feature you don't recognise then you may need to look that up (the docs are good + install with perl). But the set of features you need to know is still not the whole language, its just the set of features which the author used.

Lastly, the number of features which can be abused to write unmaintainable code isn't really relevant. If a coder is sadistic enough to write unmaintainable code they only really need one or two language features (which all languages have).

Perl is not a panacea. However, instead of thinking "use the (one) right tool for the job" and learning C, C++, perl, python, java, scheme, eiffel etc, use "a good enough tool for the job" - which is often perl. Its easier to write in perl all the time and use a new feature than it is to learn a whole new language for every task.

Phew. Rant over.

Well _I_ happen to like Perl.

[zCyl]

I've been coding for about 15 years, but never bothered to learn Perl until a few weeks ago. I can tell you I'm sufficiently impressed with the language. Certainly, it has the power to be cryptic, but it's not as if "features" of other languages don't offer you an equivalent level of too much power (e.g. #define, the champion of obfuscated C/C++ contests).

So why do I like perl? Because it has many of the most useful language constructs integrated into its general semantics in a way that other languages don't. In Java you can declare a stack object, in C++ w/ STL you can easily declare a stack object, but in perl, you just use push and pop and the stack is there. In perl if you want to treat something as a stack, and then as a queue, and then as an array, it's elementary.

Anyone who has ever looked at a unix configuration file can't dismiss the usefulness of perl's split function, and the simplicity it provides by splitting files into lines, lines into subsections, and sticking it all in arrays, stacks, or queues with arbitrary lengths, and all done with no effort, and a tiny section of code, in perl.

I shouldn't even need to mention the potential beauty and simplicity of regular expressions (in the hands of someone who knows how to comment!). In my most recent application I needed to split the unix mail spool file into separate emails, it was elementary using regular expressions in perl, since I could make one regular expression to detect the well-structured From line at the beginning of each email. The corresponding C/C++ code would have been quite large and complicated, and the corresponding Java code would have taken 14 packages, 32 regular methods, and 704 getter/setter methods.

The other great thing about Perl is that because of the way things like split, foreach, etc are so naturally integrated, you can usually avoid the most common programming errors. After 15 years, the things that still trip me up in a program are the stupid things. A null pointer error while traversing a data structure, or an off-by-one error while comparing something or interating something. You can't have an off-by-one with split or with regular expressions, since Perl handles the grunt work for you. You basically just tell it what you want it to do in condensed form, and it figures it out.

My biggest gripe with perl is that there seems to be no mode to require variables to be declared beforehand. I really despise when I'm coding and do something like:

my ($fileName) = "/etc/blah/blah.cfg";
if ( $filename =~ m~^/etc~ ) { print "This is in /etc\n");

In most languages, this would trigger a compile error since filename has never been declared, and you would say, "Oh, whoops, I meant to put fileName there", but since perl lets you declare filename in the middle of the if statement, it just makes a new variable. Fine, if you want to program in basic this is useful, but I want to turn it off because I prefer to maintain my sanity. If anyone knows a way to do this, please post it.

All in all, perl is a promissing language. I don't expect it to take any flying leaps in popularity or make any great paradigm shifts due to the level of detest some people have for it, but I know I'll continue to use it for the things it is well tuned for. It's the best tool for a great number of jobs.

Re:Lvaluable Subroutines

[ratbag]

Does the presence of unusual constructs mean that Perl code cannot be maintained?

We often see the accusation that Perl is unmaintainable: I suspect that the blame lies with the coders, rather than the language itself.

Perl has a very handy construct that can render almost all code highly maintainable:

#
# it looks like this
#

Any language can be the source of unmaintainable code; it's up to us to use the power of the language in a sensible way.

Your example (mysub(2) = 15) is unmaintainable, but I suspect most sensible coders would have called the function something clearer than "mysub". And if necessary they may even have put a clarifying comment next to it.

Rob. (C++ and Perl coder, with an occasional dash of Python - Zope rules!)