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

One potential use of lvalue subs

[Matts]

The Win32::OLE module has to do quite a few syntax changes to make it work like the VBScrypt or JScrypt implementations of OLE (the significance of this is in ASP use). However with lvalue subs this is no longer the case. Irritating VBScript things like:

Object.Collection('Key') = Value

Can now be implemented in perl using the very similar syntax:

$Object->Collection('Key') = $Value;

So I think lvalue subs will have a lot of uses. They will also go a long way to allowing overriding of all core functions, although that's still a way away yet (something python does far more elegantly than perl).

Re:PERL FUTURE FORTH FUTURE = QUESTION

[William Tanksley]

How many of you still program in FORTH?

I do.

And I disagree with every single thing you said there. I only had to read one book to understand Forth; furthermore, far from having a mess of inconsistent syntax, Forth has next to NO syntax.

Forth doesn't make solving hard problems impossible; it makes writing application-specific languages easy. You can then solve your problem in a language which is natural for solving it -- and one which may not look very much like Forth. That's not even remotely possible in Perlish or Pythonic languages (outside of going to ridiculous lengths, like building a parser and parsing a seperate file or comments).

Now, what does this have to do with Perl? I'm thinking that you're accusing Perl of being a fad, like Forth was in the early 80s. (And worse yet, a bad fad.) I don't think you have a leg to stand on here; not only did Perl manage to catch a MASSIVE growth spurt in the industry, but it has completely different characteristics from Forth in just about every way -- have you ever written a Forth compiler? How about a Perl compiler ;-)?

