Slashdot Mirror
Perl New Version 5.5.660
aarestad writes, "Just saw this on perl.com:
the new beta leading to perl 5.6. Read the
announcement."
It's mostly bugfixes. Pumpking Sarathy says we're on track for a 5.6 final release candidate by Feb.28.
← Back to Stories (view on slashdot.org)
TCL 8.3 was just release a couple weeks ago too. TCL is a competitor to Perl which I happen to love. Not trying to start a flame war here!
If tits were wings it'd be flying around.
Which version(s?) of perl does Slashdot run with?
only 6 thousandths away from 5.5.666!
Note:
I mean, why all these release updates?
Bjarne
Yes. It came from a project called "Blacker" project. Here's the Linux Magazine article where he states that.
This is just a bugfix release. As a rule, new versions will almost *never* break compatibility with older versions. Only certain M$ products *cough*Excel*cough* do that.
Each version, a few things might be dropped/added. But usually the archaic forms are kept for a few releases until everyone's migrated.
void recursion (void)
{
recursion();
}
while(1) printf ("infinite loop");
if (true) printf ("Stupid sig quote");
Friends don't let friends misuse the subjunctive.
(I can't find Tom's Perl->Slashdot formatter, so make whatever you can of the script below.)
:object.property :object.method()
' .$2.$3:'$'.$1.'->{'.$2.'}'}egi;
#!/usr/bin/perl -w
# a filter for enabling C++-looking "OO" style in Perl.
# not tested; have no idea if it works; probably clashes with about a dozen other forms. As usual, provided without any warranty. Heh.
# syntax:
#
# => $object->{property}
#
# => $object->method()
while (<>) {
s{:(\w+).(\w+)\s*([\([^\(\)]*\)]?)}{$3?'$'.$1.'->
print;
}
Happy now?
To the editors: your English is as bad as your Perl. Please go back to grade school.
For those who want to know what is actually new in Perl 5.6, you want to look at perldelta . (The message linked to above is just what was new since the last beta).
Eventually I'll have to learn Perl. But I might wait for release 6.6.666, so that it runs on Windows properly. ;)
:)
Seriously, though, I think this is news, because Perl hasn't changed version numbers in a while. I guess this'll be cooler when it's a stable version, but...
Remember, Linux, Apache and Perl are always news here, because Slashdot runs on all three. And if Slashdot ever tackles that "slow under load" problem, that'll really be news!
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
As with the other posters, I recommend "Learning Perl" (The Llama book), from O'Reilly and Associates. I also recommend, even if you're just learning, that you also have a copy of "Programming Perl", also from ORA (The Camel book). It is a nice reference to have, if you're curious about more information that the Llama book doesn't offer you.
HTH.
This is my
This is my
--An Oldie, but a Goodie!
As was pointed out there are a number of changes. This is not just a bug-fix. The biggest new item is Unicode support. If you have to do things like match patterns in multi-byte character sets, this will be really cool. If you don't it will still be a nice feature since a lot of things (eg the web, file-systems, etc) are moving towards Unicode as internationalization becomes more and more important.
:-)
The biggest "missing features" continue to be solid multi-threading, compilation, and solid 64-bit support. If you want the first one, rethink whether the fork model works. If you want the second think about embedding an interpreter. If you need the third I suggest getting used to opening pipes to and from programs that can handle large files...
A "cool feature" that was discussed (I have ignored the Perl development list for the last half year so I don't know if it is in) was embedding Perl and a directory structure in a zip format. Imagine shipping an executable which had an encrypted zip appended which was Perl, with your scripts, and a directory structure of all of the modules your script used...
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Start with Mastering Regular Expressions by Jeffrey Friedl. This book is superior to Learning Perl because it will teach you skills that will apply to all languages and utilities. This book starts from the very basics of using regular expressions.
Next try Advanced Perl Programming by Sriram Srinivasan. This will introduce the higher level concepts of Perl that will explain what about Perl makes it suitable for various tasks.
Before one can use Perl effectively one must wade through a substantial fraction of its excellent man pages. Actually, Perl's man pages are written in its own lightly marked up documentation format perldoc which can be translated into man pages, plain text, html, whatever. I read it "straight" by downloading the latest development Perl source.
Perl is basically a fusion of the C library functions and Unix system calls with excellent abilities to handle regular expressions. For this reason is is quite probable that one can learn more about actually using Perl by reading W. Richard Stevens book Advanced Programming in the UNIX Environment then any beginners Perl book.
For my money if one had only about 40 US dollars to spend on one Perl book, I'd get Tom Christiansen and Nathan Torkington's Perl Cookbook and try to make do learning from the Perl manpages.
How can I compile my Perl program into byte code or C?
Malcolm Beattie has written a multifunction backend compiler, available from CPAN, that can do both these things. It is included in the perl5.005 release, but is still considered experimental. This means it's fun to play with if you're a programmer but not really for people looking for turn-key solutions.
Merely compiling into C does not in and of itself guarantee that your code will run very much faster. That's because except for lucky cases where a lot of native type inferencing is possible, the normal Perl run time system is still present and so your program will take just as long to run and be just as big. Most programs save little more than compilation time, leaving execution no more than 10-30% faster. A few rare programs actually benefit significantly (like several times faster), but this takes some tweaking of your code. You'll probably be astonished to learn that the current version of the compiler generates a compiled form of your script whose executable is just as big as the original perl executable, and then some. That's because as currently written, all programs are prepared for a full eval() statement. You can tremendously reduce this cost by building a shared libperl.so library and linking against that. See the INSTALL podfile in the perl source distribution for details. If you link your main perl binary with this, it will make it miniscule. For example, on one author's system, /usr/bin/perl is only 11k in size!
In general, the compiler will do nothing to make a Perl program smaller, faster, more portable, or more secure. In fact, it will usually hurt all of those. The executable will be bigger, your VM system may take longer to load the whole thing, the binary is fragile and hard to fix, and compilation never stopped software piracy in the form of crackers, viruses, or bootleggers. The real advantage of the compiler is merely packaging, and once you see the size of what it makes (well, unless you use a shared libperl.so), you'll probably want a complete Perl install anyway.
(back to me) I also noticed GNU/Hurd is now supported. Hmm.. mebbe it's time to try that (the Hurd) out.
Lots of people will recommend 'Learning Perl', but I strongly recommend not buying that book. Unless you have problems falling asleep, then this book will be useful. I would recommend Nigel Chapmans "Perl: The Programmers Compagnion", a truely excellent book - specially if you already can program in another language. Half of the authors of Learning Perl prefer Nigel Chapmans book.
I've heard good things about Andrew Johnsons "Elements of Programming with Perl". I haven't read the book yet though, so I hesitate to recommend it. On the other hand, it mentions my name and discusses some code of me... (of course, that could be held against the book as well).
After learning Perl, it becomes more difficult. There are a lot of Perl books, but most of them are just a waste. I've more than 15 Perl and Perl related books in my bookcase, but there are two I've actually found useful: Mastering Regular Expressions, and The Perl Cookbook. The former is three years old, and hence doesn't discuss any of the new and advanced regular expression stuff though. But it gives a great insight on how to avoid writing inefficient regular expressions. But the best Perl book remains the Perl Cookbook. Despite it being an O'Reilly book.
-- Abigail
If you read the whole original announcement, you find among other things, renaming "byte::" to "bytes::". Do you call this a bugfix? And what exactly is "default mkdir() mode argument to 0777"? Changing default mode arguments is definitely *NOT* a bugfix. Fixing a memory leak is a bugfix, but what about "generalize "%v" format into a flag for any integral format type: "%vd", "%v#o", "%*vX", etc are allowed"?
The reason I asked is because I have some doubts about the way Perl is evolving. When I used it first, about eight years ago, it seemed to me a pretty cool little language, but I never had the chance to use (and learn) it more extensively. A couple of months ago, I bought "The Perl CD Bookshelf" from O'Reilly and was surprised with all the features that had been added to Perl. Adding unneeded features is the quickest way to add bugs to a system. Look at the MS-Office or MS-Windows releases for the last ten years or so for further examples.
Seeing this announcement, if you only read the slashdot homepage, you think it's just bugfixes. If you go further and read the "announcement" itself, you see it labelled as a "development version", with "mostly bugfixes". Well, as I see it, if you are developing, you are not fixing bugs, you are adding new features. With new features come new bugs. Looking further, at the "original announcement", you need to be a Perl guru to understand all the notes.
I really like the Linux system, having a set of versions for adding features and a separate and parallel set of versions just for bugfixes. Although this system is sometimes not followed very religiously, it's an excellent basic principle. So, my original question still stands: is this version intended for fixing bugs or for adding new features or a little of each? Are they adding new bugs to Perl faster than they are debugging?
This rather long comment could have been avoided if you did what you preach and had actually read the whole original announcement. Clueless moderator, clueless AC, perhaps they are the same?
Moderators, take note:
1)Read the moderation guidelines before moderating anything
I'd trust what Mark-Jason Dominus said or what Tom Christiansen said about the Perl for Dummies book.
I haven't looked at it yet, but I've heard good things about Elements of Programming with Perl. I've also been told that MacPerl: Power and Ease does a good job of teaching perl programming as well as teaching the MacOS specific areas of MacPerl.
This is exactly why computer books are expensive. If you make "Milking cows for dummies", you've got a high upfront cost (writing the book), but you can make that back over a long period of time, as cows in 1990 are the same as cows in 2000 and 2010.
On the other hand, if you make "Cowsoft Milker 2.0 for dummies", then you have the same upfront cost, but you can only sell the book until Milker 2.1 comes out. Sometimes you can revise the book, but this is an additional cost.
Well, that book put me to sleep, but I then handed it to a colleague who needed to learn perl, and never did get it back. For what it's worth, that person was an intelligent non-programmer. Apparently that book ended up on a Great Journey and has landed on the desks and shelves of many people just like my so-called, book-stealing friend.
I think the only perl books I don't have now but might want (I have these two) are Perl in a Nutshell (looks like a really handy reference) and possibly Object Oriented Perl, because it was written by Damian Conway, whose papers and projects I have found very useful in the past.
Babar