Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Perl 5.10, 20 Year Anniversary

CmdrTaco posted more than 6 years ago | from the thats-a-lotta-candles dept.

304

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

cancel ×

304 comments

Thanks Larry (0, Troll)

Adolf Hitroll (562418) | more than 6 years ago | (#21750762)

Perl is the proof not all believers are fucktards.

Re:Thanks Larry (0)

tha_mink (518151) | more than 6 years ago | (#21751290)

Yeah...Huzzah...Let's all go down and riot at the punctuation factory.

2nd post? (-1, Offtopic)

BestNicksRTaken (582194) | more than 6 years ago | (#21750794)

missed 1st.

yay for new version of perl!

Hmmmmmm (4, Insightful)

Billosaur (927319) | more than 6 years ago | (#21750804)

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 (4, Insightful)

fbjon (692006) | more than 6 years ago | (#21750998)

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 (0, Troll)

SolitaryMan (538416) | more than 6 years ago | (#21751100)

and don't go on about Parrot

I always though of Parrot as of a project that was born dead. What niche is it going to fit in, anyway? The same javish "write-once-support-anywhere" thing? Well, Java is doing pretty OK there: it has a pretty good market in small apps and games for cellphones, but I really doubt, that Parrot can make any difference there.

Large projects are usually targeted at some specific environment and nobody cares about OS independence, since OS is cheaper anyway.

I understand, that writing a VM can be fun, but I'm just wondering, are there any other reasons for working on this project? What merits it has?

Re:Hmmmmmm (5, Funny)

Tony Hoyle (11698) | more than 6 years ago | (#21751202)

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:Hmmmmmm (2, Informative)

Ed Avis (5917) | more than 6 years ago | (#21751226)

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:Hmmmmmm (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21751850)

I helped on the Perl 6 and we made sure nothing like this would happen [tinyurl.com]

Re:Hmmmmmm (1)

bytesex (112972) | more than 6 years ago | (#21752130)

The above is a spamtroll who has reached new depths of depravity in his cunning to lead us onto his minicity website. Seriously dude - are you in it for the money or something ?

Re:Hmmmmmm (5, Funny)

doti (966971) | more than 6 years ago | (#21751252)

I always though of Parrot as of a project that was born dead.
It's not dead, it's resting.

Re:Hmmmmmm (2, Funny)

tha_mink (518151) | more than 6 years ago | (#21751336)

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 (1)

SolitaryMan (538416) | more than 6 years ago | (#21751376)

It's not dead, it's resting.

I only now realized that there was a pun in my post :)

Re:Hmmmmmm (4, Funny)

$RANDOMLUSER (804576) | more than 6 years ago | (#21751434)

It's not dead, it's resting.
I bloody well know a dead parrot when I see one!

Re:Hmmmmmm (2)

metallic (469828) | more than 6 years ago | (#21751274)

I understand, that writing a VM can be fun, but I'm just wondering, are there any other reasons for working on this project? What merits it has?

The reason you want a VM is for performance reasons. If you take a look at a high-performance VM like Java's HotSpot VM, it can actually do code analysis while the program is running and then do optimizations on the fly. YARV, which is being developed by the Ruby team, will give Ruby somewhere around a 3x performance increase. I expect to see continued performance increases as they improve YARV.

Also, Parrot isn't intended just for Perl. It's goal is to be a general VM that any language can run on. So if someone writes a compiler for Python, that language will gain any performance improvements that Parrot can offer.

Re:Hmmmmmm (0)

Anonymous Coward | more than 6 years ago | (#21751330)

"So if someone writes a compiler for Python, that language will gain any performance improvements that Parrot can offer."
But Python already has a working JIT with psyco, and a project with even greater goal than just yet another VM with PyPy. And PyPy unlike Parrot, is not vaporware and received funds from the European Union from 2004 to 2006.

Re:Hmmmmmm (1)

smitty_one_each (243267) | more than 6 years ago | (#21751572)

PyPy is a straight-up compiler, replacing CPython, is it not?
My understanding is that the value of Parrot is that you can mix and match code derived from any compiler that targets it. You could have some Python, some Perl, and some Scheme code (eventually) executing together.

Re:Hmmmmmm (4, Interesting)

ricegf (1059658) | more than 6 years ago | (#21751524)

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

Re:Hmmmmmm (1)

Dystopian Rebel (714995) | more than 6 years ago | (#21751698)

Running scripting languages in a single VM is a cool idea. If I have to do practical extraction and reporting, it sure as hell isn't going to be in Java.

Knicker-twisting quibblers like to blame Perl for the fact that they need tabs to understand their own code. Perl is excellent for its purpose.

It is, however, ghastly for OOP.

Re:Hmmmmmm (1)

davegaramond (632107) | more than 6 years ago | (#21751570)

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

Re:Hmmmmmm (1)

TheLink (130905) | more than 6 years ago | (#21752278)

Will that be after or before Duke Nukem Forever is released? ;)

Re:Hmmmmmm (1)

Deanalator (806515) | more than 6 years ago | (#21752240)

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 (3, Insightful)

morgan_greywolf (835522) | more than 6 years ago | (#21750818)

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:Switch statements are syntactic sugar (2, Funny)

mccalli (323026) | more than 6 years ago | (#21750848)

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:Switch statements are syntactic sugar (2, Funny)

SamP2 (1097897) | more than 6 years ago | (#21750866)

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

Re:Switch statements are syntactic sugar (3, Funny)

mccalli (323026) | more than 6 years ago | (#21750902)

"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 (0, Offtopic)

Instantlemming (816917) | more than 6 years ago | (#21751036)

100 monkeys will eventually write something that isn't Perl, but will turn out to be the complete works of Shakespeare. It's possible to write obscure code in every language, so Perl's not alone there. Without comments even COBOL-74 source can be a mysterious black box.

Re:Switch statements are syntactic sugar (4, Insightful)

Phroggy (441) | more than 6 years ago | (#21751858)

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 (4, Funny)

ajs318 (655362) | more than 6 years ago | (#21751108)

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)

Re:Switch statements are syntactic sugar (1)

DJProtoss (589443) | more than 6 years ago | (#21751310)

+ 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"=="23" in all
hmm, when you do a comparison taking into account the fact that the languages use different operators for concating strings, surprisingly they act the same! shocking </sarcasm>

Re:Switch statements are syntactic sugar (0)

Anonymous Coward | more than 6 years ago | (#21751402)

The '.' isn't Perl's dereference operator. There isn't a single dereference operator, since it depends on the referent's type. The arrow "->" works in the context in which, say, Ruby's (and I presume Python's) '.' would.

Re:Switch statements are syntactic sugar (1)

TheDauthi (219285) | more than 6 years ago | (#21751942)

Why would 2 . "3" throw a type error? Does it actually do that in other languages? 2 becomes stringified, becomes "2", and is concatenated into "23". For that matter, perl doesn't even care about the quotes 2 . 3 will return exactly what you would expect - "23".

Re:Switch statements are syntactic sugar (1)

nuzak (959558) | more than 6 years ago | (#21751398)

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:Switch statements are syntactic sugar (1)

ajs318 (655362) | more than 6 years ago | (#21752120)

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 different another. Fortunately, you can just pretend that there is no addition operator in JS, and subtract negative numbers instead.

Implicit vs. explicit parsing (3, Insightful)

SamP2 (1097897) | more than 6 years ago | (#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:Switch statements are syntactic sugar (3, Interesting)

chris_eineke (634570) | more than 6 years ago | (#21750988)

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 (4, Funny)

mccalli (323026) | more than 6 years ago | (#21751128)

>>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:Switch statements are syntactic sugar (2, Informative)

SolitaryMan (538416) | more than 6 years ago | (#21751782)

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 whenever possible :)

Re:Switch statements are syntactic sugar (2, Interesting)

johannesg (664142) | more than 6 years ago | (#21751910)

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:Switch statements are syntactic sugar (1)

Inoen (590519) | more than 6 years ago | (#21752234)

I always preferred the other way of writing conditionals without if:

(3 > 2 and 5) or 4;

Much prettier, and easier to read.

Re:Switch statements are syntactic sugar (1)

rucs_hack (784150) | more than 6 years ago | (#21751222)

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 first place.

No doubt some programming guru will blast me as being a bad coder for saying this :-)

Re:Switch statements are syntactic sugar (1)

A beautiful mind (821714) | more than 6 years ago | (#21750852)

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

Re:Switch statements are syntactic sugar (0)

Anonymous Coward | more than 6 years ago | (#21751032)

Well LISP allows you to define your own syntactic sugar, so I'd say lambda calculus is more high level than most of the "high level" languages in common use.

Re:Switch statements are syntactic sugar (1)

krog (25663) | more than 6 years ago | (#21751246)

Lisp includes a version of the lambda calculus, but pure lambda calculus [wikipedia.org] is about as useful as a Turing machine.

Re:Switch statements are syntactic sugar (1)

Eravnrekaree (467752) | more than 6 years ago | (#21751234)

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:Switch statements are syntactic sugar (2, Insightful)

Chandon Seldon (43083) | more than 6 years ago | (#21751902)

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

Re:Switch statements are syntactic sugar (1)

LarsWestergren (9033) | more than 6 years ago | (#21750888)

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:Switch statements are syntactic sugar (0)

Anonymous Coward | more than 6 years ago | (#21750900)

Actually, in many languages such as C#, switch statements vs. if statements can have different performance as well, so it's not purely a syntax issue. For instance, in C#, a hashing is used with the switch so for a large number of cases, a switch is faster than multiple comparisons using if statements.

Re:Switch statements are syntactic sugar (1)

IBBoard (1128019) | more than 6 years ago | (#21750940)

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

Re:Switch statements are syntactic sugar (2, Funny)

Tony Hoyle (11698) | more than 6 years ago | (#21751406)

While statemets? pah. setjmp and longjmp ftw.

Re:Switch statements are syntactic sugar (1)

oliderid (710055) | more than 6 years ago | (#21751124)

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:Switch statements are syntactic sugar (1)

Chysn (898420) | more than 6 years ago | (#21751228)

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

Re:Switch statements are syntactic sugar (2, Informative)

beuges (613130) | more than 6 years ago | (#21751262)

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 to each value in turn.

So, a switch statement can be more efficient than nested if/then/else.

Re:Switch statements are syntactic sugar (2, Interesting)

chicoryn (989443) | more than 6 years ago | (#21751278)

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 means a switch statement can be converted to a binary-search or even a jump-table giving us a best-case complexity of O(1).

As you can see they are hardly equivalent but a really good compiler might be able to convert a if-else if-else... to a switch statement. But considering a switch statement is usually easier to read, write and understand in the first place why bother?

Re:Switch statements are syntactic sugar (2, Funny)

Fujisawa Sensei (207127) | more than 6 years ago | (#21751392)

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

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

Oh right... (1)

chicoryn (989443) | more than 6 years ago | (#21751514)

Readability? You do realize this is Perl we're talking about?
Oh come on, you can write readable Perl code. Never mind that it is never practised.

Re:Switch statements are syntactic sugar (1)

bytesex (112972) | more than 6 years ago | (#21751408)

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.

Re:Switch statements are syntactic sugar (1)

Chandon Seldon (43083) | more than 6 years ago | (#21751938)

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.

Re:Switch statements are syntactic sugar (1)

TomorrowPlusX (571956) | more than 6 years ago | (#21751332)

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.

Re:Switch statements are syntactic sugar (1)

Phil John (576633) | more than 6 years ago | (#21751364)

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.

Re:Switch statements are syntactic sugar (0)

Anonymous Coward | more than 6 years ago | (#21751454)

Not to let facts get in the way of a good story, but switch statements are much more than mere syntactic sugar. Switch statements can be optimized much efficiently than one can optimize a chain of ifs. This is quite important in a compile-and-run style language like perl.

Re:Switch statements are syntactic sugar (1)

jez9999 (618189) | more than 6 years ago | (#21752050)

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;
                };
 
            $_ == 123 and do
                {
                    # 123 stuff...
 
                    last SWITCH;
                };
 
            $_ eq "bar" and do
                {
                    # Bar stuff...
 
                    last SWITCH;
                };
        }

Aren't these two unrelated events? (1, Insightful)

Westley (99238) | more than 6 years ago | (#21750824)

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? (1, Insightful)

Anonymous Coward | more than 6 years ago | (#21750860)

Perhaps the Anniversary was the date set to have it all ready by. People set deadlines and they probably met the deadline hence it being released. Common sense plz.

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

supersnail (106701) | more than 6 years ago | (#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.

Channeling Jeb Magruder, are they? (1)

wiredog (43288) | more than 6 years ago | (#21751534)

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

A language where bless is a basic operation (1)

patio11 (857072) | more than 6 years ago | (#21751774)

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

Re:Aren't these two unrelated events? (0)

Anonymous Coward | more than 6 years ago | (#21751034)

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.
Yes it could. So?

I doubt the Perl community feels disenfranchised because of a week or month delay. After all, we've been waiting on Perl 6 since the turn of the century.

Re:Aren't these two unrelated events? (1)

ricegf (1059658) | more than 6 years ago | (#21751580)

I doubt the Perl community feels disenfranchised because of a week or month delay. After all, we've been waiting on Perl 6 since the turn of the millennium.

There, fixed that for ya. ;-)

Re:Aren't these two unrelated events? (0)

Anonymous Coward | more than 6 years ago | (#21751066)

Remember, we're talking Perl hackers here. Jesus 2.0 landing in Bologna in time for Christmas couldn't generate as much salivating over spaghetti.

Perldelta (1, Funny)

Anonymous Coward | more than 6 years ago | (#21750834)

The link should be perlDELTA, not perldata.

perldata link (1)

mariushm (1022195) | more than 6 years ago | (#21750872)

PerlData Link is actually this one [cpan.org] , not the current link that points to the blog.

Is this the version (2, Funny)

$RANDOMLUSER (804576) | more than 6 years ago | (#21750918)

that has the ORELSE operator?

Re:Is this the version (1)

dintech (998802) | more than 6 years ago | (#21751026)

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

Re:Is this the version (2, Funny)

supersnail (106701) | more than 6 years ago | (#21751192)

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:Is this the version (1)

$RANDOMLUSER (804576) | more than 6 years ago | (#21751348)

How is that different than following a function pointer in C?

Re:Is this the version (1)

dintech (998802) | more than 6 years ago | (#21751728)

Also, this is supposed to be satire so don't take it seriously.

Re:Is this the version (2, Funny)

Chysn (898420) | more than 6 years ago | (#21751196)

> that has the ORELSE operator?

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

Re:Is this the version (4, Funny)

vagabond_gr (762469) | more than 6 years ago | (#21751846)

This is Perl we're talking about here. It would be "orels".
Or whatever you set the $=] variable to.

Linus is right (0)

Anonymous Coward | more than 6 years ago | (#21750982)

I have to agree with Linus on this one.

Oh dear. (5, Funny)

Xargle (165143) | more than 6 years ago | (#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?

Re:Oh dear. (1)

sapphire wyvern (1153271) | more than 6 years ago | (#21751126)

Hey, it lets them shave a few characters out of "Hello, world."

Who says code optimization is dead!

Re:Oh dear. (1)

leonbloy (812294) | more than 6 years ago | (#21751284)

Planned for the next release:
  - shout() : similar to print(), but appends three exclamation signs
  - htmlshout() : similar to shout, but surround the string with <b></b> tags

Actually, I like Perl, but orthogonality has never been one of its strong points.
It seems that it's getting worse.

Re:Oh dear. (5, Funny)

macshit (157376) | more than 6 years ago | (#21751360)

"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. (0)

Anonymous Coward | more than 6 years ago | (#21751752)

Who needs threading when you have fast forking?

Re:Oh dear. (1)

Phroggy (441) | more than 6 years ago | (#21751828)

Come on guys, it's not like this [w3schools.com] is unique to Perl.

lame naming scheme (0)

Anonymous Coward | more than 6 years ago | (#21751008)

So does Perl know that version 5.10 > 5.8?

Re:lame naming scheme (1)

krog (25663) | more than 6 years ago | (#21751272)

Next you'll be complaining when I say that 4.4 > 5.4.

Anyway, the formal version number is 5.010_000.

$_ = 20 (0)

Anonymous Coward | more than 6 years ago | (#21751390)

I must say, I never thought I'd live to see Perl make it to. long years! To think, years ago the original Street Fighter had just been released. The PC first got the VGA standard years ago -- the Web? Forget about it -- years ago, the Internet barely existed as such!

Congratulations Perl on making it to glorious years!

I wonder if you'll make it to more?

recursive patterns (5, Funny)

hey (83763) | more than 6 years ago | (#21751412)

The new recursive patterns should increase perl's readability.

Thank you (0)

Anonymous Coward | more than 6 years ago | (#21751574)

Please provide five examples. Thanks in advance.

Re:recursive patterns (2, Insightful)

Kostya (1146) | more than 6 years ago | (#21751778)

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 (5, Insightful)

BodhiCat (925309) | more than 6 years ago | (#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:Much Thanks to Mr. Wall (0)

Anonymous Coward | more than 6 years ago | (#21751860)

Spoken like a true Java developer. You clearly have no clue what you are talking about.

Re:Much Thanks to Mr. Wall (2, Insightful)

Goaway (82658) | more than 6 years ago | (#21751940)

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:Much Thanks to Mr. Wall (1)

frith01 (1118539) | more than 6 years ago | (#21752264)

Welcome to real processing. I have several perl libraries and individual scripts that top the 20,000 line mark. These are used for medical transaction processing.

X Year Anniversary (1)

AveryT (148004) | more than 6 years ago | (#21751604)

Sigh. I wish people would stop saying that. It's "20th Anniversary." Anniversary MEANS YEARS.

Re:X Year Anniversary (0)

Anonymous Coward | more than 6 years ago | (#21752122)

anniversary (n'-vûr's-r)
n., pl. -ries.
The annually recurring date of a past event, especially one of historical, national, or personal importance: a wedding anniversary; the anniversary of the founding of Rome.
A celebration commemorating such a date. ----------------------

Happy Anniversary! (1)

ekimminau (775300) | more than 6 years ago | (#21751996)

Happy Anniversary, Larry!

Everyone, please don't forget to wish a Happy Anniversary to Randal L. Schwartz [stonehenge.com] and Tom Christiansen [perl.com] . The three of these gentlemen have created the Perl we all know and love.

I have been blessed with the opportunity of going to week long Perl classes with all 3 of these (well, Tom & Randal. Larry just came for lunch :) gentlemen/gods.

Merry Christmas one and all!

Re:Happy Anniversary! (2)

ekimminau (775300) | more than 6 years ago | (#21752080)

And don't forget my favorite Perl export here. [cypherspace.org]
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...