Now, I'm sure that Perl will die out; it has nothing to offer that isn't done better in other places, and the sheer mass of its syntax is already causing it problems. Forth is still around, in OpenBoot and OTA (EuroPay), but only because it offered something really unique -- a simple VM which the programmer could understand and write to, without first having to master a byzantine language (I'm sorry, but even UCSD Pascal is byzantine compared to Forth).

Perl seems popular among web monkeys and CS geeks. Forth is popular among engineers (I've also met a few mathematicians who like Forth, oddly enough).

-Billy

what's new in perl 5.6

[orabidoo]

looking at the main new features of perl 5.6:

• unicode support: it's a good thing, and not intrusive: it's off unless I "use utf8".
• lvalue subs: not really important; I can see it being used in methods, i.e allowing $object->method = $value, rather than the usual $object->method("value")
• improved threading, and win32 fork emulation. I dislike both threads and win32, so no comment. If peopel find it useful, it's good, I just hope it doesn't bloat perl too much when i'm not using it.
• improved perl compiler: neat, I wish it got to the point where it's usable in practice, though. bytecode production and loading seems to be 'almost there'; I'm looking forward to them.
• auto-vivification of filehandles: great. finally say goodbye to the Symbol::gensym kludge, for those cases where IO::* is just too heavy.
• weak references: neat idea, annoying implementation. I mean, it needs support in the core, so why not just make it part of core and have a 'weaken' func, instead of needing a special module?
• delete/exists on arrays: neat.
• lexical warnings: cool.
• 'our': I still think 'use vars' was perfectly good enough, and this is just added confusion.
• v1.3.6 strings: kind of worthless.
• large (>2GB) file support: good feature.
• improvements in 'use fields', typed object refs and pseudo-hashes: the idea is to make objects look like hashes (with fields in $obj->{keys}), but be actually implemented as (faster) arrays, with compile-time checking of what field names actually exist. I'll be using this.

Re:Unicode support

[FigWig]

Iconographic writing trades simplicity for portability. A system of writing wherein the rearrangements of the letters of the alphabet corresponds to the sounds (romantic languages for example) makes it impossible for a single word to make sense in different languages. Iconographic writing (chinese, japanese, etc) assigns a meaning to each character, but doesn't specify the sound. Thus the same writing can make sense to speakers of different chinese dialects (mandarin, cantonese, many others). Also the writing is accessible to Japanese & i believe korean, although each extends the icons with their own proprietary extensions. Makes sense if you were trying to make a unified script to manage your empire with if your empire extended over people with similar, but different languages.

ps - IANAL (i am not a linguist)

lvalues considered pain in ass

[Bob Ince]

Sure, it's interesting, but it's yet more bizarre syntax that is going to be hell to debug.

I agree. It's a feature that places more emphasis on the confusion between mutable objects and value types that seems to exist in most popular programming languages.

The problem is variables: sometimes when you write them, they get evaluated immediately (print a), and sometimes they only represent a reference. Perl is extending the range of situations where the latter occurs by allowing these lvalues to be returned from subroutines. I'm also not greatly happy with the way you specify that a routine returns an lvalue in the header of the routine rather than in the return statement it actually affects; I see this causing many bugs.

The solution in MOPL (My Own Pet Language) would be to make all variables objects, so that when you write their names it always means a reference to the object. And use constants instead of variables for holding immutable values to minimise use of variables.

Some functional languages already solve the value/object problem quite elegantly. ...by not having mutables at all. Hmm.

Anyway. I doubt this one'll tempt me to Perl; it's already got so many language features I haven't managed to learn yet, I don't need any more! Guess that's why I liked Python: I had picked it up, learned the language features, and starting writing production code in less than half an hour. But hey, I wouldn't want to start a Perl/Python flame war or anything. ;-) (After all, Python causes as much object-value confusion as any other language, when lists are mutables but tuples are not.)

--
This comment was brought to you by And Clover.

Feature bloat in Perl

[spiralx]

Am I the only one who thinks that the Perl team are trying too hard to make Perl all things to all programmers? I mean, Perl was designed to do simple scripting and text processing tasks, which it does well, but each new release sees some new "feature" tacked on to the end of the language without any real care over whether it is actually required or not.

Perl was never designed to handle classes, threading, lvalue subroutines and so on. I can understand the need for Unicode support - this is in keeping with the whole "Practical Exraction and Report Language" thing, but the rest seems unnecessary for what Perl should be. And unfortunately, Larry Wall et al., haven't never considered these issues in the first place, have added them to the language with little or no care or elegance.

What Perl needs is a bit of a rethink - go back to the core of what it is supposed to do and make sure that it does that as easily as possible. It doesn't need object orientation or threading - they are extraneous and bloated. Unfortunately, at the rate Perl's bloat is increasing, it'll soon be the Visual Basic of the *nix world, with plenty of "cool features" that nobody needs.

Re:Feature bloat in Perl

[buzzcutbuddha]

To only look at Perl as a scripting language is to discount a lot of good and well implemented features in Perl. Just because you don't need them does not mean that no one needs that feature. If there is a need for a feature, why not include it?
I have used VB, C/C++, Python, RPG, COBOL, and Perl and I have not seen a language that wraps everything I need for systems administration and reporting, etc into one powerful package.
And as far as threading is concerned, Perl is using threading in Win32 to allow ActivePerl emulate the fork command from *nix. That is something that should exist (free-threading is available in VC++ for all Win32 platforms), and I'm glad that I finally have it at my disposal.
Anyway, a rethink of Perl has been underway for a while. Look up the Topaz project.

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: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.

Lvaluable Subroutines

[IO ERROR]

This isn't intended as flamebait, though it might sound like it. That said, I'm trying to grok these new features...

From the department of bizarre syntax, subroutines can now be legal lvalues; that means they can be assigned to. Of course, this only works if they return something assignable, and if they're marked as an lvalue subroutine.

Took me a few minutes, but I finally got my head around this one. Sure, it's interesting, but it's yet more bizarre syntax that is going to be hell to debug.

mysub(2) = 15;

Without looking at mysub(), how in the hell am I supposed to know this assigns to $a? So much for the "black box." This violates just about every precept of good programming practice I can think of. Not that it won't be useful; in perl, anything can be useful...

This is yet one more reason I am going to stay as far away from perl as I possibly can. I like to be able to maintain my code. And sometimes I have to maintain other people's code. Things like this will make maintenance a complete nightmare.
---

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!)

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....

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.