Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Perl Programming Announcements Upgrades

Perl 5.8.1 Released 144

Posted by CowboyNeal from the new-and-shiny-camels dept.
langles writes "Perl 5.8.1 has been released. Read the official announcement, then download it from a CPAN mirror near you. If you've been following the Perl5 Porters List, you'll know this version was very well tested before they released it. However, there may be some modules that will need to be fixed before they will work with this release." The announcement also contains full details on incompatibilities and known issues, so give it a once over before upgrading, especially if from a pre-5.8 version.
This discussion has been archived. No new comments can be posted.

Perl 5.8.1 Released More

Perl 5.8.1 Released

Comments Filter:

  • Already.... (Score:2, Funny)

    by Anonymous Coward
    Damn, Slackware 9.1 is out of date already...

  • This is good news (Score:3, Interesting)

    by Sh0t ( 607838 ) on Saturday September 27, 2003 @10:02AM (#7071934) Journal
    ...as I've encounted a few script problems with the last few perl incarnations. Could have been the libraries however.

    But I have an honest confession.

    Python has become my scripting language of choice over the last 2 years.

    Does that mean I have a problem?

    TO put things in perspective, I was an 0311 for 4 years so maybe that's why I have these recurring nightmares of perl necklaces and pythons tcling me.

    • Re:This is good news (Score:4, Insightful)

      by Daniel Dvorkin ( 106857 ) on Saturday September 27, 2003 @10:24AM (#7072035) Homepage Journal
      Python has become my scripting language of choice over the last 2 years.

      Does that mean I have a problem?
      No, it just means you got tired of writing code that looks like line noise. ;)

      Seriously, scripting language holy wars are even sillier than other holy wars. I use Perl, Python, and PHP regularly (and both MySQL and PostgreSQL, on both Linux and BSD) choosing whichever seems best for the task at hand. (Yes, I know that I'm very lucky to have a job that allows me to do this.) And as a benefit, I've become pretty good at porting between various combinations of these languages, servers, and platforms. The underlying logic is a hell of a lot more important than the flavor-of-the-month.
      • Seriously, scripting language holy wars are even sillier than other holy wars. I use Perl, Python, and PHP regularly

        I agree! I'm happy to hear someone else say it. I use both Python and Perl continuously. My code isn't unreadable in either language. Yes, I've had other people work on my Perl code, and I've been able to read my own years later. No problem. OTOH, I'm currently refactoring Java code that is an incomprehensible mess in places. The fact is that the language is not the problem if your code is r

        • Re:This is good news (Score:5, Interesting)

          by Daniel Dvorkin ( 106857 ) on Saturday September 27, 2003 @11:27AM (#7072363) Homepage Journal
          To be fair, it's probably easier to write unreadable but still useful code in Perl than in any other language (and I'd say Java is second) while Python does strongly encourage code that has, at the very least, a logical and easily understandable form. (You can still obfuscate it with bad variable names and the like, of course.) PHP is somewhere in the middle, IMO.

          But yeah -- it is entirely possible to write well-documented, well-organized Perl that other people (or you, well after you wrote it) can read, as you say. Actually, IMO, it's easier to write the code this way, once you get into the habit. Organizing the code well on screen helps you organize the thought processes in your head. Some programmers (and I do think that Perl programmers are particularly prone to this) seem to take a childlike delight in writing unreadable code. I maintain that people who do this deliberately are bad programmers, no matter how impressive their other skills may be.

          • Re:This is good news (Score:1, Informative)

            by Anonymous Coward
            Personally, I write a lot of perl and I make it a high priority to make the code as clear as possible. All my subs get at least a few lines of documentation, explaining their purpose and expected inputs and outputs (and what happens on failure), and if the module is really important I'll even write a man page for it, using POD. I tend to shy away from "kewl" code *unless* it's in a tight loop and has a significant performance advantage. And anything weird gets commented. For the most part though, there i
            • I'm always surprised about Perl's reputation for being hard to read. The perl community
              seems to generally put a lot of emphasis on readable code.

              Is the reputation for obfuscation just based on regexes?

              • Nah, regexes aren't the main 'cause (imho). Basic regex notation (what probably %90 of people that use 'em out there use) is pretty easily recognizable as the core syntaxes once you've spent a little time grubbing through docs. It's just that there are a lot of shortcut notations and alternate usages possible with basically everything else.

                One of perl's little catchphrases is "There's more than one way to do it." The language is extremely flexable.

                I totally agree with the poster a few levels up, the on
          • To the people talk about Perl being a write once language, yes Perl tends to be write once but not usually because it is hard to read, but it's because it is common and possible to actually _reuse_ code. Why rewrite code when you don't have to:

            www.cpan.org

            There are TONS and TONS of code there and significant quantities are actually useful and usable.

            The perl modules seem to be written by people who actually use them in _real_life_.

            Unreadable code? Who cares man :). A good design is where you don't have
            • Ug, I care. ;) That's almost exactly one reason I don't use some of the crappy CPAN modules out there.

              If I can't figure out what's going on in them, how the hell do I know it works as advertised with a quick scan?

              I'd rather just take a quick glance at the (whatever) code than worrying about adding yet another dependancy, and one that probably takes more time to read/convert/integrate than to just do it yourself from scratch.

              That being said, there are a hell of a lot of great modules out there!

              If you do
          • To be fair, it's probably easier to write unreadable but still useful code in Perl than in any other language (and I'd say Java is second) while Python does strongly encourage code that has, at the very least, a logical and easily understandable form.
            The apparent usefulness of Perl (like Visual Basic) is only indicative of the large number of modules it incorporates. It's got nothing to do with properties of the language itself. Personally I think the usefulness of a language should be measured using the
            • I'm posting WAY too much in this thread, but your comparison of perl to VB just made me vaguely queasy. ;)

              "The apparent usefulness of Perl (like Visual Basic) is only indicative of the large number of modules it incorporates."

              I don't think that the flexibility of a programming language can be in any way be affected by the ancillary code produced later. The flexability or usefulness of a language, I think, is apparent in what you can do with it, period.

              Basically either you can do something or you can't

              • Ug! (Score:1)

                by Shardis ( 198372 )
                I hate it when I'm overtired and don't cap off a tag and screw up grammatically from editing...
      • Amen. The more tools/languages/code you learn, the better you are. Some languages are better than others for certain things. Being a well rounded programmer never hurt anyone.

        Sometimes just learning a new language keeps you out of the day to day rut, stress, and interest loss.
      • "No, it just means you got tired of writing code that looks like line noise"

        You can write stuff in English which reads like crap too, doesn't stop some people from using the language to write poems.

        Same with Perl.
    • As someone who is not a very good perl hacker (I am not a programmer) but who has to write programs anyway, I was glad to actually read the article (no, I am not new here) and find out about the UTF8 problems with 5.8.0. I had been too lazy and ignorant to search for it earlier, but it does explain why some of my code broke when I went from 5.6.x to 5.8. Guess I should have read the docs, since I went through some hoops to change/fix what I didn't understand, and still don't.

      The cool thing is, I still ge
      • how the hell do you not lose your job, but a cgi programmer who has been doing it for years and went to school to learn the skills of software engineering loses his/her job?

        • Re:This is good news (Score:1)

          by Anonymous Coward
          Karma, man. It's all karma. And not the slashdot kind.
        • Bitter, are we?

          Yeah. Me, too.
        • how the hell do you not lose your job, but a cgi programmer who has been doing it for years and went to school to learn the skills of software engineering loses his/her job?

          Because programming is a tiny part of my job. We don't need a full time, or part time, programmer. I don't lose my job because I can adjust. Technically, I run the marketing dept for a manufacturer. But I do photography, website development, IT and several other tasks.

          How I keep my job (easily) is because I am not great at any one
    • Does that mean I have a problem?

      Yes, but apparently you're recovering :-)
    • Python has become my scripting language of choice over the last 2 years. Does that mean I have a problem?

      Only if you have a different prefered tab size to other people, and try to share code with them.

  • Just got a new job... (Score:5, Funny)

    by Basje ( 26968 ) <bas@bloemsaat.org> on Saturday September 27, 2003 @10:13AM (#7071985) Homepage
    and now they release both a new perl and a new slackware, after 3 months of unemployment. I say they do it to pester me.
  • A quick pass through the changes uncovered:


    Miscellaneous Enhancements

    map in void context is no longer expensive. map is now context aware, and will not construct a list if called in void context.

    This must have been added to *end* the ceaseless wars over whether using "map" in a void context is lame, or not. This argument after repeated dowsing attempts, would constantly spring back into life with renewed vigor on comp.lang.perl.misc and other places.

    Now it doesn't matter. Argument over. I think I'll miss it. Sort of. I can't remember a time when people weren't fighting about this. Next I suppose we'll be sorting out the whole "who would win, the Enterprise or a star destroyer?" mess ;)

    For those who don't know what I'm on about: "map" applies a subroutine or code block to each element in a list. Some people would use it to iterate over lists, instead of using "for". Perl is now smart enough to notice if you're not using the result of "map", and so won't generate the result list in that particular case.

    The whole argument came down over whether to say:

    map { do_stuff; } @list;

    or

    do_stuff for @list;

    So the "for" people would, rightly, say that the "map" was inefficient if you weren't using the result list created by map, and the "map" people said that Perl should just figure it out and do the right thing.

    Actually, now I think about it, this is going to make the argument *worse*, as now they are functionally equivalent, and it will just come down to taste! No! They don't know what they've done ... now it will never die! :)

    • map in void context is no longer expensive. map is now context aware, and will not construct a list if called in void context.

      This sounds like some Zen Buddhist zoan.

  • Perl modules for artificial intelligence [cpan.org] must be kept current with the new Perl release.

    The Perl AI Weblog [virtualentity.com] has some sample Perl AI code for the main Alife module [visitware.com] of the Open-Source AI Mind in Perl.

    Register your own Perl weblog [blogwise.com] if you are writing AI or other good code to share in Perl.

  • PerlDoc Bliss! (Score:4, Informative)

    by C60 ( 546704 ) * <salad@carbon6 0 . net> on Saturday September 27, 2003 @03:10PM (#7073686) Homepage
    Pod::Perldoc

    Complete rewrite. As a side-effect, no longer refuses to startup when run by root.

    Okay, okay, I know, root bad, now shut up. I don't know how many freakin times I've been hacking away at a perl script, as root and had to actually log in as a different user just to read the damn documentation. Thank Wall for small miracles.

    Not that I often read documentation, but anyway.

    • I don't know how many freakin times I've been hacking away at a perl script, as root and had to actually log in as a different user just to read the damn documentation.
      You could have read the doc as root just by using the "-U" option to perldoc. That option basically says "I know it's insecure but do it anyway!".

  • I've already got Perl 6... (Score:4, Insightful)

    by CatGrep ( 707480 ) on Saturday September 27, 2003 @10:18PM (#7075373)
    it's called Ruby ;-)
  • There are too many languages now a days. Please eliminate 3. I am not a crackpot!

    With Perl 5.8.1 we finally get usable threads that efficently communicate and cooperate. There is a fix for the memory leak that existed when using shared queues, arrays and hashes in Perl 5.8.0. This starts a whole new era for Perl programs. My little language is finnally growing up (sniffle.)

    Perl has been a great language for people who just want to "get it done." It get's the job done and usually get's it done fast.
  • This must have been added to *end* the ceaseless wars over whether using "map" in a void context is lame, or not.

    It doesn't change the idea of whether map in a void context is lame, only about its cost. The great thing is now the arguments can't point back to the cost issue, and only deal with the pure idealism of whether map is a good substitute for foreach.

Slashdot Top Deals

If all the world's economists were laid end to end, we wouldn't reach a conclusion. -- William Baumol

Close