The sky's falling again? Each time this python-vs-perl lament comes up, I recall a bit of humor:

Heaven is where the police are British, the lovers French, the mechanics German, the chefs Italian, and it is all organized by the Swiss. Hell is where the police are German, the lovers Swiss, the mechanics French, the chefs British, and it is all organized by the Italians.

Hi oiskuu,

your little anecdote made me laugh at the end of along day. Thank you.

McA

Valuable? More like Unemployed. The fewer people using Perl, the fewer jobs using Perl.

Perl will always need legacy support, but being the new Cobol isn't what any of us want.

---

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

(Shrug ...)   Perl is a programming tool, and Python is another one.   If you’ve been in this biz any length of time at all, you switch very easily from one environment to another and are quite likely to use several different ones in the course of one project.

Python does have one advantage, though ... if you get fired, all you have to do is to sneak into the source-files and add or remove one tab-stop, somewhere.   ;-)

How did PHP and Python...

It’s interesting to watch these programming tools – ahh, pun (originally) not intended – “go fork themselves.”   Python-3 is noticeably incompatible with its predecessors, even though it is an incremental improvement, because in order to make those improvements they tinkered with some of the cornerstones of the language.   PHP has also gone through a fair number of language incompatibilities.   Each time this happens, the language-camp divides in two, and both must find a way to continue to exist in parallel – not always easy.

And Perl?   Well, Perl did, too ... except for the fact that it “died trying.”   Perl-6, like it or not, never made it off the ground as “the grand successor to Perl-5 and the fixer of all things (someone) thought to be wrong with it.”   So, Perl never [successfully] forked itself, and this might actually turn out to have been a very good thing for Perl.

Perl remained Perl-5, and it started inheriting some remarkable things, like Moose, which were actually built in and using the Perl-5 language system.   No other language that I know of ever did that.   None can say, no Moose;.   The amount of installed software in CPAN continues to grow, even as it remains compatible with what has been out there for so many years now.   Although Perl tried to fork itself, it never did, and I think that it ... yes, warts and all ... continues to grow more valuable as a result.

But no, not “at the expense of” or “versus” any of the others.   Programming tools live alongside one another, like it or not, and we wind up using them all, like it or not.   (Perl: “like it.”   Everything Else: “not.”)

Perl remained Perl-5, and it started inheriting some remarkable things, like Moose, which were actually built in and using the Perl-5 language system. No other language that I know of ever did that.

That other language is Lisp. Interesting that you've never heard of it... Interesting that reportedly wonderful object system didn't seem to help Lisp very much...

LISP: Lots of Irritating Silly Parentheses.

From a “purely philosophical, purely language-design, purely theoretical” standpoint ... (hey, it’s alcohol-time in my time-zone, so kindly hear me out)   ;-) ...

A significant notion in all(!) of these various arguments just might be:   “just how much language-functionality ought to be ‘in the language™?’ ”

The ls command provides some insight:   the perl executable is many times smaller than either python or php.   (In fact, of the three, perl is positively tiny.)

With perl, the basic approach is:   “use it (whatever ‘it’ is on your system ...), or, it’s not there.”   A statement such as use DBI; is, in fact, utterly dependent on precisely which version of DBI is currently installed upon this particular computer system, such that it might will have an altogether-different functional meaning on another machine.

Per contra, both python and php took more-or-less a different approach.   There is more “built-in,” such that “exactly what is ‘built-in’” is more or less consistent between “language versions.”

Which of these approaches is “right” vs. “wrong?”   Obviously, this is not the right question.   Obviously, both approaches work.   But I think that it does serve to point out that, when we compare these various programming languages (and, programming approaches ...) to one another, we are truly (and so, irrelevantly ...) comparing apples to oranges.   There’s more than one way to do it.™   And, all three of them await our bidding at the command-line.

-- The schizophrenia between python 2.n and 3.n and 2.n+1 in the various system and deployment scripts and packages causes me nothing but pain when playing sysadmin on my own boxes. As a non-user, if I weren't constantly told how great python is I'd assume it was just as much a mess as PHP.

