I recently turned down a job that involved revamping and tailoring a piece of work I did some years ago for a new end client. The reason I turned it down is because whilst the original used Perl; that was not acceptable for the revamp which had to be done in Python.

I don't like Python. Every time I've used it, it feels like a poor substitute.

Kinda like listening to an Elvis impersonator or a Beetles tribute band. It/they completely miss the point of what makes the original great. They go to great lengths to copy the superficial things; accents, cloths, hairstyles, even mannerisms and facial ticks; but completely fail when it comes to the important stuff; the music. They may sing and play all the notes in the correct order and key. They may even fairly accurately emulate the sound and tone and feel of one particular performance of each song they play. But listen to 3 live performances of any given track by the original artist and you'll notice that they are all quite different. Different in ways that are mostly too subtle for me as a non-musician to describe well; but you're never in doubt they are they. Each performance is unique and valuable for its uniqueness; and for originality; and because it shows the skill and growth of the artist.

The tribute bands meanwhile are condemned to only emulate, because the moment they add some originality to the performance; they fail to be a tribute any more and become karioki.

And that's how it feels when I use Python. Like a tribute band that opted to break out of the mould and add its own stamp on the original. Along the way of adding its unique contributions, it lost something, and many somethings that made the original so good. So usable.

For example, take regex. Like most every post Perl language, Python has "Perl-compatible" regex. Except of course, it isn't! It may be able to do pretty much everything that the Perl regex engine can do; but the way it does it is anything but compatible. It's not just that the regex features and syntax -- recursive regex; non-greediness; look-ahead/behind; embedded code et. al. -- but also the way the regex is used -- method call style versus top-level operators -- and the way they are (or not) integrated into the language.

Ie. The way perl re's operate upon $_ by default; the way substitutions can be both applied and tested in a single statement; the difference in operation between scalar and list context; that global captures can be returned en-mass or one at a time.

And that's just one language feature where a raft of subtle and not-so-subtle differences make Python a piss poor substitute for Perl. And there are many others.

Maybe if I'd come to Python first; I wouldn't always be comparing and noticing its awkardness; but that ship has long since sailed.

Turning down the work was no big loss in the scheme of things; it wasn't worth a great deal.

But it was an interesting piece of work -- the only type I take on these days -- that I would have enjoyed doing. Kind of an extension to a piece of work I did 6 or 7 years ago, though for a different ultimate user and purpose. The friend I did that original work for was adapting it and selling it on to a new client for a new purpose, and gave me first refusal on the new stuff. However, whilst the original was done as a C library that used Perl for the workflow glue and file handling; the new version will reuse the C library with some additions and use Python for the glue. And my friend tells me that this is the trend.

Not only because some client are specifying Python; but also because most of the other guys he farms work out to, are not just preferring Python, but positively anti-Perl. Not it seems because they have any particular aversion to Perl itself, but because they see it as an evolutionary dead end.

Not extinct; nor even yet on the critical list; but still vulnerable, bordering on endangered. In desperate need of a forward looking positive plan indicating where it is going and why. They are mostly young, and are unwilling to expend the energies and time acquiring skills in a language for which they see little demand and no clear evolutionary path.

The responses (and the lack thereof) to this thread/question pretty much sum up how I feel about the subject.

I don't need Perl to evolve and have a future. It continues to work well for those things I use it for as is. 5.10 satisfies my needs of Perl.

Most of what has come in p5 since has been either too buggy, or trivial, or too transient for me to have bothered to add it to my core lexicon. Most of what I use from 5.10 still works fine in all the later builds when they are the target. And the few things that don't -- usually because of the short-sightedness or sheer bloody-mindedness of the developers -- I've developed workarounds that I apply after the fact to code developed in my preferred environment. Which is fine for me, given my low development rate at the twilight of my career; but developing code to work despite the best efforts of the core maintenance team; is no way for those at start of theirs to go on.

And p6? It's interesting, but unproven. And possibly, unimplementable.

And in the time it has taken to get to the point where it is now -- which rumour has it is that it'll do about 90% of what P5 does; and about 30% of the P6 unique stuff; but with a performance that makes your 3.6GHz i7 look like a 400MHz Pentium 4 -- most of the then, big players in IT have disappeared; whilst many of the biggest players in the industry today have gone from startups to huge, mature companies that are now running, controlling and otherwise influencing much of it. Many millionaires (and billionaires ) have been made; careers forged; entire new branches of the industry have been born, evolved and come to maturity.

Too late for the mature P5 programmer; and too little, too nebulous, too radical and too slow to evolve for those starting out. It is seen as neither the successor to Perl5, nor sufficiently revolutionary to make it worth the learning curve, uncertainty and risk going forward.

So what future do I see for Perl? A slow, painful, but inevitable decline, first to obscurity, nicheness; and then extinction.

I won't affect me, so I'm all right Jack; but I do so hate the vision.

What future would I have liked for Perl?

• Perl5 with knobs on; and minus a few warts.
• Greater maintainability (of perl itself); a cleaned up codebase that encouraged experimentation and change, rather than fighting it tooth and nail.
• Greater performance; through a root and branch clean-up, rafactoring; re-writing of the core rather than ad-hoc optimisations.
• Greater extensibility; through loadable (domain specific) parsers.
• Greater concurrency; by refactoring using modern coding styles -- reentrant functions; removal of God-objects, global variable and static allocations - to allow threading to be integrated at the core.

But then, most of that is what most of those involved in the Grand Inquisition that started the Perl6 bandwagon were hoping for.

Unfortunately, despite the apparent democracy of the start; the Grand Inquisition turned into the Grand Vision. But the Vision was only seen by a few; and only seen in full by one; and along the way many of those that had seen a part of the Vision had Crises of Faith, and were excommunicated, and fell by the wayside. And whilst there has been a steady recruitment of new disciples to the cause; few have been party to the full Vision; and fewer still have been able to keep their faith for more than a short time.

And the rest is history.

I won't be giving up using Perl; but as far as its future is concerned. I've stopped looking.

And going by the lack of reaction to this thread; so have most others.