Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×

Perl 5.10, 20 Year Anniversary 304

Posted by CmdrTaco from the thats-a-lotta-candles dept.
alfcateat writes "Perl 1 was released to the public by Larry Wall 20 years ago yesterday. To celebrate, Perl5Porters have released Perl5.10, the latest stable version of Perl 5. Happy Birthday Perl! Perl 5.10 isn't just a bug fix version: it's full of new features that I'm eager to use: named captures in regular expressions, state variables for subroutines, the defined-or operator, a switch statement (called given-when, though), a faster regex engine, and more. You can read more about the changes in perldelta."
This discussion has been archived. No new comments can be posted.

Perl 5.10, 20 Year Anniversary More

Perl 5.10, 20 Year Anniversary

Comments Filter:

  • Hmmmmmm (Score:5, Insightful)

    by Billosaur ( 927319 ) * <wgrother@optonline . n et> on Wednesday December 19, 2007 @08:57AM (#21750804) Journal

    I was right... we hit double-digits with Perl 5 before Perl 6 became available... and don't go on about Parrot -- it's not Perl 6. I'll be interested to download 5.10 and see what it can do. The speedier regex engine is going to be a great boon.

    • Re:Hmmmmmm (Score:5, Insightful)

      by fbjon ( 692006 ) on Wednesday December 19, 2007 @09:21AM (#21750998) Homepage Journal

      The speedier regex engine is going to be a great boon.
      Not to mention the named captures. Finally, no more empty capture vars because some parentheses were removed in the middle of the expression!

    • and don't go on about Parrot -- it's not Perl 6.

      Perl 6 is a language specification, remember? It's no longer a single implementation. Anything that passes the Perl 6 suite will be Perl 6, be it Parrot, Pugs, ...

      Anyway, we're seeing good progress recently with Parrot. We should be seeing a Perl 6.0.0 alpha "soon" ...

    • At my first software engineering job when I was in highschool, everyone on my team was hardcore into perl. My boss especially, since he regularly hung out with some of the perl oriley authors, and had written however dozen many of the cpan modules etc.

      I remember how excited he was because perl 6 was going to be coming out "any day now". This was in 2001. I have been out of the loop for a while, but every time I do a linux install, I notice that perl hasn't hit 6 yet, and I find that slightly amusing.

  • Switch statements are syntactic sugar (Score:3, Insightful)

    by morgan_greywolf ( 835522 ) on Wednesday December 19, 2007 @08:59AM (#21750818) Homepage Journal
    Switch statements are syntactic sugar. They're really not needed. Nested if/then/else do the same thing. There are also other constructs that you can use to get around the whole nested if/then/else thing too in many cases.

    • Re: (Score:3, Funny)

      by mccalli ( 323026 )
      Switch statements are syntactic sugar. They're really not needed. Nested if/then/else do the same thing.

      Yeah, and who needs if statements anyway, or a high-level language come to that? Just syntactic sugar, I say we go back to sector-editing ones and zeros directly to the disk. Readability? Pah.

      Cheers,
      Ian

      • Re: (Score:3, Funny)

        by SamP2 ( 1097897 )
        "Perl" and "readability" don't fit in the same sentence to begin with. :)

        • Re: (Score:3, Funny)

          by mccalli ( 323026 )
          "Perl" and "readability" don't fit in the same sentence to begin with. :)

          Lean on your keyboard for long enough, and you will eventually have produced a valid Perl script. Of course you won't know what it actually does, but then how does that differ from 90% of Perl scripts anyway?

          Cheers,
          Ian
        • At least Perl knows that adding numbers and concatenating string are different operations.

          2 + 3 == 5 (Perl isn't that weird)
          2 + "3" == 5 (not a TypeError as in Python)
          "2" + 3 == 5 (not "23" as in JavaScript)
          "2" + "3" == 5 (not "23" as in both JavaScript and Python)
          • + is javascripts and pythons string addition operator, presumably because they didn't want to confuse by overloading the standard record deference operator (.), like perl does (which is the better choice is an argument best left to people with time for language bashing).
            Now, if we look at the equivilent results when using the string addition operator (lets call it <>, to represent + in javascript/python and . in perl):

            2<>"3"==type error in python and perl
            "2"<>3=="23" in all
            "2"<>"3"==

            • Re: (Score:3, Informative)

              by ajs318 ( 655362 )

              2<>"3"==type error in python and perl

              Are you sure about that?

              $ perl -e 'print 2 . "3", "\n"'
              returns 23 on my system (perl, v5.8.8 built for x86_64-linux-gnu-thread-multi). Note you need a space before the dot, otherwise Perl gets its knickers in a twist because a dot looks like the fraction delimiter; but that's OK, because we don't have to strip out unnecessary spaces to make our code fit into the remaining 6KB of RAM (after allowing 20K for the framebuffer and 6K reserved for the system) an

          • Re: (Score:2)

            by nuzak ( 959558 )
            At least Python has polymorphic operators and knows that numbers and strings are different things.

            Actually, perl has overloaded operators too. Now itdoes, anyway. Scalars are a remnant from perl 1, and themselves some sort of throwback to awk.

            • Re: (Score:2)

              by ajs318 ( 655362 )
              True; but Python {which is otherwise a high-level language} insists for you to call a function just to convert between a string and a number, all so it can recycle an operator. Perl treats numbers and strings interchangeably {and, be brutally honest, isn't the whole point of using a high-level language so you don't have to think about stuff like that?}, but uses distinct operators for distinct operations. JavaScript manages to balls it up both ways, treating things as being the same one minute and dif

          • Implicit vs. explicit parsing (Score:4, Insightful)

            by SamP2 ( 1097897 ) on Wednesday December 19, 2007 @11:16AM (#21752276)

            2 + "3" == 5 (not a TypeError as in Python)
            "2" + 3 == 5 (not "23" as in JavaScript)
            And this is intuitive, useful, or best practice, how exactly?

            Implicit parsing a num to a string is straightforward and will pretty much always work, even if you may get wierd results like "1.66666666666666666667". But the other way is just too careless to let be implicitly done. You may unexpected errors when for some reason the string you use cannot be parsed, and you may get either an unexpected datatype or a truncated result when a parsed string would not match the other num you add to it (such as int a = x+5 where x is a string "3.5").

            Casting from string to number should always be done explicitly, with precise definition of the data type you cast to, and ideally with an error catching block in case something goes wrong. Letting it be done implicitly is a recipe for headache.

            • Re: (Score:2)

              by glwtta ( 532858 )
              You may unexpected errors when for some reason the string you use cannot be parsed, and you may get either an unexpected datatype or a truncated result when a parsed string would not match the other num you add to it (such as int a = x+5 where x is a string "3.5").

              Thus proving that you have never, ever, programmed in Perl. But I'm glad that you can pass these dicta on what dynamically typed languages should and shouldn't do.

              For the record: when a string being used as a number can't be parsed, it's 0

            • Re: (Score:3, Funny)

              by ajs318 ( 655362 )

              Casting from string to number should always be done explicitly, with precise definition of the data type you cast to, and ideally with an error catching block in case something goes wrong. Letting it be done implicitly is a recipe for headache.

              Let me guess: You like Pascal. The language that, if it was a car, would have only one pedal and two forward gears.

              I program in high-level languages precisely because I don't want to have to think about whether something is a string or a number. I have bought an

      • Re:Switch statements are syntactic sugar (Score:4, Interesting)

        by chris_eineke ( 634570 ) on Wednesday December 19, 2007 @09:20AM (#21750988) Homepage Journal

        Yeah, and who needs if statements anyway,
        You wrote something accidentally insightful. Look at the following expression:
        (if (> 3 2) 5 4)
        which obviously evaluates to 5. But you know what? You can eliminate the if operator entirely if you let > (and any other predicate) return a two-ary function:
        (define true (x y) (x))
        (define false (x y) (y))
        and stuff the arguments into separate functions for deferred evaluation:
        ((> 3 2) (lambda () 5) (lambda () 4))
        :-)

        • Re:Switch statements are syntactic sugar (Score:5, Funny)

          by mccalli ( 323026 ) on Wednesday December 19, 2007 @09:33AM (#21751128) Homepage
          >>Yeah, and who needs if statements anyway...
          >You wrote something accidentally insightful. Look at the following expression:...

          Away - away foul Lisp advocate, and darken not my doors again!

          Cheers,
          Ian
          /tongue-in-cheek

        • Re: (Score:3, Informative)

          by SolitaryMan ( 538416 )

          Well, most languages have a ternary operator ?:, which allows to get away without if in any situation. In Perl and Python you can do:

          (CASE1 and STUFF_TODO) or (CASE2 and STUFF_TODO2) or ...

          Where CASEx is boolean and STUFF_TODOx is some statement. It has to return true in order to halt the search though, so, in general case you have to go for something like

          (CASE1 and (STUFF_TODO1 or 1)) or (CASE2 and (STUFF_TODO2 or 1)) or ...

          As well as in your LISP example, this is ugly enough to be avoided when

          • Re: (Score:2)

            by mstahl ( 701501 )

            As well as in your LISP example, this is ugly enough to be avoided whenever possible :)

            When used judiciously, it can actually lead to succinct, readable code. Take for instance, in perl, the opening of a file:

            open SOME_FILE, ">some_filename.foo" or die("Some kind of error occurred");

            Using short-circuit operators like &&, ||, or ?: can actually greatly simplify your code if you don't go overboard with them, particularly if you can call them "and" and "or". Having more than two such statements in one big expression I would say is ill-advised if you ever want to read your code s

        • Re: (Score:3, Interesting)

          by johannesg ( 664142 )
          And how is ((> 3 2) (lambda () 5) (lambda () 4)) better than (if (> 3 2) 5 4), especially considering that you are apparently changing the meaning of true and false to something that is only extremely locally true? (disclaimer: ((lisp) ((not) (me)) () (speak))). This is a serious question, btw: is there really some advantage to doing this the difficult way?

          And then I'm carelessly skipping over 3 > 2 ? 5 : 4, which is of course the *correct* solution ;-)
          • It isn't. That's why 'if' is a special operator in Lisp. You *could* write it in the former style, but the second is much more readable: syntactic sugar. There's no advantage of doing it the difficult way. Except, maybe, that you can now pass true and false around as functions. :-)

            BTW, why do you think that defining true and false as functions makes them 'only extremely locally true'? If you have a predicate, the only outcome is either true or false.
      • I writ a lot of C, and don't often find much need for switch statements.

        I find if-else statements to be quite sufficient. They might be less efficient when compiled, I'm not sure, but when it comes to the readable code, they're simpler to write and parse most of the time. Conditional jumps of any kind are wasted clock cycle intensive regardless. I suppose I could output the assembly and hand optimise that, I know how to do it (yeah, how sad am I...), but if I wanted to do that I wouldn't be using C in the f
    • Programming languages are syntactic sugar. We could all be programming in lambda calculus if not for the convenience a higher level language provides.
      • Lambda calculus is a high level construct. It would be more apt to say we could all be programming in ones and zeros, or assembly language, or entering in memory addresses and instruction codes by hand.
    • Switch statements are syntactic sugar. They're really not needed. Nested if/then/else do the same thing. ...only in a less readable way. MOST language features in any language are syntactic sugar. Besides, if the fact that there is more than one way to do something bothers you, isn't Perl the last language you should be using? :)
    • if...then...else statements? Pah, syntactic sugar. Don't you know that you can do all of your control flow with while statments?
    • It looks like a step in the right direction (well structured human readable syntax).
      I can't wait Perl 6 anyway especially for their promising new Object oriented syntax (and static types).

    • Re: (Score:2)

      by Chysn ( 898420 )
      It's all syntactic sugar! Just don't take my ternary operator away from me...

    • Re: (Score:3, Informative)

      by beuges ( 613130 )
      Switch statements are more efficient than nested if/then/else, at least in C/C++ (I dont use perl so I'm not sure if the same applies).

      C/C++ only allows constants to be used as case values in a switch statement, you can't use a variable as a case label. This allows the compiler to optimise the comparisons based on the numerical value of each constant case label. Performing the case evaluations in different orders, using subtraction and addition and testing against zero can be more efficient than comparison

      • Re: (Score:2)

        by Sancho ( 17056 )
        Changing the order of case evaluation can break things. Remember, you don't always have to break; before your next case:.

    • Re: (Score:2, Interesting)

      by chicoryn ( 989443 )

      Switch statements are syntactic sugar. They're really not needed. Nested if/then/else do the same thing.

      They do not! Not only do they increase readability of the code in many cases they do not even generate equivalent RTL. When you do a if-else if-else... you tell the compiler that it MUST check the first condition before the second, a subtle but important difference. What this means to the compiler is that an if-else if-else... must have O(n) complexity!

      An switch statement on the other tell the compiler each item is independent of any other (and comparison is generally enforced as side-effect free). This

      • Re: (Score:3, Funny)

        by Fujisawa Sensei ( 207127 )

        Not only do they increase readability of the code in many cases

        Readability? You do realize this is Perl we're talking about?

      • Re: (Score:2)

        by bytesex ( 112972 )
        Never mind that you can do all sorts of modifying behaviour inside the if/else if conditions (which would have to be evaluated by the compiler in the order that it encounters it in), and that you can do fall-trough in the case (!) of switch/case.

      • What this means to the compiler is that an if-else if-else... must have O(n) complexity!

        Since you're manually typing a constant number of cases, the if-else tree has O(1) complexity. Always.

    • Sure, technically that's true. But in C++ ( and I'm sure other languages ) I enjoy the fact that if I'm switching on an enum, I can get compiler warnings if I forget one. if/then/else can't do that.

      You might as well say that objects are just sugar for structs with function pointers and isa/super class pointers. And that functions are just sugar for goto.

      Grousing about a language feature that makes doing certain classes of operations more robust just tells me you don't write much code.

    • There are cases where a switch is simply syntactic sugar (however the argument for improving the readability of code goes a long way), however, implementing a "fall-through" with if/then/else is impossible (it would have to be done as a load if if/then statements that at the end set the variable to be checked so that it passes the next if test); That's just insane, and error prone when you add new items into the list.

      • Sometimes it's difficult to tell if the fall-through was intentional when maintaining old code, an explicit fall-through might have been better. Sometimes it help to put a "//fall through" comment in place of the break.

        A better way to reproduce fall-through with 'if' statements would be to create a false boolean variable that names the reason for falling through, and set it to true in one or more of the earlier 'if's.

      • Re: (Score:2)

        by Sancho ( 17056 )
        You can do fall-through in if-else with liberal use of GOTO, however it's pretty ugly.

    • Re: (Score:2)

      by jez9999 ( 618189 )
      Yeah, I used to look for a switch statement in Perl until I came along this type of construct, which is far more powerful (regexps) and basically better than a switch:

      SWITCH: for ($checkme) {
      $_ eq "foo" and do
      {
      # Foo stuff...

      last SWITCH;

    • Re: (Score:2)

      by 87C751 ( 205250 )

      Switch statements are syntactic sugar. They're really not needed. Nested if/then/else do the same thing.
      I am pretty sure you can't construct Duff's Device [wikipedia.org] using if/then/else.
      • If you're implementing Duff's Device at all, let alone in Perl, you deserve to be shot, brought back to life, and shot again.

    • Re: (Score:2)

      by Sancho ( 17056 )
      I don't know--how hard is it to implement Duff's Device with if instead of switch?

    • Re: (Score:2)

      by mstahl ( 701501 )

      In lower-level languages like C, though, they become a multiway branch, which, when converted to machine code, results in fewer branch instructions. In C code, a good switch statement, particularly in a block of code that's already looped or gets called often, can save you a lot of pipeline flushes.

      In high-level languages of *course* it's syntactic sugar, since there are some languages sophisticated enough to convert serial if/elsif/else blocks into multiway branches. Perl is all about that sort of thing t

    • There are also other constructs that you can use to get around the whole nested if/then/else thing too in many cases.

      ... amongst them hash of subroutines is best ^_^

      There is no other language where pointer to function can be used with such ease.

  • I can't see why (in purely practical terms) it's worth coordinating a release with an anniversary.

    Surely if the code is "ready" (thoroughly tested etc) before the anniversary, it could very easily be useful as a release to developers before the anniversary.

    If it isn't ready, it shouldn't be released early just because there's an anniversary.

    • Re:Aren't these two unrelated events? (Score:5, Funny)

      by supersnail ( 106701 ) on Wednesday December 19, 2007 @09:24AM (#21751024)
      Get real -- this is perl we are talking about.

      A programming language used for poetry.

      A programming language where "bless" is a basic operation.

      A programming language which borrows the "understood" syntax from English.

      A programming language where all published examples contain variables "Foo" and "Bar".

      Of course they are going publish a new release on the twentieth anniversary. I dont think it occurred to anyone in the perl community not to.

      • "The new version on the anniversary, thus, was immediate and automatic," Wall wrote later. "No one ever considered that there would not be a new version on the anniversary."

        Original source [washingtonpost.com].

      • But the cursing you get for free. And, bonus points, if you write it out in newspaper style it will execute. "Who the $_|&%.$# decided they were too cool to use lettes in the names of their variables in a 6,000 line program?"

        (Yep, I really did hit an executing program on the first try. I think it evaluates to null for all input strings but $_|&%.$# if I'm going to try to parse Perl code without getting paid money for it.)

      • Just imagine what will happen when Python turns 20...

        ...laura

        • you're going to compare a magnificiently architected skyscraper with urban sprawl sans zoning? ah well, at least Perl 5 is useful, I've written tons of it. Sadly, haven't yet worked with any project where python was needed, and for my personal use I choose something else where they feel the need to release new things at Christmas!

    • Actually, Perl 5.10 has been in release candidate state for a little while now, and someone recently just happened to drop an email reminding p5p of the upcoming anniversary and how cool it would be to release on the anniversary date, so it became a target to get the final out on that date. Without the anniversary to shoot for, it probably would've been a few days later. The fact that the anniversary happened to fall somewhere in the right vicinity was pure luck.

    • Re: (Score:2)

      by glwtta ( 532858 )
      You are right, it's almost as if they somehow knew about the anniversary and planned the release beforehand.

      Spooky.

  • Is this the version (Score:3, Funny)

    by $RANDOMLUSER ( 804576 ) on Wednesday December 19, 2007 @09:11AM (#21750918)
    that has the ORELSE operator?

  • Oh dear. (Score:5, Funny)

    by Xargle ( 165143 ) on Wednesday December 19, 2007 @09:20AM (#21750984)
    "say() is a new built-in, only available when use feature 'say' is in effect, that is similar to print(), but that implicitly appends a newline to the printed string".

    *sigh* Nice to see they're still adding to the elegance of the language :(

    I wonder if threading actually works in production yet?

  • recursive patterns (Score:5, Funny)

    by hey ( 83763 ) on Wednesday December 19, 2007 @10:00AM (#21751412) Journal
    The new recursive patterns should increase perl's readability.

    • Re: (Score:3, Insightful)

      by Kostya ( 1146 )
      What? No mod +funny yet? Come on people!

      Yeah, I saw recursive patterns and thought, "Crap, now I'm going to have to relearn how to look at regexes so that I see those too." Still, I'm excited about the power (while being daunted by the readability).

  • Much Thanks to Mr. Wall (Score:5, Insightful)

    by BodhiCat ( 925309 ) on Wednesday December 19, 2007 @10:21AM (#21751602)
    Much thanks to Mr. Wall for creating a fast and dirty lannguage. The Oscar Madison of programming languages, much easier to learn and use than Java, the script equivilent of Felix Unger. Perl has been great for small cgi web things, not a lot of fuss and bother. Wouldn't use it for anything over a few hundred lines, tho, too easy for variable to get confused, even when using strict. Now if I can just get the DBI to MySQL on OS 10.5 to work my life would be perfect.

    • Re: (Score:3, Insightful)

      by Goaway ( 82658 )
      Uh, with Perl being one of the few scripting languages out there that even have something like use strict, I'd say it's one of the least likely ones to confuse variables in.
    • The same can be said about any language. If you're worried about writing applications and not scripts, read up on using modules in perl. They're a bit wordier than C++ and Java style classes, but they can also be used as non-oop libraries or used to extend other modules without repeating yourself or building a huge class tree.

      You'll also be much happier if you start using DBIx::Class instead of pure DBI; it's the best object-relational mapping I've found in any language thus far.
  • I am not touching Perl for any purpose. I'd rather do it in machine code than Perl... :-)

  • The regular expression construct (?p{}), which was deprecated in perl 5.8, has been removed. Use (??{}) instead
    " A lot of the other changes have "go here for more info" - but not this one :) I love Perl :)
  • I gave a quick look through the Features list and have the following comment:

    Larry, developers; stop smoking crack.

    Do we really need the "defined-or" operator? Is the "given" operator really any simpler than the numerous known switch examples? Recursive Patterns? My head almost asploded parsing the example. Stop doing things, just because you can. Do something else -- and I don't mean that franken-project Perl 6.

    Ok, no more coffee for me today. :-)

  • Bold perl hackers, I salute you (Score:4, Funny)

    by anilg ( 961244 ) on Wednesday December 19, 2007 @12:13PM (#21753116)
    With 'given-when', you have broken into lands no other languages dared. I now await the addition of 'conclude-basedon' and 'eithernot-ifonly' to complete the glory that is perl.

Slashdot Top Deals

According to the latest official figures, 43% of all statistics are totally worthless.

Close