Which is basically a branding / namespace / marketing problem.

Perl is stuck to increment subversions cause it's stuck to the decision to assign the number "6" to a language which is effectively a "Perl++".

Observing the problems between different Python versions - not only 2.7 and 3.3 - highlights how "much" Pythonistas really care about code quality and (backwards) compatibility.

Cheers Rolf

( addicted to the Perl Programming Language)

Hi Rolf,

it's an interesting discussion how to cope with progress in a programming language and backward compatibility. IMHO there is not a white or black to that problem.

E.g. when Python introduced version 3 it was a key issue to help the people to tranform their programs to 3.x. Whether this was so successful is another question. It was made worse with performance problems in 3.0 which didn't make a transition attractive. Python also faced the problem that the Linux distribution packages remained on 2.x as basis for the upcomming system tools (This is a really interesting question: Why were more and more system support or administration tools which is traditionally the domain of Perl made in Python?). This is the same with Perl. E.g. on RHEL 6.x which is common on enterprise environments the current version is 5.10.1.

So now, what are the solutions to the problem when you want or need additional modules or to be more up to date with your Perl runtime environment?

• Try to get happy with additional distribution prepackaged CPAN modules. This may work for simpler things and is often backed up by a company system policy.
• Install additional modules from CPAN into the Perl runtime environment. This happens when people start to use cpan without thinking further. If you install something which doesn't pull newer versions of prerequisite modules which already exist as prepackaged distribution modules, you have luck. After that point a big big mess starts up. (I've seen that many times.)
• You start to get aware that installing additional Perl modules from CPAN into system's Perl is not a good idea. Now you think about installing CPAN modules into a "private" directory to be independent from the system's modules. This hurdle was IMHO very high before cpanm and local::lib came up. But even with these two modules (let's pray the authors of these) it's not trivial. (Has anyone a link to a tutorial explaining the bits and pieces of how using a "private" CPAN directory works and must be set up especially with the different flavours of install and builing tools?). With this solution you stick to the distribution's Perl version. If you don't get bitten by a Perl bug or don't need a fancy new feature you may get happy with that (distribution's update service gives you security updates).
• The next step is to use App::perlbrew to create your own Perl runtime environment and let all scripts and programs point to the right Perl version and CPAN modules path. But with this step you have the same as you often see with JAVA. Programs are installed with a full blown runtime environment of a certain version. But what does this last step mean? IMHO in this cases you don't have a backward compatibilty problem any more (yes, I know that you have to pay a price at the other end, e.g. maintaining several module versions per runtime version).

So, what do you all out there use as your path out of this problem?

How should a newcomer cope with this issue? I'm sure he or she isn't even aware of that problem domain.

And now my personal key issue with newcomers (and oldcomers): How should they know what the current state of the art in programming Perl is (answering TIMTOWTDI to them is not a solution). How do they pick CPAN modules to solve their problems? How should a newcomer know what is good? And to that question Python provides IMHO a (kind of) solution: It comes with a library included matching many use cases ("battery included"). Not that it is not possible to find the same or better solutions on CPAN, but someone could get the feeling that this library can't be too bad if someone decided to include especially these modules to the core distribution. Why not using this library? And the whole process around changing and adding to that library is worth a look. I'm pretty sure that this aspect of "batteries included" is an advantage to the beginner and average programmer.

Just wanted to write "...this is my 2 cent...", but looking at the length of my post I have to say 76 cent. ;-)

I like Perl, I dislike programming language battles, but I also like to look around and learn from others and I want to be free to have the opinion that an aspect of a programming language may be solved better in a different language (look at Plack as a copy of WSGI). And if I get the feeling that Perl is loosing more and more people I want to have the right to ask "Why?".

McA

For as many problems and migration headaches as you get with Python 3, you might as well consider Perl6 to be on equal ground.

---

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

No, perl6 is years behind. If Python can't figure out what people should use after five years of having two credible major versions, when will perl6 get there?