Perl 5.14 Released

chromatic writes "Pumpking Jesse Vincent has just released Perl 5.14, the latest stable version of the venerable Perl 5 programming language. The list of changes in Perl 5.14 includes several enhancements, including performance tuning, Unicode improvements, and updates to the core libraries and documentation. Perl 5.16 is on track for a release next April."

Comments

What about Perl 6?

[Anonymous Coward]

Wasn't Perl 6 supposed to be available about, oh, 11 years ago?

Re:What about Perl 6?

[nysus]

I was just going to say that back in about 2001 someone gave me advice not to learn Perl 5 because a Perl 6 release was imminent.

Re:What about Perl 6?

[goombah99]

Perl 6 is out. But it's a diffent language in the same way that python 3 is not like py 2.7

The thing I really like about perl is it's the shortest oreily pocket reference. it's even shorter than c++. Yet you can do vastly more than python without importing a single lib. that is to say it's surprisingly concise for encompassing such a lot of capabilities in the core language.

Re:What about Perl 6?

[Anonymous Coward]

No, Perl 6 is not "out". I can't use it on my production servers, because there's no good implementation yet, even after ten years.

I know there have been a few attempts, but none of them are seriously usable like Perl 5, Python, Ruby, Tcl, or Lua are.

At least when developing Python 3, the Pythonistas built a production-grade implementation. Even if its adoption hasn't been as fast as was initially hoped, at least those of us who do want to use it can actually use it, and we can do so for serious uses. The same can't be said about Perl 6.

Re:What about Perl 6?

[Anonymous Coward]

that is to say it's surprisingly concise for encompassing such a lot of capabilities in the core language.

And it's the reason why it makes my anus hurt when I have to read it.

Re:What about Perl 6?

[Tacvek]

Perl 6 has 140+ different operators! That is absolutely insane. While I support being concise, Perl has far more complexity in the language core than any other language I have ever seen.

Re:What about Perl 6?

[Anonymous Coward]

Perl 6 is so damn complex that nobody can actually implement it.

Re:What about Perl 6?

[symbolset]

The more mature a programming language is, the harder it is to extend it. Mature languages have vast codebases that must be supported, and substantive changes break legacy support. That's why it's best to get it right early on.

Re:What about Perl 6?

[larry bagina]

He was right, but for the wrong reason :)

Re:What about Perl 6?

[bunratty]

Python 3 is barely different from Python 2. It is not backwards compatible, but I've ported Python 3 programs to Python 2 (when I realized I had to use SciPy or run the code on a system with only Python 2), and nearly the only changes I had to make were changes for // for integer division and required () for print -- and these changes were trivial if I could simply import from __future__. In contrast, Perl 6 is very different from Perl 5.

Re:What about Perl 6?

[Anonymous Coward]

Perl Nukem Forever?

Re:What about Perl 6?

[Anonymous Coward]

That's true. However, it has also been over TEN YEARS since it was first announced, yet there's still no good Perl 6 implementation.

It's pointless to worry about retaining compatibility when nobody is actually able to use your software in the first place, even a decade after it was announced.

Re:What about Perl 6?

[arth1]

With Duke Nukem Forever being released next month, I think we shouldn't lose faith in Perl 6 either.

It's taken 10 years, yes, but sooner or later they'll realize that what people are waiting for is a _native_ perl 6, not one on top of parrot, haskell, perl 5 or any other external engine. Cause if you virtualize, you might as well use the underlying langauge - it has to be at least as powerful as perl 6.

Re:What about Perl 6?

[Anonymous Coward]

Perl 6 will be the primary scripting language of the GNU Hurd if Larry Wall will fix his license.

Re:What about Perl 6?

[Anonymous Coward]

And it's the reason why it makes my anus hurt when I have to read it.

The reading glasses that the doctor gave you are meant for external use, resting on the bridge of your nose - not for internal use. Stop using them as a suppository, and your anus should stop hurting within a few days.

Re:What about Perl 6?

[goombah99]

have you ever seen a program that did not have a "print" statement in it? well those don't exist. And ignoring that whopper, I can tell you that it's not the big ones that really screw up legacy programs, it is the tiny tweaks that only go wrong one in a million times. Perl5.6 to 5.8 had some really really subtle changes to regrular expressions that broke programs in almost impossible to detect ways. Python 3 is death for legacy python.

Re:What about Perl 6?

[Anonymous Coward]

Maybe, just maybe, the more mature a programming language is, the less need there is to extend it. Particularly in the case of scripting languages. Write new programs and APIs with new features, not languages with more syntactic sugar. Boy am I glad to be free of the cult of that wierdo Larry Wall.

Re:What about Perl 6?

[Anonymous Coward]

IMNSHO I tend to think that like Python 3, Perl 6 is a broken version of a once useful language. I'll stick with Python 2.x and Perl 5.x.y.

Re:What about Perl 6?

[bill_mcgonigle]

Perl 6 has 140+ different operators! That is absolutely insane. While I support being concise, Perl has far more complexity in the language core than any other language I have ever seen.

I like this about English too. Can't tell that Larry is a linguist by training, can you?

Come to think of it, I bet Python developers tend to be fond of Esperanto too. Some similarities there.

Re:What about Perl 6?

[Anonymous Coward]

And have you actually seen the changes made between Python 2 and 3? As far as I know, the syntax is completely unchanged. There were a lot of changes in the library though, restructuring stuff and removing legacy code. Porting all my code (that doesn't depend on external libraries which require Python 2) still barely took any effort at all.

In my opinion, GP is correct. The mandatory () for print is one of the largest troubles I've been having. Another big one has been that xrange has been renamed to range, which forced me to replace all occuraces (which I did with a script, of course). If I recall correctly (I ported to py3k a long time ago), the program 2to3 takes care of those things for you. It also eliminates a lot of the search-and-replace.

Re:What about Perl 6?

[kiddygrinder]

erm... i'm pretty sure there are a lot of gui programs that don't use print. ignoring that i think fixing brackets on print is pretty fucking trivial. do you have any better examples?

Re:What about Perl 6?

[TheLink]

Actually I don't care whether it is native or not.

I want it fast. If they can get javascript to run fast, why can't they make perl faster? Heck get perl5 to run fast now and I don't mind "waiting for perl6" for another 20 years ;).

Re:What about Perl 6?

[sqldr]

Yet you can do vastly more than python without importing a single lib

Some would argue that this is a bad thing.. :-) It's not an accident that python without any libraries is completely useless.

In answer to the comments a bit further down about how languages getting more mature makes them harder to extend - well python has about 30 keywords. Perl has about 600. Python usually just has to replace a few libs. Python 3000 mostly fixes some 10 year old issues which date back to the infancy of the language, which will hopefully be the last time for a very long time someone has to do it.

Re:What about Perl 6?

[internettoughguy]

I think that Python needs a __past__ module for those nostalgic features like bracket-free print statements. Perhaps it could be a new PEP, and we could use a bizarre import statement like from __future__ import __past__ in Python 3.3.

Re:What about Perl 6?

[RDW]

"I was just going to say that back in about 2001 someone gave me advice not to learn Perl 5 because a Perl 6 release was imminent."

It's a shame that this 'Osborne effect' has hung over Perl for the last decade. I wonder how Perl 5 would now be perceived if Perl 6 had been given a different name and announced as a research project into language development, rather than the next version of Perl? With better PR, Perl 5.10 could easily have been 'Perl 6'.

All this tends to obscure the quet evolution of Perl 5 programming into what 'chromatic' and others are calling 'Modern Perl', using an idiomatic style that takes full advantage of recent language features (some borrowed from Perl 6) and CPAN to write efficient and maintainable code:

http://www.modernperlbooks.com/
http://onyxneon.com/books/modern_perl/

As always, a lot of the most active development is happening outside the core language. Anyone interested in some of the directions Perl 5 is going in today ought to check out projects like these:

http://www.iinteractive.com/moose/
http://plackperl.org/
http://www.catalystframework.org/
http://mojolicio.us/

Re:What about Perl 6?

[chromatic]

With better PR, Perl 5.10 could easily have been 'Perl 6'.

That would have been extremely silly.

Modern Perl 5 is a good language with great libraries, but Perl 5 still has many, many flaws that only breaking backwards compatibility in a very dramatic way could fix. You can take the Perl 5.10 approach of deprecating a few of the worst offenders and considering removing them and eventually replacing them, but that process will take decades.

