Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Perl Programming

Perl 5.8.0 Released 254

Posted by pudge from the jhi-is-my-hero dept.
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.
This discussion has been archived. No new comments can be posted.

Perl 5.8.0 Released More

Perl 5.8.0 Released

Comments Filter:
  • I assume that the source only is released so far. Time to start porting it to HPUX! I wonder if this will fix problems with Oraperl on HPUX 10.20... probably not.
    • Oraperl? Or do you mean DBI + DBD::Oracle. oraperl, sybperl and all those other monstrosities have been unsupported for ages.

    • Re:Excellent! Now I have something to do at work : (Score:3, Informative)

      by Anonymous Coward
      I'm no coward, but don't want to spend time creatying an account (and remembering it) right now.

      perl-5.8.0 is now completely 11.00 and 10.20 HP C-ANSI-C and GNU gcc safe. There are more 'README' pieces about Oracle in README.hpux and DBD-Oracle's README's have been extended, and probably will be even more in the near future.

      I've already made a pa-risc-2.0 gcc version prepared for Oracle available on https://www.beepz.com/personal/merijn for HP ITRC forum members, and I cannot promise, but a 10.20-pa-risc-1.1 version is planned for the near future.

      BTW, I seldom read this forum.

  • Explanation of Pumpking (Score:5, Informative)

    by recursiv ( 324497 ) on Friday July 19, 2002 @09:35AM (#3916060) Homepage Journal
    patch pumpkin n. [Perl hackers] A notional token passed around among the members of a project. Possession of the patch pumpkin means one has the exclusive authority to make changes on the project's master source tree. The implicit assumption is that `pumpkin holder' status is temporary and rotates periodically among senior project members.
    This term comes from the Perl development community, but has been sighted elsewhere. It derives from a stuffed-toy pumpkin that was passed around at a development shop years ago as the access control for a shared backup-tape drive.
    • Good explanation...seeing as I had only a guess as to what that meant. I was especially confused when I read the typo at the end of the original post, "...and his merry band. Hugo van der Sanden is the new pumpking...". I'd much rather be a pumpkin than a pump-king.
  • Perl gets more and more features it is not designed for, making it potentially more and more ugly if you use all of them.

    Maybe it is time to dump Perl and start designing Berl = the Beautyfull Extraction and Reporting Language ;-)

    • Re:Time for Berl? (Score:4, Interesting)

      by Jeppe Salvesen ( 101622 ) on Friday July 19, 2002 @09:48AM (#3916132)
      It's been done. They are called Python and Ruby.

      Frankly, Ruby has a lot of promise. I've been toying with it, and it feels like a pretty good compromize between java and perl.
      • Ruby's a bloated joke. I don't want an object interface to literals.
        • > Ruby's a bloated joke. I don't want an object interface to literals

          I should feed troll posts such as above, but I can't resist. The entire gzipped ruby source code is 998k. That's small enough to fit on a floppy. Now how is that bloated?

          I've programmed in Perl for 4 years and Ruby for 1 year. Ruby has become the _only_ language I need to get the job done at work(writing data aquisition and analysis software at an environmental lab).

          Ruby's standard library is analogous to Perl's, and it's one-tenth the size. It's object system is extremely robust and mature. The fact that everything is a first-class object makes ruby great. It's consistent, and you're sitting here complaining about the fact that it does something right that almost all other Object Oriented languages do wrong! If you don't want to treat a literal like an object then don't, but don't confuse "well designed" with bloated.
      • funny, i find perl to be an excellent compromise between perl and java. but then i feel that way about any language and java. ok, maybe not cobol. maybe.

      • Re:Time for Berl? (Score:4, Interesting)

        by jdavidb ( 449077 ) on Friday July 19, 2002 @10:49AM (#3916581) Homepage Journal

        At Yet Another Perl Conference [yapc.org] this year there was a book auction [perl.org] to raise funds for Perl development. Tons and tons of O'Reilly, Manning, and other books, and not just Perl books. It was interesting to see where the interests lay. There were plenty of wisecracks and groans for Java, Python, and PHP books. (I picked up Learning Python for $10.) Interestingly enough, there was intense interest in the Ruby books, and no wisecracks. Went for a higher than average price, I believe.

        • I was there.. I remember when the python book was being sold.

          Someone: I thought python was an easy language. Why's the book so big?
          Auctioneer: Must be all the whitespace

      • I dig Ruby, but I don't see it as a compromise between Java and Perl. Not much like java at all really, unless all allegedly "OO" languages look alike to you. If I had to put Ruby "halfway" between two languages they'd be Perl and Smalltalk.

    • Re:Time for Berl? (Score:3, Informative)

      by axxackall ( 579006 )
      Maybe it is time to dump Perl and start designing Berl = the Beautyfull Extraction and Reporting Language

      Done. It's called BRL: Beautiful Report Language [sourceforge.net]

      • Beautiful: It is easy to write BRL code that is understandable and maintainable, appealing to a programmer's sense of aesthetics.
      • Report: BRL is particularly suitable for constructing output that is a mix of static and dynamic content, e.g. web pages, e-mail messages. Its greatest strength is constructing output from SQL databases, though it is useful for many other tasks.
      • Language: The full power of a general-purpose programming language is there, though you wouldn't know it from simple examples.
      It is based on Scheme, which makes the syntax extremely simple yet powerful.
  • "- New Threads Implementation: A new multithreading implementation called interpreter threads, or "ithreads" for short, is available, their use instead of the old "5.005 threads" is strongly encouraged. The major difference is that in ithreads any data sharing must be done explicitly."

    Does this mean when you use fork() you must define a variable as global? I didn't think it was possible to declare a variable as global other than a "$var = 0". Also, does any one know if after forking how would a child return a variable to the parent?

    • Re:Thread Question (Score:3, Informative)

      by ndanger ( 589194 )
      Fork() is for creating a new process. The Perl 5.8.0 threads uses the threads pragma to spawn threads. But Perl doesn't share all data by default, so variables must be declared shareable via variable attributes( $variable : attribute). Artur Bergman wrote a good synopsis [perl.com].

  • Request (Score:5, Insightful)

    by Anonymous Coward on Friday July 19, 2002 @09:54AM (#3916164)
    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 [perl.org]). 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 [perlmonks.com] :)

    - super ugly ultraman

    • Re:Request (Score:4, Informative)

      by asobala ( 563713 ) on Friday July 19, 2002 @10:21AM (#3916331) Homepage
      Well, when Perl 6 is released (a while yet, I think) you'll find radical changes to the regexps. See Apocalypse 5 [perl.com] for more information.
    • Two things. First, the newer perl camel book contains just about everything you need to know, so you could just reread the appropriate sections of interest there.

      Secondly, and more importantly, the way I've managed migration is to simply reread the man-pages. If you've ever read the perl man pages, they're rather nice. Most importantly, you'll recognize a lot of material from previous reads. Thus for each new version, I simply skim certain man pages (like man perlre).

      Next, I've noticed in the past couple releases, there's a man perl5005delta, and now perl56delta and perl561delta.

      In terms of man pages for reg ex's, each feature stands out, and you'll quickly come to learn the (xx..) commands. There are definately a couple that stand out in terms of usefulness: (?=..), ?!, ?<=, ?<!, and possibly ?>. These involve look head and behind assertions (and their negatives). The last one is a non-backtracking forward expression.. Great for avoiding nearly infinite backuptracking issues.

      And, in case you don't find a good collection of info. I'll throw this change.. "our" is now the global equivalent of "my". It replaces "use vars qw($x $y $z);". I say this because I wan't as much perl code to do this as possible.
  • From the announcement [perl.org]:
    Known Problems
    • Tied/Magical Array/Hash Elements Do Not Autovivify

    I never liked autovivified hash elements in the first place. It's such a pain in the butt to put a if (exists $hash{index}) before trying to access everything if I don't want autovivification. Don't take this as a slam against Perl, I love the language and the concepts, but there are a couple little nooks and crannies that ought to somehow be fixed. I say "somehow" because to do it with backwards compatiblity may be impossible.

    • Autovivification on access is seen as a bad feature, and it's intended that in perl6, there will only be autovivification on write. In other words if($hash{'index'}{'index'}==2) won't autovivify, but $hash{'index'}{'index'}=2 will. This is one of the design goals behind perl6, to fix those things which need fixing, but can't in perl5 because of backwards compatibility.

  • Cocoa bindings... (Score:2, Interesting)

    by dowobeha ( 581813 )
    Now if only Apple would get the Cocoa bindings for Perl cooked up, so I could back-end in Perl and GUI in Cocoa...
  • How do you decide whether to upgrade or not?
    (rand() < 0.5) ? (print "Definitely yes\n") : (print "Outlook cloudy\n");
  • Is it worth upgrading at this point? Does anyone, having used it, say its all that much better?

    Most of what I do is basic anyhow...so from what I've read, I'm not sure its worth an upgrade at this point. I don't think my projects would benefit that terribly much from it.

    • Re:Worthy upgrade? (Score:3, Informative)

      by Anonymous Coward
      It is definetly worth the upgrade. Some highlights from perldelta [perl.org]:
      • Perl's built-in sort should be about 20% faster on most lists
      • More accurate number representation
      • Lots of new modules and pragmas [perl.org], including, for all C fans out there, one that implements C's switch.
      And don't forget that this release adds Windows CE or "Windows Powered" or whatever MS are calling it now as a supported platform. Mobile Perl applications AHOY!

  • Easy upgrade (Score:2, Informative)

    by Plutor ( 2994 )
    For those with Perl already, the following is an easy way to download and upgrade:

    perl -MCPAN -e 'install J/JH/JHI/perl-5.8.0.tar.gz'

    • Re:Easy upgrade (Score:5, Informative)

      by bertilow ( 218923 ) on Friday July 19, 2002 @11:32AM (#3916858) Homepage
      perl -MCPAN -e 'install J/JH/JHI/perl-5.8.0.tar.gz'

      That should probably be:

      perl -MCPAN -e 'install perl-5.8.0.tar.gz'

    • NOT WORKING, please mod the working install up. (Score:5, Informative)

      by arnoroefs2000 ( 122990 ) on Friday July 19, 2002 @11:34AM (#3916877) Homepage
      Which is in this thread also.

      ( perl -MCPAN -e 'install perl-5.8.0.tar.gz' )
    • For some reason, whenver I try to CPAN anything else, the shell INSISTS on trying to update perl for me. I don't want perl updated. I just want my modules....

      Any way to supress this?

      • Re:Easy upgrade (Score:2, Informative)

        by chrsbrwn ( 14235 )

        You have an old version of CPAN.pm.

        Newer versions of CPAN won't try to upgrade Perl itself (or a few other critical dependencies, can't remember exactly which) unless explicitely requested (using a command like the one mentioned earlier in the thread).

        To fix this, you need to upgrade only your CPAN module (not bundle-cpan) before trying to install other modules.

        Example:

        # perl -MCPAN -e shell
        cpan> install CPAN
        cpan> reload CPAN

        Then you can use CPAN to install other modules, and it shouldn't try to install the new Perl. It might, however, refuse to install a new module version that requires or depends on the new Perl.

  • Uh, none of these comments are about the story (Score:4, Insightful)

    by Junks Jerzey ( 54586 ) on Friday July 19, 2002 @11:32AM (#3916864)
    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.
    • It's like arguing which pop band is better than another. Who cares? It's all opinion and hearsay.

      I haven't heard any of Opinion's songs yet, but Hear'Say definitely suck.
    • 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.

      Are we really supposed to believe that all languages are equally good/bad and that we might just as well choose any of them for any project? This is nonsense.

      Languages do differ in clarity, maintainability, readability, and many other features, and, in the end, this will lead to fundamental differences on average in the engineering quality of the code. Little science (AFAIK) has been performed to study the relative quality of different languages, but there is no reason to believe that it could not be studied in principle. Nor is there much reason to believe that there wouldn't be substantial differences between languages.

      --Mike

      • Are we really supposed to believe that all languages are equally good/bad and that we might just as well choose any of them for any project? This is nonsense.

        But quality is often a personal opinion. Some people hate Perl and Ruby, but love Python. Some people hate Python and Ruby, but love Perl. Some people hate Perl and Python, but love Ruby. How can you get anywhere in such discussions?
        • But quality is often a personal opinion. ... How can you get anywhere in such discussions?

          As I said, "science". For example, in principle, one could set up studies to observe the various qualities (e.g., reliability, maintainability, readability, etc.) of code written in these various languages. These can be objectively measured--it's not just a question of opinion.

          In practice, studies like this would be tricky and expensive to perform, which is probably why they're so rare. This doesn't negate the fact that languages can objectively differ in these properties.

          My personal opinion is that languages with lots of sharp corners [mathdogs.com] cause grave problems in practice. I've certainly seen it happen an awful lot. Nonetheless, until the science is done, it's just anecdote and guesswork.

          --Mike

  • ActiveState (Score:3, Interesting)

    by Flounder ( 42112 ) on Friday July 19, 2002 @11:36AM (#3916884)
    ActiveState Perl is still 5.6. Any ideas when it'll be updated?

    I run the scripts on Linux, but I do my coding on a WinAMD machine.

    • Re:ActiveState (Score:4, Informative)

      by hobbs ( 82453 ) on Friday July 19, 2002 @12:25PM (#3917239)
      ActiveState Perl is still 5.6. Any ideas when it'll be updated?
      ActiveState is already working on a 5.8-based ActivePerl, but the timeframe for release is not yet set (it will be this summer).
      • Cool. Hopefully they'll also update their PPM repository, where many modules are a year and a half old. Perl/Tk, for example, is two revisions behind.

  • Math class (Score:3, Funny)

    by FattMattP ( 86246 ) on Friday July 19, 2002 @12:47PM (#3917408) Homepage
    Silly Pudge. 5.10 is less than 5.8. Didn't you take math classes?

  • Regarding Perl Criticisms... (Score:5, Insightful)

    by Art_XIV ( 249990 ) on Friday July 19, 2002 @12:47PM (#3917416) Journal

    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++?

    • Untrue (Score:3, Interesting)

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

      On the contrary, if the choice was the developer's and he/she made a poor choice, that is very much a reflection of their (lack of) ability.

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

      Generally speaking, given the choice, a good programmer won't make a poor choice of language for a project. (We don't always have that choice, of course, but a good programmer knows the difference and will readily admit to suboptimal management constraints.)

      The maintainability of a language seems weakly related to individual languages.

      Most of the garbage code I see these days, both proportionally and in absolute terms, is written in Perl. I believe that this is due to design problems with the language itself [mathdogs.com], and due to the fact that the language is so popular, therefore drawing to it many unskilled programmers, and due to the compounding interaction of these two factors.

      Perl was there first, and Larry Wall deserves accolades for it, IMO. These days, though, is there anyone that doesn't cringe at the thought of having another bale of newbie Perl code dumped on them to maintain?

      --Mike

  • Binary incompatibility is beginning to be Perl's bane. Didn't FreeBSD remove perl from their base system because of this?
    • Huh?

      No, Perl was removed becuase it has started to become very bloated, plain and simple. 5, 10 or even 20 MB could be handled, but it is starting to get a little bit bigger. Plus the language bigots had crept in too...:)

      Atleast I got Perl in there, JKH and others were voting for TCL instead. (YUCK)

      When I added Perl to FreeBSD 2.0 way back when, it came in very handy for things which needed to be written. In this day and age, FreeBSD has started to take more and more things out of the base installation and allow people to add them back in via a port. Which I agree with, why does a web server need Sendmail installed???

      BWP

Slashdot Top Deals

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Close