Perl 5.8.0 Released

twoshortplanks writes "The latest version of Perl has been released, with new features such as better Unicode support, a new threads implementation, new IO layer support, and a whole plethora of bundled modules - plus a wonderful collection of regression tests and new documentation. The release notes and links to mirrors for download are on dev.perl.org." This is not a release candidate, it's the real thing, representing over two years of work by patch pumpkin holder Jarkko Hietaniemi and his merry band. Hugo van der Sanden is the new pumpking for perl 5.10.

Comments

Re:Will it enforce readable code?

[spottedkangaroo]

good coders can write readable code in any language. bad coders cannot. So just what are you saying?

Re:Will it enforce readable code?

[lamp77]

Feh.

I think it's easy enough to write readable code in perl, the great thing is that you have the option of writing horribly unreadable code to do in 3 lines what it would otherwise take 10 to do.

Request

[Anonymous Coward]

I learned perl using 5.0.0.5, or somesuch. I learned using version 2 of the Perl Book.

It seems to be the case that the perl language has actually evolved a bit since 5. I am continually finding out about "new" features in Perl that i were not aware were there (invariably, the only ones that make a difference to me are the extentions to the Regexp system: there seems to be a whole class of (?X) operators that are not in my copy of the perl book).

Is there anywhere that summarizes the various changes to perl since version 5? there are the perldoc perldelta documents (here is the perldelta document for 5.8.0). However, these are complete, technical changelogs, and cover everything from language changes to small inconsistency smoothings to changes to obscure library functions to bugfixes in internal perl functions. Moreover, they do an even poorer job of explaining the consequences to the coder of things like (?>) than the perldocs :) It seems it would be a useful community project if someone were to take these changes and compile them into a sorted by type document-- I.E., all grammar changes, then all regexp changes, then library functions, etc., with sample code where germane.

Really, now that i think about it, i guess what i would like is a summary of what they've done to the regexps since version 5.0 :)

If no such document exists, maybe someone can write one and post it on PerlMonks :)

- super ugly ultraman

Re:Request

[Anonymous Coward]

Well, that's the interesting part. A lot of the changes in the perl 5 regexps have the end result of moving toward perl 6. I mean, you can definitely see that there is a logical progression of ideas from the perl 5.6 and 5.8 RE extentions toward the perl 6 regexp system.

The things that the 5.x (?X) "extentions" did have now become deeply integrated parts of the perl 6 regexp engine: named subpatterns ("rules"), embedded code assertions, and the "::" abort are the most important part of the perl 6 extentions, and they all had clear descendents in the things that have been added to perlre since 5.005...

Now, if only i understood how to use them effectively.. :)

P.S.: Please note that if you want to try to wrap your head around this perl6re beast, in addition to asobola's link it may be good if you looked here and here. (The first is a summary/reference of the apocalypse changes, the second is some neat sample code in which an elegant XML validator is created using perl6re)

-- super ugly ultraman

Re:Will it enforce readable code?

[Anonymous Coward]

Good coders use "ugly" pointers that scares C++ coders away.

Yes, you'd never see

Object *pointer=new Object("foo");
pointer->Method1();
pointer->Method2(1);
delete(pointer);

Oh, wait. Yes you do.

Re:Will it enforce readable code?

[Neil Watson]

The fundamental point of perl is its a quick way to write one-off scripts to do quick repetitive jobs - therefore maintainable code is not necessary.

I could not disagree more. I keep a copy of all interesting scripts I write. I often give them to friends or peers. In addition, I may not look at a saved script for some time in the future. Well written, documented code is key to being able to remember just what it was that you were doing and communictating these ideas effectively with others.

Uh, none of these comments are about the story

[Junks Jerzey]

I see people bashing Perl for it's supposed unreadability. I see people bashing Perl so they can advocate Python or Ruby. I see people making general, blanket statements about code readability, as if these opinions are always ready to burst forth, making the speaker a hit at parties.