Also, the Perl 5 core is very, very difficult to maintain.

Re:What about Perl 6?

[Anonymous Coward]

English is an incredibly complex language to learn and use correctly, though. Even native English speakers can't tell you what the "rules" are for writing and speaking it. So in what why is "Perl 6 is complex, just like English" a good thing?

Re:What about Perl 6?

[jlarocco]

So trivial that 2to3.py, which comes with Python 3, will do it automatically.

Re:What about Perl 6?

[RDW]

No, I didn't mean forget about re-designing the language (and its implementation) altogether and just carry on building on the old, flawed foundation. The goals of Perl 6 seem entirely laudable. I just think that the way this has all been presented to the wider community over the past decade hasn't done Perl any favours. Somehow a (false) impression has been created that Perl 5 is in some sense deprecated, while Perl 6 is not ready. If Perl 6 had been presented from the start as an experimental 'sister language' (perhaps with a different name), rather than being named as Perl 5's successor over a decade early, perhaps the perception would now be different.

Far less significant changes than those that occurred between Perl 5.0 and 5.10 (or 5.14) have been honoured by major version bumps in other software packages, which at least serve to indicate that some new and exciting features are available (which is what I meant by 'better PR'). But this wasn't possible with Perl because a drastically changed language design had already been given the Perl 6 name. Isn't your term 'Modern Perl' itself a way of saying that things have changed a bit since 1993, even though we're still using 'Perl 5'?

Re:What about Perl 6?

[Grishnakh]

Whoosh!

Re:What about Perl 6?

[Anonymous Coward]

That's a ridiculous statement. Perl 6 is design dependent upon a "virtual machine" methodology. Its supposed to run on top of parrot, or whatever they're working on to be the VM. To make a "native" compiler, would remove features they're expecting from the new language, like JIT and platform portability.

Re:What about Perl 6?

[chromatic]

If Perl 6 had been presented from the start as an experimental 'sister language' (perhaps with a different name), rather than being named as Perl 5's successor over a decade early, perhaps the perception would now be different.

People express that sentiment often, but I've never found it realistic. Many of the philosophical goals of Perl 6 are the same philosophical goals Larry had when designing Perl 5. Many of the tactical approaches are far different, but there's where my disagreement with the "It deserved the label as an experiment at the time!" idea arises. No one really knew how far redesigning Perl needed to go to achieve those philosophical goals until the RFCs and Apocalypses started pulling at loose strings in the sweater.

Isn't your term 'Modern Perl' itself a way of saying that things have changed a bit since 1993, even though we're still using 'Perl 5'?

Certainly, though it's less about using new and exciting features because they're new and exciting than it is about understanding how the language and its features, both new and old do—and, in some cases, don't—work. The biggest and most important language change has been the gradual lexicalizing of features such as filehandles, pragmas, grammar modifications, and even packages. You may have to squint to see the latter, but it's there. Perl 6 takes that principle to another level.

Re:What about Perl 6?

[arth1]

Easy, flexible, fast -- pick any two.

I've often found that I can do things quicker in perl than other langauges, not because perl itself is fast, but because it gives me the tools to implement faster algorithms without having to invent new spokes, ball bearings, tires and hubs. Just something as simple as caching database queries in a local hash can save ridiculous amount of time, with very little work. And sorting on a subset instead of entire tables? Priceless.

I also strongly recommend the perlperf(1) man page, as well as the web links found at the end of that man page.

Re:What about Perl 6?

[RDW]

"No one really knew how far redesigning Perl needed to go to achieve those philosophical goals until the RFCs and Apocalypses started pulling at loose strings in the sweater."

It's certainly easy to criticise all this with the benefit of hindsight - I don't imagine anyone at the time imagined it would turn out to be be such a long, drawn-out process.

The question nobody wants to ask....

[cowboy76Spain]

.... does it have any new operator? :-P

And before you tell, it was just a joke, I know you should now add operators in a minor release.

Re:The question nobody wants to ask....

[gman003]

Actually, I've always thought there should be one more common operator - "===". In floating-point context, it would be "approximately equal to", returning true if the arguments are within 10 times the smallest representable value. That would reduce problems with floating-point comparison. Hell, make it work for integers too - it might be useful in PLCs and stuff.

