Perl 5.10, 20 Year Anniversary

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."

Hmmmmmm

[Billosaur (927319)]

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

[fbjon (692006)]

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!

Re:Hmmmmmm

[Tony Hoyle (11698)]

I always though of Parrot as of a project that was born dead.

You *know* what kind of responses you are asking for when you write something like that don't you....

Re:

[Ed Avis (5917)]

I think the Perl hackers want something to run Perl 6 on, and the existing perl5 interpreter isn't up to the job (it is fast and well-tested, but the internals are somewhat kludgy). So they need to write a VM. The idea of running Perl, Tcl, Python and others on the same VM is a good one, it would be nice if the world could live together in harmony and all work on the same underlying interpreter, but I don't think the Python or Tcl maintainers will be interested. Which is a shame.

Re:

[mr_mischief (456295)]

The Python community doesn't have to adopt it. There's a considerable overlap of community members among Perl, Python, Ruby, Scheme, Haskell, and other languages. So long as Pirate keeps close enough to the official Python stuff, people who want to use Python and Perl together will be able to put their Python code into a project using Pirate instead of Jython or whatever.

Re:Hmmmmmm

[doti (966971)]

I always though of Parrot as of a project that was born dead.

It's not dead, it's resting.

Re:

[tha_mink (518151)]

I always though of Parrot as of a project that was born dead.

It's not dead, it's resting.

the norwigian blue prefers kippin' on its back. its a beautiful bird....loverly plumage

Re:Hmmmmmm

[$RANDOMLUSER (804576)]

It's not dead, it's resting.

I bloody well know a dead parrot when I see one!

Re:Hmmmmmm

[ricegf (1059658)]

are there any other reasons for working on this project?

If Parrot becomes "efficient enough", then hosting Perl, Python and Ruby on Parrot should permit writing programs in a mixture of all three. Python has a very extensive library, but I certainly wouldn't mind having all of CPAN for which to choose as well - or access to Rails, for that matter. (Yes, I know, much of Rails' value is in its elegant fit to Ruby syntax, but I'd still like access from Python. Call me a library pack rat. :-)

For another example of recent interest to me, Perl and Ruby have excellent integrations with GraphicsMagick; Python has Python Image Library (PIL) instead. Why can't I choose the graphics library I want from any of the big three dynamic languages?

Nor would Parrot implementations of those languages need to replace the main implementations to be useful. The JVM has Jython and JRuby, granting access to Java libraries like Swing. Similarly, Microsoft's .NET has IronPython and IronRuby to avoid the much-maligned VB6. Interoperable implementations of Perl 6, Python 3, and Ruby 2 on Parrot would be very nice indeed.

Well, for a dynamic language junkie like me, at least. ;-)

Switch statements are syntactic sugar

[morgan_greywolf (835522)]

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:

[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:

[SamP2 (1097897)]

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

Re:

[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

Re:Switch statements are syntactic sugar

[Phroggy (441)]

Hey now - those of us who write Perl code know exactly what our own code does, or at least we did when we wrote it. It's reading somebody else's code (or our own, years later) that's the tricky part. Perl is a lot of fun to write!

Re:Switch statements are syntactic sugar

[ajs318 (655362)]

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)

Implicit vs. explicit parsing

[SamP2 (1097897)]

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:

[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:

[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:Switch statements are syntactic sugar

[chris_eineke (634570)]

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

[mccalli (323026)]

>>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:

[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:

[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 ;-)

Re:

[rucs_hack (784150)]

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

Re:

[A beautiful mind (821714)]

Programming languages are syntactic sugar. We could all be programming in lambda calculus if not for the convenience a higher level language provides.

Re:

[Eravnrekaree (467752)]

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.

Re:

[Chandon Seldon (43083)]

Lambda-calculus is in no way high level, it just doesn't happen to correspond to a machine model.

Re:

[LarsWestergren (9033)]

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? :)

Re:

[IBBoard (1128019)]

if...then...else statements? Pah, syntactic sugar. Don't you know that you can do all of your control flow with while statments?

Re:

[Tony Hoyle (11698)]

While statemets? pah. setjmp and longjmp ftw.

Re:

[oliderid (710055)]

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:

[Chysn (898420)]

It's all syntactic sugar! Just don't take my ternary operator away from me...

Re:

[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:

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

Aren't these two unrelated events?

[Westley (99238)]

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?

[supersnail (106701)]

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.

Is this the version

[$RANDOMLUSER (804576)]

that has the ORELSE operator?

Re:

[dintech (998802)]

I think as well as things like GIVENWHEN or GOTO it might also include the COMEFROM [fortran.com] statement.

Re:

[supersnail (106701)]

If you are going to implement "COME FROM" can we have "ALTER GO TO" back please.

For the younger among you this was a fiendish COBOL construct which altered the
target of a plain "go to" somewhere else in the program. A wonderful tool
for sadists whith a particular dislike of maintenance programers.

Re:

[Chysn (898420)]

> that has the ORELSE operator?

        This is Perl we're talking about here. It would be "orels"

Re:Is this the version

[vagabond_gr (762469)]

This is Perl we're talking about here. It would be "orels".

Or whatever you set the $=] variable to.

Oh dear.

[Xargle (165143)]

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

Re:Oh dear.

[macshit (157376)]

"say() is a new built-in ... similar to print(), but that implicitly appends a newline ..."
*sigh* Nice to see they're still adding to the elegance of the language :(

Not to mention the new "lol()" built-in, which is like say(), but also removes random letters from the string, and appends 17 exclamation points.

Sometimes I wonder about Larry Wall.

Re:Oh dear.

[Speare (84249)]

Not to mention the new "lol()" built-in, which is like say(), but also removes random letters from the string, and appends 17 exclamation points.

Better than the first draft of lol() which replaced letters from the string with l33t equivalents. They found it was a security risk because people could just inject eval { lol($_) } and it was valid Perl code to cause a kernel panic.

Re:Oh dear.

[funaho (42567)]

So Perl is getting kinky. You can tell it to "say my $name" now. :)

recursive patterns

[hey (83763)]

The new recursive patterns should increase perl's readability.

Re:

[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

[BodhiCat (925309)]

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:

[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.

Re:

[mr_mischief (456295)]

It's more expressive in that it takes less syntax to achieve the same result than most other languages. I think that's a fairly common definition. Python and Ruby have the advantage of coming after Perl, and Ruby is actually the designer's idea of re-imagining Perl to be more regular and better at OO. They are more expressive than many other languages, too. C and C++ are not nearly as expressive as Perl. They can express the same programs, but it takes much more syntax to do so.

The flexibility isn't just CP

Bold perl hackers, I salute you

[anilg (961244)]

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.