Arguments about programming languages on this level are pointless beyond belief. It's like arguing which pop band is better than another. Who cares? It's all opinion and hearsay.

Regarding Perl Criticisms...

[Art_XIV]

First off, let me state that choice of programming language isn't a reflection of the abilities of a developer.

I've seen dedicated, talented developers produce great apps with Perl, Python and even (gasp!) pre-.NET Visual Basic. On the other hand, I've seen careless, uninterested developers produce mounds of pure, unadulterated crap with C++.

The language used has little to do with the quality of thefinal result, and has a lot more to do with the person coding with it.

The language used for a product often isn't even up to the developer. Employers and clients mandate a language as often as not, sometimes for valid reasons, sometimes for moronic reasons ("The CEO plays golf with this dude who told him that using Java is gonna save big bucks").

Let's look at three factors we can use when comparing languages: Performance, Development Effort Required, and Maintainability.

C++ is a great language in experienced and knowing hands. When well-done its performance is good but it tends to be very effort-intensive.

Perl and other very high-level languages are less effort-intensive, but they have a corresponding performance trade-off.

Java and .NET languages are somewhere between the two, though they both seem closer to C++ on the scale than they are to VHL languages.

The maintainability of a language seems weakly related to individual languages. Most of the maintainabilty qualities of a product will spring from the all-too-often overlooked Planning, Design, and Discipline of the developers that worked on it!

I'll allow that Perl can really let you shoot yourself in the foot as far as maintainablity goes, but what languages aren't like this? Especially beloved C++?

why are brainfuck and machine code unreadable

[dgym]

to oppose some claims that the only reason brainfuck and machine code are unreadable is because the reader doesn't know HOW to read it I will go into why they are inherently less readable than some other languages DESPITE being able to read them.

thankyou elflord for already getting the point ;)

at one level brainfuck is extremely easy to read, it only has 8 characters, each of which corresponds to one of 8 simple to understand operations. Anyone could learn to read off the code operations given 10 minutes because there isn't very much to learn. brainfuck is still inherently unreadable because it is very hard to work out what a peice of code's functionality is when only given a list of low level operations. In brainfuck there are no function names to give a big clue as to what the function does, there are no variable names, and there are no comments.

Just imagine trying to write readable code in perl if you were forced to call all your functions f1, f2, f3.... and all your variables $v1 $v2 $v3.... and you are not allowed to create any comments, and you have to build your own strings at run time too, none of these abstract types thank you. Just to finish off remove all the whitespace from your perl script and tell me if it is readable. brainfuck forces all of those points, so although the operations are very readable, the functionality isn't.

machine code is also quite readable, it is perfectly possible to learn how to read machine code, but it is much harder to read machine code than it is assembly. Again this has nothing to do with the posibility of learning to read either, it is infact purely based on how quickly you can read them. There is a one to one translation between machine code and assembly (apart from label names)
but whereas I can read an assembly op in well under a second, I would have to spend a fair amount of time deciphering which op code is being used, with which options and registers and data. Even if I knew everything I needed to know to work out what the instruction is, I am still having to calculate it each time I read a code. In variable length instruction sets I have an even worse time as although I can see one assembly instruction followed by another, and I can simply skip looking at a few I am not interested in, in the machine code I have to work out every instruction before I know where the next intruction begins.

Now, for a stupid example that knowing how to read two languages does not imply equality in ease of reading them, as appropriate for a comparison of assembly to machine code: I pick english for one language and english with each letter offset by one for the second, so that 'a' is translated to 'b'.

The languages are almost identical, and you have been given everything you need to know how to read both, but how long does it take you to READ AND UNDERSTAND e"readable" compared to e1"vosfbebcmf"?

machine code is harder (but possible) to read because you have to work more things out than you do with assembly.

brainfuck is harder to read than C like languages because you don't have any names or comments to give you clues as to the functionality. If you wrote C with random function names, random variable names, no comments and agreed to never use any number except 0, and never use any strings then your code would be on par with brainfuck : but brainfuck manadates this style, which is why it inherently difficult to understand.