In a string context (in Perl, it would have to be something besides ===, but we'll get to that later), it would be "visually equal to" - any characters that are visually equal would be considered equal (useful mainly when using Unicode). So the Cyrillic "e" (0435) would be considered equal to Roman "e" (0065). I'm not sure how to handle complexities like "is the single character 'small a with macron' equal to the sequence 'small a' and 'combining diacritic macron'". We'll need a committee for that, probably. And since Perl uses different operators to determine context, we'd need something else for that. "veq", maybe?

This would, ideally, not just be a Perl construct. I can think of a lot of higher-level languages that could use that. Python. Ruby. Lua. Stuff like that. Lower-level languages probably would be better off without it - C does not need such an operator.

Just something I've always felt could be useful to have. Sure, there's probably some library that can do those things, but it would be nice to make things simpler.

Re:The question nobody wants to ask....

[Anonymous Coward]

Ruby already has an === operator. Override it to evaluate whatever weird definition of 'equality' floats your boat. http://www.ruby-doc.org/core/classes/Object.html#M001008

Re:The question nobody wants to ask....

[Anonymous Coward]

Not yet, but the changelog contains this:

C<?PATTERN?> (without the initial C<m>) has been deprecated and now produces a warning. This is to allow future use of C<?> in new operators. The match-once functionality is still available as C<m?PATTERN?>.

So stay tuned.

Re:The question nobody wants to ask....

[dorward]

This is version 14 of Perl 5. It is a major release. (Perl 6 is a new language)

Re:The question nobody wants to ask....

[gman003]

Huh. Cool. I never played with Ruby much, never saw that.

Re:The question nobody wants to ask....

[elfprince13]

This would conflict with "equality without type coercion" in Javascript and PHP.

Re:The question nobody wants to ask....

[formfeed]

.... does it have any new operator? :-P

Of course. Not every possible key combination has been used yet.

With previous versions of perl, a cat could walk over the keyboard and accidentally create valid perl code.
Now a cat walking over the keyboard will for sure create valid perl code.

Re:The question nobody wants to ask....

[gman003]

That reminded me of "Black Perl":

BEFOREHAND: close door, each window & exit; wait until time.

open spellbook, study, read (scan, select, tell us);

write it, print the hex while each watches,

reverse its length, write again;

kill spiders, pop them, chop, split, kill them.

unlink arms, shift, wait & listen (listening, wait),

sort the flock (then, warn the "goats" & kill the "sheep");

kill them, dump qualms, shift moralities,

values aside, each one;

die sheep! die to reverse the system

you accept (reject, respect);

next step,

kill the next sacrifice, each sacrifice,

wait, redo ritual until "all the spirits are pleased";

do it ("as they say").

do it(*everyone***must***participate***in***forbidden**s*e*x*).

return last victim; package body;

exit crypt (time, times & "half a time") & close it,

select (quickly) & warn your next victim;

AFTERWORDS: tell nobody.

wait, wait until time;

wait until next year, next decade;

sleep, sleep, die yourself,

die at last

That's actually valid Perl (only Perl 3, though - it breaks in later versions). And yes, I'm aware most of you have already seen it.

Re:The question nobody wants to ask....

[emarkp]

Actually, I've always thought there should be one more common operator - "===". In floating-point context, it would be "approximately equal to", returning true if the arguments are within 10 times the smallest representable value. That would reduce problems with floating-point comparison.

Thus exposing your ignorance of how to use floating point numbers. Thank you for handing me a new question for my interview list to highlight weaknesses of potential candidates. The "problems" with floating point are well-known, and if you use them correctly they do a fine job. If you're so ignorant that you blindly do a simple comparison test like this, it means you probably shouldn't be writing software that uses floating point.

Hardcoding an operator to perform this specific test (which is one particular way to compare for equivalency) is idiotic, and would encourage even more "programming by guessing" than we already have.

Re:The question nobody wants to ask....

[gman003]

No, I'm well aware of the problems with floating-point math. Hence why I have code that does "if (x - y
And I also know NEVER to use floats for currency. That's just asking for trouble.

But hey, thanks for flaming. If I'm not pissing someone off, I'm obviously doing something wrong.

Re:The question nobody wants to ask....

[Nutria]

it means you probably shouldn't be writing software that uses floating point.

Since I'm not a scientist or graphics programmer Floats are as damned useless and destructive as needing pointers to do string manipulations in C.

BCD should be the default data type for decimal arithmetic.

Re:The question nobody wants to ask....

[Eil]

Er, no it wouldn't because Perl is neither Javascript or Python.

Re:The question nobody wants to ask....

[petermgreen]

The big problem with an approximately equals for floats operator is that it provides no way for the user to specify the acceptable margin of error. So the language designer has to guess a value that they thing is "big enough" to avoid (possibly heavily compounded) rounding errors while not being so big as to cause unwanted matches. IMO that kind of judgement call should be something consciously made by the programmer (and they should be having the releated thought of "should I really be using a floating point type here at all" not something hardcoded into the language.

Similarly for strings "approximately equals" sounds like a nice idea but it's very hard to define in a robust way. Again probablly not something that should be in the core of a langauge but something provided by a library that can give options on what exactly constitutes approximately equals.

Finally using === to signify approximately equals seems like a bad idea given that many dynamic languages are using it for something closer to "exactly equals".

Re:The question nobody wants to ask....

[goombah99]

bite_me() if abs($x-$y)> $epsilon;

$t =~ tr/e/e/;
eat_me_raw() if $t eq $s;

Re:The question nobody wants to ask....

[VortexCortex]

I somewhat agree, however the floating point implementations SUCK at powers of ten -- you should specify epsilon in terms of powers of two. Hell, even my correct decimal text to float/double parsing function is 8 times more complex than the same in hex Why, even C has a hex float/double literal that goes something like this:
/[+-]?0x[0-9a-f]+\.?[0-9a-f]*p?[+-]?[0-9a-f]*/i )

The "p" in there stands for "times Nth power of two" similar to the "e" in decimal floats meaning "times Nth power of ten". eg: 0x123p-8 == 0x1.23

Note, hex decimal places act like decimal's do eg:
0x1.23 == (dec) 1 + 35 / 256 == 1.13671875 or (hex) 0x1 + 0x23 / 0x100 == 0x1.23

Specifying floats in the language of the computer's math (binary representable fractions) allows you to actually use equality properly ;-)

Some of my languages have the === operator already, similar to JS's exact match, perhaps ~=~ or =~= or "approx" would be better?
I've thought of adding an "approximate" operator -- esp. for physics simulation & game DSLs.

Although, what's wrong with specifying your required precision? Define your own epsilon (error factor).

print "$a is approx $b\n" if ( $a > ($b - $epsilon) && $a < ($b + $epsilon) );

# Compared to:
print "$a is approx $b\n" if ( $a approx $b );

# Oh, great, now we need another obscure magic special variable to contain epsilon...
# Perhaps $ë would do? Our English users won't mind using character map...

Re:The question nobody wants to ask....

[Anonymous Coward]

"This would, ideally, not just be a Perl construct. I can think of a lot of higher-level languages that could use that. Python. Ruby. Lua. Stuff like that. Lower-level languages probably would be better off without it - C does not need such an operator."

Re:The question nobody wants to ask....

[kiddygrinder]

true, but fucking around with that kind of thing between languages is really annoying when you work in both regularly

Re:The question nobody wants to ask....

[Hognoxious]

Thus exposing your ignorance of how to use floating point numbers.

Ignorance would be simply testing for equality and wondering why your code sometimes doesn't work. Clearly he's aware of the issue, or he wouldn't have raised it.

Hardcoding an operator to perform this specific test (which is one particular way to compare for equivalency) is idiotic, and would encourage even more "programming by guessing" than we already have.

I don't like his idea of having a fixed limit, but why couldn't it be done with a ternary operator?

Re:The question nobody wants to ask....

[Hognoxious]

The big problem with an approximately equals for floats operator is that it provides no way for the user to specify the acceptable margin of error.

Not without using a ternary operator, anyway. If you don't like that idea you could set something akin to an environment variable.

Re:The question nobody wants to ask....

[sqldr]

Actually, I've always thought there should be one more common operator - "===". In floating-point context, it would be "approximately equal to", returning true if the arguments are within 10 times the smallest representable value.

You can already do that in the language. More to the point, why 10 times? That's a bit decimalist isn't it? Shouldn't that be configurable, and if so, surely you would do so via a function. So now we have a function controlling the behaviour of an operator.. yuck! As for unicode, that's just getting speculative about its meaning. Is perl supposed to understand the shape of glyphs now?

You've probably gathered by now that I'm one of those crazy new-age freaks who dropped perl in 2003 for all but the odd 6-line sed/awk replacement (which is how it started out and did very well at it) for python precisely because of stuff like this that just makes it more and more confusing. Any suggestion like this on the python mailing list would be shot down by the language-nazis long before somebody made a terrible mistake which would have been an awful legacy. They spent 3 years arguing about how to implement ternary operators, and after much debate came to the following conclusion: just use 'if'.

What you want is a CPAN module. if (wavy($x, $y)) { do something }. OK, so you have to type 5 more characters, but do you honestly spend more time typing than thinking when you're programming? You can be thinking about what you're going to do next whilst you're typing w..a..v..y..

Re:The question nobody wants to ask....

[internettoughguy]

What about ~ ellipsis =, eg: (1.01 ~0.1= 1.00) == True?

Re:The question nobody wants to ask....

[internettoughguy]

oops, epsilon not ellipsis.

Re:The question nobody wants to ask....

[maxwell demon]

What about a =[ eps ]= b?

Re:The question nobody wants to ask....

[petermgreen]

why couldn't it be done with a ternary operator?

It could but imo that wouldn't be all that much of an improvement over writing abs(a-b) tolerance (especially if your language makes abs an operator rather than a function).

Re:The question nobody wants to ask....

[devent]

if ( isApproximatelyEqual(10.356, 10.356) ) { }
if ( isVisuallyEqual('a', 'a') ) { }

Wow that was easy. Do you have any other brilliant ideas for new operators?

Re:The question nobody wants to ask....

[mikechant]

# Compared to:
print "$a is approx $b\n" if ( $a approx $b );

# Oh, great, now we need another obscure magic special variable to contain epsilon...
# Perhaps $Ã would do? Our English users won't mind using character map...

But why not have something like
print "$a is approx $b\n" if ( $a approx $b by $epsilon );
as a pretty intuitive abbreviation of
print "$a is approx $b\n" if ( $a > ($b - $epsilon) && $a ($b + $epsilon) );

Re:The question nobody wants to ask....

[Anonymous Coward]

How about a "lookslike" operator? :)

if (wench .lookslike. aWitch) burn(wench);

Re:The question nobody wants to ask....

[Saint Stephen]

Maybe they could use that juicy GPU to do super fast BCD fast enough!

Re:The question nobody wants to ask....

[Hognoxious]

I assume eps is the threshold difference. That's "red cunt hair" in which language?

Re:The question nobody wants to ask....

[maxwell demon]

I assume eps is the threshold difference. That's "red cunt hair" in which language?

"eps" is short for "epsilon", the Greek letter commonly used in mathematics, especially in calculus, to represent a small positive quantity. Therefore I'd say it's "red cunt hair" in the language of mathematics.

Re:The question nobody wants to ask....

[tokul]

In a string context (in Perl, it would have to be something besides ===, but we'll get to that later), it would be "visually equal to"

So you want whole database of homonims and database of letters with diacritical marks to be stored inside program execution space. Do you imagine what kind of impact it will have on performance?

Re:The question nobody wants to ask....

[Anonymous Coward]

The answer to combining characters ought to be a resounding "yes", because (a) they're meant to be visually identical and (b) they're defined as being the same thing in unicode anyway (e.g. a search for "e+combining acute" should match "e acute"). No committee should be necessary! (Although they might be necessary for other things - should hook-g (in IPA extensions) be the same as the regular latin g? In some styles they are the same; in others they are distinct but their audience won't really notice it propely.)

Re:The question nobody wants to ask....

[Tom Christiansen]

In a string context (in Perl, it would have to be something besides ===, but we'll get to that later), it would be "visually equal to" - any characters that are visually equal would be considered equal (useful mainly when using Unicode). So the Cyrillic "e" (0435) would be considered equal to Roman "e" (0065). I'm not sure how to handle complexities like "is the single character 'small a with macron' equal to the sequence 'small a' and 'combining diacritic macron'". We'll need a committee for that, probably. And since Perl uses different operators to determine context, we'd need something else for that. "veq", maybe?

You cannot use visual similarities between glyphs that may or may not look similar in one font or another, because there exists no standard that spells out their correspondence.

In contrast, there does exist a standard that says whether two code points should be considered the same basic character. This is what you get when you compare two strings at the primary collation strength using the Unicode Collation Algorithm. This is perfectly easy to do in Perl, and is extensible to locale tailoring as well.

To do more than that is to ask to translate 133t$p3@k into normal text. It may have some applications, but it is not as useful as you think.

Re:The question nobody wants to ask....

[Eponymous Hero]

you seriously think any one of the Ps in PHP stands for Python? i'll give you a hint: the first P stands for PHP.

Re:The question nobody wants to ask....

[petermgreen]

the thing is it's not that much shorter than

abs(a-b) < eps

Is it really worth adding another trinary operator to knock about three characters off an "approximately equals" operation?

Re:The question nobody wants to ask....

[mr_mischief]

They have libraries for strings now. There are also arbitrary precision mathematics libraries.

Re:Meh.

[Anonymous Coward]

Where do I sign up?

Perl - the COBOL of scripting languages

[rubycodez]

Back in its day, Perl was vastly superior to its alternatives for web server language or large/large shell script jobs. So many superior (e.g. python) or just simpler (e.g. php5) alternatives have arisen while Larry vainly struggles on trying to turn Perl 6 into a swiss army knife complete with toilet, bowling ball and strap-less bra. Thus is the language is dying off, I see few projects done in Perl at my clients (which have tens of millions to billion+ dollar IT budgets). Sure, it's part of the important legacy code in various configuration and building tools for various OS that I use, but I could say the same for the remaining COBOL that lingers at my clients. It's undead but hardly living.

Re:Perl - the COBOL of scripting languages

[Anonymous Coward]

I still see perl getting used a lot - esp. in the financial services industry.

Re:Perl - the COBOL of scripting languages

[Anonymous Coward]

I think the problem is that Larry didn't know what he wanted Perl to be, so he tried to make it everything. But now we have C#/Java for strong type enforcement (for large projects with inexperienced people), Haskell and friends for academics and functional purists, python/javascript/lua/etc. for scripting...Perl just doesn't have a niche anymore.

Re:Perl - the COBOL of scripting languages

[rubycodez]

I don't, there is huge financial services industry in Chicago area, hot languages are dot-NET family, j2ee, objective C, c/c++, php5 , but haven't seen Perl for ages.

Re:Perl - the COBOL of scripting languages

[gman003]

Perl makes a GREAT "general-administration" tool. I use it as basically bash++ - it's the best way,bar none, to write programs on the command-line. There's a reason even the ultra-minimalist OpenBSD includes Perl in the default install.

Re:Perl - the COBOL of scripting languages

[MightyMartian]

Neither should Cobol, and yet, as with Perl, sometimes there is a thing called historical momentum. Perl is still used in a lot of places, and there is a helluva lot of Perl code out there.

Re:Perl - the COBOL of scripting languages

[rubycodez]

I love OpenBSD. But aside from scripts for mucking with perl itself, the reason perl is in the base install is to run the following (mostly brain dead simple) things:

in /usr/sbin:
add_user and rm_user scripts
apxs (apache extension DSO builder / installer)
pkg_chk, pkg_delete, pkg_info, pkg_create, pkg_merge (our simple and crude package manager)


in /usr/bin:
afmtodit font file creator for groff
c2ph/pstruct dump c structure with offsets from debugger stabs
find2perl convert find command with args to perl program
piconv character encoding converter
sed2p sed to perl converter


Nothing that couldn't be done better as a side effect to a rewrite to more modern and alive language, the apxs, package manager and add/delete user is probably the only things most people use beside some that might use the apache extension handler. That package manager is especially aching for better features anyway.

Re:Perl - the COBOL of scripting languages

[dskoll]

We still use Perl to develop our products (commercial and open-source.) Perl may be maligned, but it's still a good tool for a lot of purposes and if you pick and choose carefully, CPAN is an awesome resource. Perl has modern frameworks (eg, Catalyst) for Web development that are competitive with anything out there, and DBI is superior to most alternative languages' database libraries.

While I'm bullish on Perl 5, I'm not so optimistic about Perl 6. I think it's suffring horribly from second system syndrome and may never see the light of day as a useful production tool.

Re:Perl - the COBOL of scripting languages

[rubycodez]

but, as with COBOL, that momentum is running down while with other scripting languages things are heating up. I like a language where the attention of the found and key developers are focusing on what will be used in the near future, not flying off into lala land for a decade speaking to each other in isolation.

Re:Perl - the COBOL of scripting languages

[jimmydigital]

Excellent troll... really first rate. Did you get federal funding from the Ministry of Trolling for that gem? I've been working professionally in unix/linux environments for about 12 years and believe me perl is still quite alive and well doing real work in lots of different kinds of companies. Php is somewhat painful to code in by comparison but both have their place. Except for java.. it has no sane place but you still find it in use everywhere which just goes to show anything can succeed in this world with enough marketing dollars behind it.

Re:Perl - the COBOL of scripting languages

[Anonymous Coward]

Hackers, even if many moved to ruby with metaslpoit

Re:Perl - the COBOL of scripting languages

[Anonymous Coward]

Can't argue webservers/sites, but the command line?

Please. Python? Really? Really? Useful for some things, perhaps, but talk about overblown. And yeah, sorry, PHP is crap on the command line. (I'd say it's crap on the webserver as well, but that has less to do with the inherent flaws of PHP and more to do with, "LOL I R ROCKSTAR" PHP monkeys. :p)

There are actually worthy competitors to Perl, mind you, but Perl still wins by virtue of being included on systems by default. Rare is the case where you have to actually manually install Perl. Think the only time I've ever had to do that, actually, was with Windows systems. ;)

Re:Perl - the COBOL of scripting languages

[gman003]

Are you sure all that's in the base install? I can't see why apxs is there, since (last I checked) Apache isn't in the default install. And I think c2ph is only in the compiler "package", which is technically optional.

Although I do agree that most of that could be rewritten in sh or even in C, rather easily. And the package manager does suck.

Re:Perl - the COBOL of scripting languages

[rubycodez]

forgot in /usr/libexec has vi.recover and makewhatis in perl

had to check, but the c2ph/pstruct is in the base49.tgz

heavily audited chrooted 1.3 apache is in the default install,

,
It's sour grapes, I used Perl in development as was and fanboy over a decade ago. Major disappointment for me the way things went.

Re:Perl - the COBOL of scripting languages

[rubycodez]

well, all the other languages jacked Perl's DBI (and many, many other things) for their libraries.

Your company has history with Perl, but I don't think it will be chosen for new things now, PHP alone is mostly eating its lunch. Web serving the stats are something like 75% PHP5.x and 20% dot-NET but only 1% Perl with J2EE 5% (some overlap as sites run multiple langauges, but still....). Compare that to over ten years ago (when I was developing in Perl), it's really fallen.

Re:Perl - the COBOL of scripting languages

[rubycodez]

Troll? You mention java, there are five times the web sites using server-side j2ee (bloated crap that sells hardware) compared to Perl. Sure, it's everywhere doing legacy crap like the (spartan) OpenBSD package management system I mentioned elsewhere in this thread , but essentially no one is choosing it for new projects, i anything BUT Perl is the norm. Face it man, it's a 90s language and it is dying. Netcraft and other web stat sites help confirm it. And Larry is killing it.

Re:Perl - the COBOL of scripting languages

[jimmydigital]

All I'll say to that is that the entire computing world does not revolve around websites... or programming certification mills. =] Perl is the duct tape that holds the networked world together... and it's not dying any more than actual duct tape is. It's a refined tool used by professionals to do the jobs that have always needed done in a minimum of time and that don't cater to the latest buzz word laden development methodology.

Re:Perl - the COBOL of scripting languages

[rubycodez]

In default installs, Python is eating Perl's lunch on the command line, I can confirm by greping through my distro's /usr/bin and /usr/sbin. More python scripts to admin the system than Perl! That argument (in the default install) doesn't hold as much weight anymore, Python is also default in most major linux distros (and the new admin stuff is using that, while the crufty Perl admin scripts linger because no one cares to rewrite them).

Re:Perl - the COBOL of scripting languages

[jimmydigital]

no, that would be C, which also holds your Perl together. I can run and admin a server without perl installed, but not without C

I guess you missed the part about 'in a minimum of time'.

Re:Perl - the COBOL of scripting languages

[plopez]

COBOL is still alive and kicking. It still does some things better than any other language. As Scotty once said "Use the right tool for the job, laddie"!

Besides, COBOLScript is the COBOL of scripting languages:

http://www.computer.org/portal/web/csdl/doi/10.1109/EDOC.2000.882363

You should really do a bit more language evaluation. I don't know if you are ready to leave your parents' basement yet.

Re:Perl - the COBOL of scripting languages

[Eil]

Php is somewhat painful to code in by comparison but both have their place.

I respect your opinion, but my experience has been different. I forced myself to learn Perl twice and never could quite get the hang of it. So much of the language is context sensitive (e.g., this arbitrary symbol means a certain thing, except in some cases where it means something completely different) and there are so many features that I always felt overwhelmed. Sure, I always managed to get the code working but it felt hackish and thanks to "there's more than one way to do it," I was never sure if the way I implemented was the right way.

PHP is far simpler. It's the only language that I've learned solely by reading code. Yeah, PHP has its warts (I'm looking at you, zillions of global functions) but I never find myself staring at a line of PHP wondering what it's doing.

I don't agree with you about Java either, but that's a rant for another day.

Re:Perl - the COBOL of scripting languages

[iggymanz]

that "minimum of time" is only until the next poor SOB has to modify some code. Then it's time to go a-wadin' through the whale guts.....

Re:Perl - the COBOL of scripting languages

[ducomputergeek]

Our entire API framework is Perl and has been for a few years now. Seemed like every time we needed to add a new format to return values in (originally was XML) like JSON, there always seems to be a perl module "for that".

The best part of things is the fact that while we've added new functionality, we haven't had to do any maintenance work on the script in almost 5 years now.

Biggest change we made from 5.8.x to 5.10 was rewrite some nasty els if statements and made them switch statements.

The original web based management tool was originally written in PHP and that is what took all the time to maintain. It seemed like with each dot release of PHP some little thing broke and we were always fixing something every few weeks because of it.

Re:Perl - the COBOL of scripting languages

[Anonymous Coward]

I've been working professionally in unix/linux environments for about 12 years and believe me perl is still quite alive and well doing real work in lots of different kinds of companies.

That's pretty much an argument for the GP's point that Perl is the COBOL of scripting languages. Despite looking, feeling, and just generally being an ancient programming language, Perl is so entrenched in the computing world that it remains a cornerstone after all these years. Don't know what scripting languages a host has available? Well if it has anything, it has Perl. And why would it have Perl? Well somewhere there's bound to be a Perl script to manage some important process. So if you wanted to write a brand new script, why would you want to write it in Perl? Because the next host you install it on will have Perl, but it might not have Python, PHP, or whatever else.

Keep in mind that your post refuting the analogy didn't make an argument that Perl is a good language, just that it is still used and doing real work. You know, like COBOL.

Re:Perl - the COBOL of scripting languages

[chromatic]

I was never sure if the way I implemented was the right way.

The free book Modern Perl explains how to use Perl 5 in an effective and maintainable fashion.

Re:Perl - the COBOL of scripting languages

[bill_mcgonigle]

So many superior (e.g. python) ...if memory efficiency isn't on your requirements list...

or just simpler (e.g. php5) ... if you can remember to use different string function calls depending on the encoding of your variable (you always know this ahead of time, right?)...

while Larry vainly struggles on trying to turn Perl 6 into a swiss army knife

Larry's not involved in the most likely successful implementation effort (Rakudo). Heck, I'm not even sure there have been any language specification updates of note in the last five years.

Re:Perl - the COBOL of scripting languages

[kiddygrinder]

oh noes python is overblown! does that even mean anything? take your trolling elsewhere.

Re:Perl - the COBOL of scripting languages

[Greg Lindahl]

The new search engine blekko is written in perl - wrote our own NoSQL database in it, too. We found CPAN to be an awesome resource; we use 600 distros from CPAN, and only found a couple of bugs in them.

It's Java that's the new COBOL. (buh dum, ching!)

Re:Perl - the COBOL of scripting languages

[Greg Lindahl]

New startups using perl, courtesy of Quora:

blekko
nabbr
selectablemedia.com
goba.mobi
socialflow.com
duckduckgo

Big companies writing lots of new perl, also courtesy of Quora:

Lokku (makers of Nestoria), BBC, LJ, IMDB, Salon.com, Typepad, Zappos, Craigslist, FriendFinder, Ticketmaster, Slashdot

I think you're really confused about the role Larry plays in the community. He's slowly creating a new language, which has little to do with perl 5. Perl 5 is actively maintained and has a large community of users.

Re:Perl - the COBOL of scripting languages

[FreakyGreenLeaky]

Exfuckingactly. Whilst the buzz-word slavering IT managers and their Java sycophant underlings hype around in Brownian motion fiddling feverishly with websites, the rest of the professional world maintains the foundation and glue that really makes all the shit "just work."

With the possible exception of Python, nothing else comes close in satisfying it's intended purpose (talking toolkit/scripting/etc). Perl bashing reminds me of kids with snot-shiny upper lips whining about the "complexity" or "shortcomings" of C while not hearing the whooshing sound as the mothership-sized point sails over their heads.

Same with COBOL. Just because you don't encounter it in your little Javascript/PHP career does not mean it's not out their pumping major iron. You'd be amazed how many COBOL professionals there are laughing at the ignorance of these arrogant little dickheads talking out their anuses.

All programming/scripting languages have their place. They were all designed (some less so) to solve a specific problem.

Re:Perl - the COBOL of scripting languages

[Anonymous Coward]

If you would have paid attention while working in the professional Unix for that 12 years, you would have noticed that that environment too is marginalized and dying and the folks who still linger there live in delusion that writing GUI systems in C is viable.

Re:Perl - the COBOL of scripting languages

[Anonymous Coward]

Excellent troll... really first rate. Did you get federal funding from the Ministry of Trolling for that gem? I've been working professionally in unix/linux environments for about 12 years and believe me perl is still quite alive and well doing real work in lots of different kinds of companies. Php is somewhat painful to code in by comparison but both have their place. Except for java.. it has no sane place but you still find it in use everywhere which just goes to show anything can succeed in this world with enough marketing dollars behind it.

Very funny. A troll for a troll. I trust that the MOT has sent your check as well. Java does quite well, thank you, There are advantages to working with a system that is augmented by a massive system of support libraries and has mechanisms that - unlike CPAN - stand a passably decent chance of not being broken when you need to do a critical build on a new system.

Although Perl's "write-only" code can be off-putting when working with systems which don't see regular maintenance, one of the biggest reasons that I do a lot of my "quick and dirty" jobs in Python these days is that the Python library repositories, like the Java ones, are more likely to serve me up usable functions. Perl's excessive dependence on doing C compiles to build CPAN modules is a serious weakness. I've had too many tools fail to come up in new environments because the C code wouldn't compile for that OS/distro.

I have lots of Perl stuff, too, but it's mostly legacy. For anything new, it's more likely to work this way:

1. Shell script (if I can)

2. Python (if there isn't a big need for regular expressions)

3. Perl (if there's a need for regular expressions)

4. Java If it's going to be a full-scale Enterprise application system.

5. Other languages for specialized needs.

Re:Perl - the COBOL of scripting languages

[Haeleth]

superior (e.g. python)

Python has some advantages over Perl -- cleaner syntax, a better REPL, none of the legacy shell-script-derived cruft that makes it so easy to write terrible code in Perl. It also has quite a few disadvantages that make it harder to write robust code, such as its lack of any equivalent to Perl's extremely useful "use strict" and its poorly designed scoping rules.

I see a lot of new development taking place in both languages. I don't see much PHP, but that's a niche language restricted to web development, which isn't something I'm involved with.

Re:Perl - the COBOL of scripting languages

[Anonymous Coward]

bollocks, writing neat Perl code is just a question of adding two simple statements to your code:

use strict;
use warnings;

after you have done that, use perltidy and perlcritic on your code. What you then keep is maintanable Perl code. The next person having to modify some code then needs knowing some Perl, of course.

Re:Perl - the COBOL of scripting languages

[dskoll]

PHP alone is mostly eating its lunch

Interesting you say that... our product's Web interface is written in PHP and I rue the day I made that decision. For all of Perl's faults, PHP is about 100 times worse. No proper namespaces, completely wild-west wacky naming "conventions", no decent DBI-like library, crappy add-on modules (just try finding a decent YAML parser for PHP.)

If I had to do something new, I'd probably look at Python. I have very little experience with it, but it seems quite easy to use and fairly readable. Nevertheless, CPAN still takes the crown for a useful repo of modules.

There are still a lot of companies developing in Perl. They tend not to tout it or make much noise about it, though. It's not trendy any more.

Re:Perl - the COBOL of scripting languages

[mjwalshe]

Quite you can see the same problem with kids that don't understand why FORTRAN is still used in a lot of high end technical programming

Re:Perl - the COBOL of scripting languages

[MightyMartian]

If Perl's "wind down" is anything like Cobol's, then it's still got many years left.

Re:Perl - the COBOL of scripting languages

[Mozai]

php5 is simpler?  What planet do you live on?

In Perl:
curl -sL 'http://slashdot.org/index.rss' |perl -ne 'm/<title>(.+?)</ && print "- $1\n";'

Same thing in PHP5:
curl -sL 'http://slashdot.org/index.rss' |php5 -r '$h = fopen("php://stdin","r"); while(! feof($h)){$line=fgets($h); if(preg_match("/<title>(.+?)</",$line,$match)){echo "- ".$match[1]."\n";}}'

... and if you say "well, php5 is simpler for what *I* need," I'mma gonna poke you for thinking that everyone else has the same needs as you.

Re:Perl - the COBOL of scripting languages

[Anonymous Coward]

You're only looking at frontend stuff - we're developing plenty of stuff using PHP for the frontend but still using Perl for the backend scripting stuff which it's far better suited for. The closest comparable language for *scripting* is Python, and Perl can still outperform that in CPU. It just tends to hog memory because of a few early speed vs memory decisions which may be a little outdated on newer faster CPUs.

Re:Perl - the COBOL of scripting languages

[oiron]

I often have people asking me why C is still getting used.

C#/Java is all you need, right? Right?

Re:Perl - the COBOL of scripting languages

[bXTr]

my $troll = $ubiquitous_BSD_is_dying_troll;
$troll =~ s/BSD/Perl/g;
print SLASHDOT $troll, "\n";

Re:Perl - the COBOL of scripting languages

[Anonymous Coward]

I never made a single dime from writing in either perl, php, python or Java. I have used them over the years for various odd jobs and I know a lot of people like me. I can tell you that there are very few takers for perl now a days. if you had coded extensively in perl then it would make a lot of sense to stick with perl but a new guy surveying the landscape hardly finds perl an alluring choice. Perl is simply fading away despite it being present on every UNIX machine. Let's face it most of us are not slashdot's usual contra-I-do-what-no-one-else crowd.

Re:Perl - the COBOL of scripting languages

[dogmatixpsych]

That's why I am learning Perl instead of Python right now. I've done some Bash scripting but I'm trying to branch out a bit. My scripting needs are not huge, mostly neuroimaging-related stuff, but Perl seemed better as a bash++ environment (like you put it) than Python. I wanted to learn Python (I still will, just later) but I had two individuals independently recommend Perl for my needs rather than Python.

Perl might be a bit antiquated and awkward but it's the right tool for a number of jobs.

Re:Perl - the COBOL of scripting languages

[jsdcnet]

PHP beats perl for web applications for one simple reason: it was designed from day one to work as an apache module. mod_perl was a hack, and it worked OK for a lot of people, but for me it was always more trouble than it was worth. Eventually you had heavy hitters like Yahoo putting their weight behind PHP for web code and that pretty much decided the race. Re your specific objections: namespaces - use classes DBI library - use PDO

Re:Perl - the COBOL of scripting languages

[jsdcnet]

So much of the language is context sensitive (e.g., this arbitrary symbol means a certain thing, except in some cases where it means something completely different) and there are so many features that I always felt overwhelmed. Sure, I always managed to get the code working but it felt hackish and thanks to "there's more than one way to do it," I was never sure if the way I implemented was the right way.

I felt that way too until I read Effective Perl Programming. It goes over all the multiple ways to do things and explains why one is better than another in a particular situation. Great book. It gave me the Perl "aha moment" I needed.

Re:Perl - the COBOL of scripting languages

[rrohbeck]

If Larry really had pushed Perl6 it would have been ready a long time ago. He wanted Perl6 to be community designed; that's why it's taking forever.
I had to work on a mediawiki installation a while ago and had my first time encounter with PHP. Verdict: Brain dead.
Perl5 is still my first choice for anything that doesn't have to be efficient because it's only called every now and then. And the programs still start up faster than Java. By the time my vendor's Java code finally starts to run my Perl scripts are already finished. So much for byte code and JIT.

Re:Perl - the COBOL of scripting languages

[ToasterMonkey]

Nothing that couldn't be done better as a side effect to a rewrite to more modern and alive language

That just made me bang my head against my desk.

How about 'redesign' (if needed)
instead of 'rewrite in a newer language' (because)?

Re:Perl - the COBOL of scripting languages

[mr_mischief]

Perl 5 is the second system. Perl 1-3 built on earlier versions, and Perl 4 was a version bump to sell books which easily described the current state of the language (since 3 morphed a bit from start to end and they didn't want to specify an exact long version string for the book title).

Perl 5 added lots of features, like bless(), the default object system, proper modules, etc. These are where many people find the language creaky and messy -- where things not designed with Perl 4 got bolted onto the side of a mostly Perl 4 compatible language. Modern Perl 5 code doesn't look like Perl 4, but you can feed the system Perl 3 and it will generally work.

Perl 6 is the third system. It's designed by taking lessons from what worked and what didn't over the past 23 years.

Re:Perl - the COBOL of scripting languages

[mr_mischief]

Using classes doesn't overcome the fact that there are functions like mysql_real_escape_string_yes_I_really_mean_it_and_URI_decode_too in the main namespace. Classes and compartmentalized namespaces came far too late to avoid the issues.

Everyone is crazy..

[Anonymous Coward]

Stop complaining. Perl is still the shit.

Re:Everyone is crazy..

[Anonymous Coward]

s/the//

Perl is alive!

[fragermk]

Perl is alive!

Last time I checked Slashdot still runs on perl...

My company does too.

Now that ActiveState is providing Perl for Cloudfoundry, it's going to be good times in Perl land.

Re:Perl is alive!

[rubycodez]

last time I checked the UI of Slashdot was becoming ever more bloated, ugly and less functional. They should ditch the Perl for a modern language while rewriting the whole ball of shit.

Re:Perl is alive!

[PhrstBrn]

What does UI have have to do with the backend implementation? The UI goes in a bunch of template files, which could theoretically be language agnostic.

Any task (with regards to web apps) a modern language can do, Perl can do (and visa versa). One may be easier than the other for certain things, but Perl isn't a choice. Maybe not the best choice, but certainly far from unusable.

Re:Perl is alive!

[Anonymous Coward]

rubycodez is a troll.

I wouldn't be surprised if he cannot even code. The language running on a server is nothing to do with aesthetical design.

Re:Perl is alive!

[rubycodez]

not the point, the point is that the whole thing needs a rewrite anyway, so why not choose a living rather than dying language before doing it?

I do much coding as part of my job, haven't seen anyone choosing Perl for project in last decade, and my clients are huge municipal, state, and county IT operations with budget from millions to over a billion dollars. Perl is dying, it is undead.

Re:Perl is alive!

[palegray.net]

I'm sitting here writing a Perl 5 application right now. In fact, it's comprised of several daemons that work cooperatively to handle various tasks, all written in Perl. The user side is delivered via a pool of FastCGI daemons (served by nginx, fwiw), written in Perl. My "day job" employer uses Perl. I've got friends working as programmers in the public sector in a variety of areas of state and federal government and education, and they write Perl code frequently. I've got other friends in the financial services industry, and they're still writing new Perl code. In the not too distant past, I served in the Navy. Perl is alive and well there, too. These all add up to billions of dollars worth of budgets.

In short, the fact that you haven't seen it either means your exposure is more limited than you're claiming, or you're simply not paying enough attention.

For me Perl is alive and well.

[EEPS]

Despite what many are saying, Perl is still used extensively even for new projects. I use it daily, and while I really like ruby and python, for a variety of reasons, I have not switch away from Perl for most projects. My only question is when will Strawberry Perl 5.14 be released?

Re:For me Perl is alive and well.

[aixylinux]

I agree completely. As a UNIX sysadmin I frequently write scripts. For short and simple things, shell is preferred. But if I anticipate any complexity, I reach for Perl. I've had the experience of getting deeply into a shell script and thinking "I should have used Perl". Perl has never let me down, although I confess at times the programs have that write-only, line-noise appearance. But that's just because I've learned to use the idioms, and I comment on the complex stuff for the benefit of those who follow me--which could include myself six months later.

I'd write Ruby if I could. The syntax is cleaner, and objects are built-in, not bolted on. But Ruby is just not available where I need it. Does anybody know of an AIX LPP package for Ruby?

Also, I've been deeply disappointed at the progress of Perl 6--but Perl 5 does everything I need, so I really don't miss it. Of all sad words of tongue or pen, the saddest are these--it might have been.

Re:For me Perl is alive and well.

[PhrstBrn]

I agree. I can always find Perl installed (most of the *nixes come with this by default due to dependencies), but python is less frequently installed, and ruby is almost never installed. Perl works fine for those hack-type scripts, so I don't see a pressing need to go start installing ruby or python everywhere. If ease of use is the deciding factor for choosing the language, then Perl is certainly the easiest to deploy of the full fledged scripting languages.

Re:For me Perl is alive and well.

[chromatic]

My only question is when will Strawberry Perl 5.14 be released?

Strawberry Perl 5.14 may wait for 5.14.1 in a month.

Re:For me Perl is alive and well.

[Anonymous Coward]

I'd write Ruby if I could. The syntax is cleaner, and objects are built-in, not bolted on. But Ruby is just not available where I need it. Does anybody know of an AIX LPP package for Ruby?

Have you considered something like Pkgsrc to compile stuff that you need?

Re:For me Perl is alive and well.

[Anonymous Coward]

Curtis Jewell here, and I'm starting on that tonight. It's been stuck behind Real Life (i.e. getting the wedding preparations as far complete as my fiance and I can) and getting Strawberry's 5.12.3 finally out to release-candidate state and the installer-crash bugs buried and put to rest. (they have been painful) Should have the first beta build of the 5.14.0 installer done later this week.

but the power

[Anonymous Coward]

With Perl, that complexity gives you power. If one does lots of programming, and their mind is in good shape, Perl can be used to rapidly dispatch programming problems.

Re:but the power

[Galactic Dominator]

Nobody's mind is in a good shape after coding in Perl. Even reading it can cause mild permanent brain damage. Someone who writes a reasonably complex app in Perl has a very good chance of developing an uncontrollable homicidal rage and other social problems. For example, I hear the Unibomber, Timothy McVeigh, Dieter Simader, and bin Laden are all accomplished Perl grey beards.

Re:but the power

[kiddygrinder]

unless your problem is "what the hell does this code do that i wrote 6 months ago".

Re:but the power

[poopdeville]

You should learn how to use "abstract interpretation". "6 months ago" is a terrible excuse not to use a language. If you can express a complex idea quickly, by using "weird" operators, interpreting the idea is easy, specifically by ignoring the "weird" operators and focusing on the types/semantics of the things they combine. There are only so many sensible ways to combine values, so there are exactly that many possible semantics for the combinators that combine them.

"6 months ago" is the best reason to use a strongly typed programming language, so that you can be absolutely sure that abstract interpretation will work on parametric operators.

Perl5 is a lovely, expressive language, with a variety of strong abstraction operators. Perl6 brings all of Perl5 in, and extends the language with a built-in object system (using what experience with Perl5 hacking has shown to be the most useful)

Re:but the power

[Nimey]

You should really document your code, then.

Re:but the power

[kiddygrinder]

who said i didn't?

Re:but the power

[Nimey]

You should document your code in a non-shitty way. Seriously, if you can't figure out what you did six months later, your doco sucks.

Re:but the power

[kiddygrinder]

seems to work ok for python, c# and javascript. python i barely even have to bother.

headless camel

[Anonymous Coward]

can anyone explain the picture of a headless camel next to the article summary? Is this Perl's mascot? Does a camel with its head cut off act similarly to a chicken with its head cut off?

Re:headless camel

[danbuter]

I think the camel's head didn't fit. The pic probably needs resized. As for the camel, it's featured on "Programming Perl", which has been the main way to learn Perl for most programmers. BTW, "Programming Perl" is being updated for a maybe-December release. I was notified by O'Reilly after reviewing "Programming Perl" and saying it was old and out of date.

Re:headless camel

[pmontra]

Yes, the artist made a mistake: the image http://a.fsdn.com/sd/topics/topicperl.gif is too wide to fit into the template. Hopefully it will be noticed now. By the way, how do we report bugs about Slashdot?

Re:headless camel

[damn_registrars]

Yes, the artist made a mistake: the image http://a.fsdn.com/sd/topics/topicperl.gif is too wide to fit into the template. Hopefully it will be noticed now.

Don't count on that. It's been that way for some time now, and nobody with the ability to fix it seems to care. One of the former slashdot programmers was a regular voice on use.perl and he never bothered to fix it; I highly doubt anyone still working for slashdot gives a damn about it.

By the way, how do we report bugs about Slashdot?

Carrier pigeon, sent to the ISS.

Or at the very least, that would be just as useful as any other mechanism. Slashdot doesn't care about fixing bugs, just about implementing new ones. You can email rob malda directly (malda@slashdot.org) if you want, and he'll weasel his way around the problem in a reply to you. Or you can just do like the rest of us and bitch about the bugs openly here on slashdot instead. It also doesn't lead to them being fixed, but you can take credit for being the first to find a specific bug!

Re:headless camel

[pmontra]

Oh well, too bad for the camel. It's going to stay headless until the next major UI rewrite. Thanks anyway.

Re:headless camel

[damn_registrars]

Oh well, too bad for the camel. It's going to stay headless until the next major UI rewrite. Thanks anyway.

I'm pretty sure the last rewrite is responsible for the decapitation. I rather highly doubt that the next one will put the head back on.

Port already in MidnightBSD

[Anonymous Coward]

Perl 5.14 is already available in the MidnightBSD mports. Try it out folks.

bash not perl

[highacnumber]

I don't like Perl so I wish the catchy put-down of the summary title was accurate, but its not quite right. I think shell scripts are the COBOL of scripting. Perl might be more like B, although I'm not sure there is a great analogy there.

Perl 5-something?

[Kaz Kylheku]

Did I time warp to the 90's?

Re:Perl 5-something?

[rubycodez]

I had the same thought when someone mentioned Perl 6 would be out soon

Re:Perl 5-something?

[tempire]

This is a clear example of folks not really knowing what they're talking about.
Perl6 is a language spec, not a language implementation. Check out Rakudo if you want to see an implementation.

Even so, Rakudo (and any other Perl6 implementation) is *not* the successor to Perl5. It's an unfortunate naming scheme that people don't understand, and although there are similar and borrowed elements between the two, they do not directly relate to each other.

If you want to see activity, check out web frameworks like Mojolicious (http://mojolicio.us), or installation tools like Perlbrew (http://perlbrew.pl). There's also plenty of activity going on @ sites like: http://blogs.perl.org/, http://ironman.enlightenedperl.org/, http://perlbuzz.com/.

Not to mention plenty of jobs always coming across the wire @ http://jobs.perl.org/. Which, interestingly enough, some rubyists copied - http://jobs.rubynow.com/

Re:Perl 5-something?

[rubycodez]

So what? the point is that for over a decade, Larry and his cohorts have been farting around with Perl6 with no production implementation to show for it, just a bunch of endless mental masturbation

Re:Perl 5-something?

[mr_mischief]

All the while Perl 5 has been updated and refined, you fucking troll.

Re:Meh.

[Runaway1956]

Indians using proper Microsoft Certified development tools.

Did you write that with a straight face? Enjoy spending Microsoft's money, you pathetic shill!

I see dead languages

[iggymanz]

I see dead languages, languishing in the default installs of OS mostly as wrappers for menial tasks, taking command line arguments and making output in some cron and admin jobs, and they don't even know that they're dead! 8o

Re:I see dead languages

[FreakyGreenLeaky]

I see 19 year old "professionals" with a "programming" certificate purchased off the web. They're everywhere, fucking things up, creating work for the real professionals.

Gotta love them.

A more readable changelog

[shutdown -p now]

A more readable changelog, with formatting, hyperlinks etc applied (rather than a raw pod file) can be seen here

Re:A more readable changelog

[Anonymous Coward]

Tutorials on this section can be found at http://www.breakingvelocity.com

Java has its uses

[Billly Gates]

I decided to specialize in Java at college. Today, my business I want to start will be php based because I am 5x as productive with it, but Java is great for large scale programs.

With Spring, Hibernate, and MVC you can make great million line code web sites that are more like applications than simple scripts frankensteined together ala PHP. This is great for advanced database access and business logic and intelligence. For 90% of sites out there ... tiny ... Java is overkill. However with Java I can develop the app, extend it, modify it, and change it little over a decade compared to PHP and can make it scale from a shared single server all the way to an IBM mainframe.

I do admit I will only switch to Java after I have the revenue to hire someone to do it full time so it is not perfect. But if I were to grow my idea into a billion dollar company it would seem Java would fit my bill quite well. I know 10 years from now I can deploy the code and it will run securely with minimal issues.

Re:Java has its uses

[Greg Lindahl]

Perl has some nifty frameworks that can make you as productive as PHP for small web projects, and it also does large projects well.

But hey, if you're comfortable with PHP and Java, and want to pay to have your app completely rewritten, then more power to you.

It Lives!

[Tumbleweed]

Internet Yiddish LIVES!

Age Demographic

[Anonymous Coward]

Just reading the comments for and against perl and wondering about the age of the posters. How many new perl programmers are there? How many people are switching? It just sounds like some comments are from people with 10+ years of IT experience and bit stuck in their ways (just like I am with python!).

Is this perl's destiny http://news.bbc.co.uk/2/hi/also_in_the_news/7097647.stm

Re:Age Demographic

[cin62]

I'm new to programming (2 years), using perl. My job description is not programming, but it is one of the key components of what I do. Based on how suitable perl is for our projects, I'm convinced I'll use it 5 years from now.

Re:Age Demographic

[improfane]

'Stuck in their ways?'

It's people like me who have to clean up the mess people like you make because you'd rather use the hyped up tool than the tool that is suited to the job.

You are a prisoner of hype.

Python 3 is death to Python

[mangu]

Python 3 is barely different from Python 2

It's different enough to break the language for legacy code.

When you have code by the million lines, it's impossible to have a script that can reliably convert programs like Guido thinks it can. It's not just adding parentheses to print, there are some beastly things, like giving the division operator a different behavior. In Python 2.7, the result of (3 / 2) is 1, in Python 3 it's 1.5. I have absolutely no way to pore through those million lines and checking every division to see which operator should I use, keep the '/' or change it to '//'.

Besides, the changes from Python 2 to 3 are *all* in the direction of making it a more verbose language. I couldn't find any example of code that would be shorter in Python 3 than in 2. That goes against the philosophy of a scripting language, the last thing we need is a new Java.

I had gradually changed from Perl to Python over the years, but this P3k made me reconsider if this was wise. Apparently, there's no good-for-everything language left. So, in the scripting side, where quick results count, I've been considering switching back to Perl. Conciseness is king here, and nothing beats Perl at that.

As for large projects, thank god C is still there, still running K&R style code almost unchanged. Looking back over the years, I find that, for big projects, no language has given me less trouble than C. Once you get it running, it runs forever.

Re:Python 3 is death to Python

[Anonymous Coward]

I think that has more to do with it being a compiled binary.

Once it's working, you *don't recompile the damn thing*, so the C spec can go wherever the hell it wants and your compiler can be upgraded dozens of times, but your binary isn't affected.

Re:Python 3 is death to Python

[Waffle Iron]

In Python 2.7, the result of (3 / 2) is 1, in Python 3 it's 1.5. I have absolutely no way to pore through those million lines and checking every division to see which operator should I use, keep the '/' or change it to '//'.

When the // operator was introduced - over 10 years ago - they warned you that this change was coming. Ever since then, it has been prudent to use // wherever you want the answer of 3 divided by 2 to be 1. So if you had been coding according to best practices, you wouldn't have to look through all your code for divisions.

Re:Python 3 is death to Python

[goombah99]

I think you are missing his point. So you create a syntax that is an error that will be accepted. Billions of programs have this error. Then one day the syntax changes and no error messages are generated.

Consider is some language had = and == be the same thing, then they changed it so that = meant copy a pointer and == meant copy a value. your head would explode trying to track all that down.

Re:Python 3 is death to Python

[Waffle Iron]

I think you are missing his point. So you create a syntax that is an error that will be accepted.

Reasonable people should not have "accepted" the integer / operator, and they didn't have to. On integers, the operator didn't do what anybody would expect it to, and this was clearly just about the biggest flaw in Python 2.X. It's unfortunate that the flaw was there and needs to be fixed, but life isn't perfect.

Seeing the mistake, 10 years ago the Python developers gave you the tools to avoid using integer '/', and they told you the planned fix. If you simply followed their advice, you'd be fine now. Personally, I've always cast at least one of the operands to "float()" if I used the / operator, otherwise I've always made integer division explicit by using the // operator.

This is like when the C people tell you to not use the "gets()" function. That function was a mistake, even though it still compiles and runs. Competent coders just don't use gets(), and likewise, they don't use an unqualified '/' in Python 2.X.

Re:Python 3 is death to Python

[goombah99]

Y'know I never got the memo. Seriously I never heard of this before today. I don't think this is my fauly either. I own dozens of books on python and am well read. As a check to see if I'm the lone idiot, I just went through a bunch of random files in python libraries I've downloaded over the years. Only one of them had // in it. So apparently no one else got the memo either.

Re:Python 3 is death to Python

[Waffle Iron]

Here's your memo: PEP 238. I believe that it's frequently referenced in the "what's new" section of various point releases of Python since the PEP was published.

Re:Python 3 is death to Python

[goombah99]

Shucks, I stopped reading them after the first 200 I guess. Who has time to keep up with mere proposals. This is a bewildering way to run a railroad.

Re:Python 3 is death to Python

[c0lo]

Looking back over the years, I find that, for big projects, no language has given me less trouble than C. Once you get it running, it runs forever.

It is not with running that I have issues, it is actually with the results the run has. Pray, try compiling a code from 20 years ago on a 64 bits platform, code that that convert between an int and a pointer, and tell us how it went.

Old

[Anonymous Coward]

I stopped using Perl when I was 15, and even before then it was inferior.

Re:Old

[Corse32]

to? I find myself using it more and more, interfacing with all kinds of weird bug ridden SOAP APIs seems to be easiest with Perl...

Syntax improvements are a huge step forward

[lordlod]

There are some really good changes going into 5.14. Worth highlighting for anyone with Perl experience.

The Array/Hash reference mess has been greatly improved. You can now perform most builtin operations directly on array references. So no need to mess around with dereferencing things all over the place. This is a huge improvement in the syntax surrounding complex data structures.

The eval exception handling mess has been cleaned up so that error handling modules such as autodie can function properly without strange corner cases.

Re:Syntax improvements are a huge step forward

[Corse32]

The hash ref thing will save me some intense headaches, an array of hashes of either hashes or arrays of hashes? I thought I was going nuts trying to update a value in that mess.

Re:Perl vs Python, in OS scripts

[rduke15]

A recently installed server in a small company (Debian Squeeze):

        $ find /bin /sbin /usr/bin /usr/sbin -type f -exec file "{}" \; | grep 'perl .*script' | wc -l
        196
        $ find /bin /sbin /usr/bin /usr/sbin -type f -exec file "{}" \; | grep 'python .*script' | wc -l
        46

My notebook (Ubuntu 10.4):

        $ find /bin /sbin /usr/bin /usr/sbin -type f -exec file "{}" \; | grep 'perl .*script' | wc -l
        398
        $ find /bin /sbin /usr/bin /usr/sbin -type f -exec file "{}" \; | grep 'python .*script' | wc -l
        134

Of course, some may prefer Perl to grep + wc (it's faster too):

        $ find /bin /sbin /usr/bin /usr/sbin -type f -exec file "{}" \; | perl -ne '/(perl|python) .*script/ && $$1++; END {print "$perl perl\n", "$python python\n"}'
        398 perl
        134 python

Thanks for the info. Isn't Perl dying rapidly?

[Futurepower(R)]

Thanks for the excellent insight.

However, isn't Perl dying rapidly? Isn't Python the new Perl?

Remember all the jokes about Perl being a write-only language? The libraries are wonderful, but the language is discouraging.