First, anyone who says that Python or Ruby is not even comparable to Perl is full of it or very mistaken. They are close enough that we quickly run into the narcissism of small differences [1].

Second, in my experience HN ranges from uninterested to hostile when it comes to Perl. I read lots about Perl, but many of the blogs or forums I frequent are Perl-centric. My point is simply that you shouldn't judge by "what you read" if what you read is a function of what you choose or who you follow.

Third, and most importantly, the Perl5 community doesn't seem anywhere near dead. Off the top of my head, I'm particularly happy with a slew of new tools for working with Perl and CPAN: cpanm[2], perlbrew[3], cpan-outdated[4], pmuninstall[5], cpansearch [6] (written in C, but obviously made for the Perl community). There's also Plack[7] for modern Perl webapps. Finally, consider the whole Modern Perl[8] movement.

[1] http://en.wikipedia.org/wiki/Narcissism_of_small_differences

[2] http://github.com/miyagawa/cpanminus

[3] http://github.com/gugod/App-perlbrew

[4] http://github.com/tokuhirom/cpan-outdated

[5] http://github.com/xaicron/pm-uninstall

[6] http://github.com/c9s/cpansearch

[7] http://plackperl.org/

[8] http://github.com/chromatic/modern_perl_book

Now, even though the core language hasn't changed, there seem to be all sorts of clever Perl modules appearing which take advantage of a lot of Perl's highly flexible nature.

I really like Ruby myself, and really hate Python (even though I have to use it at work) but when the other languages fail me, I can almost always turn to Perl in a pinch and get it to do what I want. I also have to admit that the potential power of Perl6's syntax is a little astonishing; I think I would pick Perl6 over Ruby, for example.

Why?

High praise or a heavy put-down?

Also, I seem to hold the Guy Steele languages in highest regard, and consider the rest passable toys. C, Common Lisp, Scheme, Java, Fortran .. somehow they feel real. You crack open the spec and you're quickly welcomed into an intelligent dialog with the best minds in systems programming. I read several chapters of the Java spec last night and learned more about the language in one night than weeks of "googling" Ruby. The GSL-school of specification is precise, uses a well established vocabulary, and explains the syntactic and semantic rules of the language, along with their required execution environment. Not a word is said about add-on packages, installation crap, compiler internals or how to fork the language on github.

Compare these two and see what I mean:

http://docs.python.org/reference/index.html

http://java.sun.com/docs/books/jls/third_edition/html/j3TOC....

See how much more detailed the Java specification is; although the language has more features, the spec manages to be much more succinct and precise. The Python spec is littered with references to "CPython" and the internals of an specific compiler.

In my mind, it does it in a way that remains succinct and strict, thus avoiding the abomination of "enlishy" code (AppleScript, SQL to some extent, etc.)

Absolutely, and I mostly write ruby. I actually love that about python. But it feels optimized for writing code with a pen, not with a keyboard. Come to think of it, I don't prefer either for the reading of other's code. But ruby and perl seem to flow from my keys much more naturally than python.

Maybe if I switch from vi to emacs I'll change my tune? ;)

All of these things are not dealbreakers, and I'd rather code in Python than several other languages. But I never actively want to develop in it.

That being said, Ruby is close enough to Perl to where it would not be difficult for you to pick it up and in all likelihood you'll actually enjoy it (especially if you're been writing clean, object oriented Perl). If there's a Ruby-based job that interests you, go for it.

I personally, "moved on" (for non-trivial personal projects) onto Scala and OCaml: I actually like static typing (when there's type inference to reduce verbosity) and the mixed paradigms and "terse syntax" in these languages appeal to my Perl hacker DNA. The fact they're also blazingly fast means I don't have to "go down" to C++ (really, not all that hard in Perl with XS): the scalability of these languages (being suitable to whole variety of tasks, from simple scripts, to full systems) also appeals to me.

Sites like the BBC iPlayer system, and Omni Hotel's booking application are large public examples of Perl applications, Magazines.com is another. At the smaller end of the fence I worked on ParkingMobility.com, a REST system written in Perl with multi-platform clients (including iPhone), was written using Catalyst and the KiokuDB Object Persistence engine.

You have moved on, but so has Perl. Moose for example has had heavy influences from OCaml, Scala, CLOS, Smalltalk, and others. It provides anywhere from "some" (Moose has Type Constraints but not inferencing for example) to much if not more (Moose's implementation of Traits can provide state unlike Scala's from what I know) of the features of other languages.

The rivalry between Perl5 and Perl6 means that more and more of these features will be expressed. For example, I've seen some proof of concept code for implementing Moose's type system at the core language level (my Int $i = 'One'; # boom!). With a properly motivated hacker and the right direction this could turn into an excellent dynamic type system, or even a semi-static system similar to the one Perl6 is implementing. Having this kind of a type system makes lot of Web programming tasks much simpler to implement (and eliminates a whole range of security holes).

The current momentum in the community has me very excited for the future of Perl.

Yeah, me too, but that's the issue. It's great at that. Great at quick and dirty command line hacks. Hell, most of my PhD code was written in Perl. (Something I take a perverse satisfaction in.)

But it's not great for rapid webapp development, it's probably harder to hire people, there are fewer libraries and interfaces and open source toolkits, etc - so people like me moved from Perl to Python (it's a really easy jump).

I still use my old perl scripts now and again, but even for quick and dirty stuff I tend to use Python - just in case I want to come back to it later and have a chance of understanding what the hell I wrote. :)

(Aside: One of my summer internships was on the web backend team at my university's Engineering lab. We wrote an object oriented student class administration system, in Perl. It was quite probably the most hideous piece of software engineering I've ever seen...)

Um... What? According to http://search.cpan.org/, there are 85193 community-contributed modules. Okay, some of that is stupid stuff (http://search.cpan.org/perldoc?Acme::Meow) but they don't make up a large percentage. Compare that to PyPI's 11199 packages and RubyGems' 15674 gems.

Every package uploaded is given a Bug Queue (rt.cpan.org) so bugs and patches can be reported to the author. Additionally distributions can now specify in their metadata (META.yaml/META.json) the source code repository for the code so you can see from search.cpan.org the place to get the latest code to patch against. Additionally there is a process that if a maintainer goes rogue and stops responding, packages can be taken over. This doesn't happen often but has been used when other options fail. Many modern projects have several co-maintainers who can all make releases lowering the "bus factor".

Right now the biggest problem is finding the wheat for all the chaff. Sturgeon's Law applies, 90% of everything is crap. With 21038 (as of this writing) unique distributions, finding the ones that are well written, useful, and generally "best" is actually a difficult problem. You're not alone in finding that hard, but there are projects like Task::Kensho[2] to curate CPAN. This process is hard and would require a full time team of experts to perform properly.

It is big problem but one I think I'd rather have than when I was (for example) working in Java in 2005 and not only had to go through the effort of assessing the module in question (will this work? is it good? will I have problems later) but also had to hunt around the web for where all the different projects were located.

[1]: http://stats.cpantesters.org/

[2]: Full disclosure, Task::Kensho is a project I started in 2007 based upon the feedback of several people in the Perl community.

I disagree. Python is incredibly restrictive when you're used to perl. I would be so frustrated if I went that direction.

My side point was really just that if you know Perl, you don't have to do much to learn Python. Another commenter in this thread says Ruby's easy to a Perl-head, but I didn't find that to be the case personally.

These three though, have more in common. They all have roughly C-like syntax, passable functions, simple I/O, and good vector and dictionary support by default. To me, they're all the same language in different suits (well, pant-suits in ruby's case ;-).

I used to be a real big python fan, now it just seems like too much training wheels. I like perl's weirdness: its global variables, implicit returns, gotos and loop labels, weird calling conventions that, while unexpected, are perfectly well documented and reliable, and _boy_ do I love its string support.

I can usually find several different ways to do anything in Python, too. In fact I find this is true even for trivial things. For example, here are 4 ways to parse /etc/passwd and return a list of objects such that you can reference each value by the field name, for example:

    >>> passwd_data('/etc/passwd')[5]['shell']
    '/bin/bash'

Interesting, do you know what you talk about and have references?

AFAIK, there are some quite neat libraries and a better OO system than the usual competition (Ruby, Python, Java et al). Etc.

At the time, Catalyst was very unfriendly (a quick google - it still is) and nowhere near as rapid-accessible as Django, just because of the amount of head-twisting you have to do to get things up and running. It may have changed, but frankly I have little interest in investigating it, and I expect most other people who drifted away from Perl are in a similar boat.

Also, having developed an OO backend for a site running in Perl, I never wish to do so again. Your definition of 'better OO system' clearly differs from mine.

And this reply alone is proof Perl isn't dead.

[1]http://perldoc.perl.org/perlobj.html

Interop between Moose and legacy Perl 5 OO works just fine.

What problems do you mean with Moose and the blessed OO?

As for bless/Moose interop, I read somewhere there were big problems mixing the two but don't remember the specifics (I mostly dropped Perl a long time ago over its dogged attempts to guess what I probably wanted when I made a mistake). Others in this thread now say that's not true if it ever was, which is good news for users of pre-Moose CPAN modules.

Me too, which is one reason I'd like to remove it, or at least fix it.

For example, Moose has always made an effort to cooperate with the native Perl object system. The documentation in the perldoc's for object oriented programming isn't wrong. The skills you learn from perltoot and companions will transfer to Moose, you'll know how the underlying implementation works. Is this the right way to learn Perl's Object Oriented programming? That is an argument the Perl community itself is having[1]. As that argument is resolved the documentation is updated.

If you think about this in startup terms. Moose as a project is 4 years old. Would you invest in a startup that had an exit strategy that was targeted for than than 5 years? Moose has just recently (in the last year or two) reached a dominant market position when compared to the existing competition (Class::MethodMaker, Class::STD, etc) but still is adopted by only 5% of the total market (that is we have ~1K direct downstream dependencies out of about 20K distribution on CPAN). It would be premature to expect the industry to recognize let alone promote Moose as the de-facto standard. However it would be an excellent bet that sometime in the next few years that will happen.

Of the "Modern Perl" distributions out there Moose is one of the most consolidated in it's scope. Things like Catalyst have been gaining new competition (Dancer, Mojolicious) in their respective markets. It's interesting to watch things that appear to my untrained eye like market forces play out across the adoption of various CPAN modules.

To circle back around, perl documentation needs to strike a careful balance between what they can guarantee exists (bless $ref, __PACKAGE__) and what the community accepts as best practice (use Moose;). The documentation needs to intentionally be less dynamic than the fashions of the community. It must be conservative enough to provide continuity so that someone who happens to be on a perl-5.8.8 box (released 3 months before Moose, and still the standard on RHEL if I recall) doesn't learn a whole different set of "best practice" modules than someone on a 5.10.1 box. It does however need to be updated as things like Moose take over the mind share and prove themselves out. When only 1 in 20 modules you run into will likely involve Moose, you'll still need to understand the native solutions. When that ratio changes, the balance will need to change too.

[1]: http://stackoverflow.com/questions/980751/should-i-learn-per...

A really well argued way of agreeing with my point that perldoc pages should start with a reference to e.g. a page on perl.org with the present best practices for that perldoc page? :-)

Or maybe as close as possible to get of a formal proof? :-)

>>[Moose] still is adopted by only 5% [of CPAN] [..] It would be premature to expect the industry to recognize let alone promote Moose as the de-facto standard.

The counter argument is that new work generally seems to use Moose. But, of course, new work use the CPAN modules.

Well, that was impressive. Stupid, but impressive... :-)

>>discover and convince themselves that "man perlobj" is now bad advice yet remains official.

AGAIN: Those man pages doesn't discuss CPAN modules. But afaik, they recommend books and the web...

In this case, neither perlobj, perlboot, nor perlbot mention any CPAN modules at all, and perltoot cites a couple but Moose isn't among them.

  Post: "I've done a bit of X and my overall impression of Y in  was..." 
  Reply: "References, sources, double blind studies please! Prove you know what you're talking about..."

I asked because his claim went against what I've read on the subject. I don't really know, since I haven't really been working with web development for a couple of years (which is why I started with "Interesting").

  - perl: 4448 results
  - python: 1988
  - ruby: 1087

http://bit.ly/bFuh7x

(source http://jobs.perl.org/about/stats)

( nb. for people with no sense of humour, this was a stab at people who don't understand that correlation != causation )

So, some interesting tidbits to add to this "conversation":

1. Perl developers are older (on average) than those of other trendier languages. They were there at the dawn of the web. They are more experienced. They are also less expensive. But who wants to be an old-timer who gets paid less?

2. There is a negative feedback situ between developers choosing what technology to learn based on what companies are running on, and companies choosing a technology to run on based on what developers are learning. This sort of tragic loop is a social cancer which takes leadership and risk to overcome.

3. CPAN completely kills the competition. It might have something to do with perl, but it doesn't matter. This thing is outstanding, one of the 5 best things in software engineering... period. If you don't get this, you are deluding yourself and need to take a closer look at it.

4. Perl6 is going to blow the doors off the hinges because it is even more hacker-friendly than perl5 (which is ludicrously hackable).

5. Perl is dead to you.

Perl 6 is a really promising language with tons of cool features, and some similarities to Perl 5. It will pick up hype when it's 100% finalized, even though you can use it now.

Perl 5 (popularly known as "Perl") is old enough to be on the other side of "cool", but it's a perfectly good language, especially if you use CPAN.

Rakudo Perl 6 has had 34 releases.

> It will pick up hype when it's 100% finalized....

That must be Perl 5's marketing problem then, because it's not finalized either.

If that's changed, you should probably go update that. "Pre-release" is generally understood as a synonym for "not complete", right? There's no complete, finished implementation of the Perl 6 spec, right? Is the spec itself finished?

It's like you can't say anything about Perl (either one) on Hacker News, not even mildly complimentary things, without someone jumping on perceived slights.

If that weren't against Wikipedia policies, I would. Then again, I don't consider Perl 5 "complete" either, whatever "complete" means.

> There's no complete, finished implementation of the Perl 6 spec, right? Is the spec itself finished?

No to both, but why does that matter? There'll be a Perl 6.1 spec and a Perl 6.2 spec and so on. Meanwhile, people who find a Perl 6 implementation usable for their purposes will use it and people who don't won't. Fortunately, every release is more usable to more people.

As for "pre-release", I don't believe in playing linguistic existential games. Software exists or it doesn't. You've released it or you haven't. It does something or it doesn't. Perpetual betas and alphas and pre-releases and unstable versions and (even) release candidates are for people who lack the courage to release good software.

As for "perceived slights", insinuating that Perl 6 doesn't exist or isn't useful because the spec isn't "complete" (whatever that means) or no single implementation is "finished" (whatever that means) or no one has said "This particular release of this particular implementation is stable for every domain and every purpose and everyone who might ever want to use it" is awfully silly and (in my mind) deserves a challenge.

As long as the official language specification refers to Perl 6 in the future tense, I will as well. Take it up with Larry Wall.

For those of us who don't play linguistic existential games, BTW, Perl 5 has been "done" since 1994. I think most of us recognize that you can continue maintaining and updating software after it's done/finished/released. It appears the Perl 6 community has been innovative in the discovery that you can release software before it's done or finished and go Derrida on someone's ass for implying that an incomplete implementation of a draft specification is, in fact, incomplete.

chromatic's pedantry is a symptom of people like us ignoring the fact that even a language like TeX will only be done when the author decides it's done (Knuth's death for example). That and he's a grumpy-butt sometimes. Perl6 is a fully-functional language in that you can write useful (for some value of useful) scripts in it. The specification is undergoing radical changes, but then as I've pointed out the Perl5 specification is undergoing changes that some consider "radical" (if you doubt this, read threads on perl5-porters sometime ... look up the debate(s) about the "feature" pragma).

Valid complaints about Rakudo being an unfinished implementation of Perl6 are better centered around things like it doesn't pass 100% of the Spec tests yet. The Rakudo developers will (I'm pretty sure) own up to this, and point to the fact that they're working hard on it and that patches are welcome. That doesn't mean that Rakudo * was in some way "Pre Release". I don't recall anybody using the term "Pre" when talking about the Rakudo * release. The terms I remember are "early", "useful", "useable","for developers". If we as non-members of the Perl6 community go about continuing to imply that Perl6 is somehow less than released in a way for developers to generate useful and usable applications, we're gonna have the grumpier members of the Perl6 community call us on it.

It looks to me like you have a unique opportunity to contribute most effectively to Perl6 moving from being what you consider pre-Released to Released. You can submit a doc patch to change the tense in the Perl6 documentation.

Whether a software project is release-quality or not is a rather basic concept to everyone else. It can be intellectually tempting to try and deconstruct these basic concepts, but more often than not it's an exercise in evasion rather than illumination. Perl 6 (or Perl 6.0.0 for the pedantic) is a work in progress--at some point in the near future, the spec and implementations will be "done" to a point where everyone will agree that this is Perl 6.0.0, every implementation that matches the spec and passes the tests is Perl 6.0.0, and work will begin on Perl 6.1. Perl 5.0.0 reached that state in the past--16 years or so in the past to be precise. There's a distinction here that's dishonest to evade.

If the Perl 6 community is more interested in using linguistic evasion and deconstructing the concept of the finished release more than they're interested in actually making a finished release though, I'd best leave it to them. Maybe this is what Larry Wall meant about the postmodernism. Who knows? My mind is still blown by the observation that you have to doubletalk your way around the idea that Perl 6 hasn't reached 6.0.0 final yet.

Actually, I clarified what I meant in a previous post, when I characterized Perl 6 implementations as "incomplete implementation[s] of a draft specification". I didn't say it didn't exist, just that it exists in a non-final, pre-released state. Some people call them betas, some people call them release candidates, some people call them pre-release, and you try to cleverly evade the fact that every Perl 6 implementation is an incomplete implementation of a draft spec, but a rose by any other name and so forth.

I actually expect that some Perl 6 implementation will meet a finished 6.0.0 spec within the next 5 years. But none does currently. Which is a roundabout way of saying "it's not done yet", which is apparently doubleplusungood to state so directly.

I got into this trying to say good things about Perl. I guess you've shown me the error of my ways. If I'm going to have everything I say about Perl on Hacker News trolled by defensive Perl fanbois, I might as well trot out the old "explosion in an ASCII factory" joke again.

Edit: The problem is, you're seeing criticism where there was really none there. All I made was a statement of fact--Perl 6 isn't done yet. I've even clarified what I meant by "not done yet"--the spec is draft and the implementations are incomplete even against that spec. I think that's a reasonable definition of "not done yet", don't you? I never said anything about how long it's taking or whether implementation and spec will ever meet, you just projected those criticisms onto me because you're defensive about the issue. That's bad faith. Fuck, man, I even said Perl 6 would be done in the near future! How the hell do you get from that to projecting "I don't believe any implementation of Perl 6 will ever meet the 6.0.0 spec" onto me? Are you even reading my comments or am I talking to myself here?

Meanwhile, over in non-Perl-world, other people are (sometimes innocently, sometimes idly, sometimes maliciously) perpetuating these idiotic toxic "perl is X" memes which just poison the ecosystem for rational argument (in my opinion).

So you stepped into a minefield with good intentions, my thoughtful friend. But if I were on the Perl 6 team, I would be so frustrated by others out there who have this perverse obsession with what other people are doing, what other people are using, what other people are building.

It's not healthy, but regretably, it's also often very mean-spirited and has all the social utility of gambling on a cock fight.

I love what Perl has become, what the Perl community is, what the Perl 6 people are building, the UNIX-y culture, the spirit of adventure. It's really cool, and for those who don't get it, and don't want to, just move on (not you Phil).

Nonsense; even the release announcements say that directly.

All I made was a statement of fact--Perl 6 isn't done yet.

I wouldn't have objected if you'd written that. Characterizing software we've released on schedule for almost three years running as something thrown out in the world incomplete, ahead of an "official" release (whatever "official" means) is, I believe, incorrect and unhelpful.

Oftentimes what matters is exposure more than when something was invented. Erlang and Haskell came out in 1986 and 1990, respectively, but they're newer to most people than Perl is. Ruby and Python didn't have the exposure in 1995 and 1991 that Perl had.

(Interesting thought experiment--are there any obscure programming langauges today that will be all the rage in 2020, or has the internet accelerated that process?)

Perl 5 added lexically scoped variables ("my"), in addition to Perl 4's dynamicly scoped variables ("local"). Perl 5 added references, which is what made OO Perl possible (either "traditional" blessed hash references, or Moose, or any of the less popular alternatives, like "inside-out" objects).

I suspect the programming language rage of 2020 is currently some highschool kid's pet project (or some elementary school kid's daydream?) which no one else has seen yet.

Perl is Dead. Long Live Perl. http://www.oreillynet.com/onlamp/blog/2007/08/perl_is_dead_l...

It's an essay from 2007, but I think it's still relevant today.

Now, on the other hand, if I had actually taken the time to become a Perl monk, and good grasp enough of the awesome stuff coming down the line and know exactly how it would fit into real-world problems- Perl wouldn't even be close to dead to me. I'm sure there are a lot of people out there that are in that group. I'm jealous but not quite enough to actually try to get up to speed on it.

If it's not dead to you then I would recommend having no hesitations using it. It'll certainly be supported, and libraries... I mean, I don't know of anything that comes close to touching CPAN yet (dunno how Perl 6 fits in there). For me, though, it's dead as an alternative unless I see something amazingly compelling that I can't get elsewhere without similar learning investment.

Perl launched to fame by being able to talk to a bunch of databases and being easily (for the time) bindable to binary libraries, as well as having great low level access to the OS, as well as being a direct upgrade path for sed, awk, bash, csh and so on. Now people don't care about upgrading old shell scripts and don't understand awk's idioms, sadly -- everyone wants yet another C, and every other language talks to the various databases and binds to C libraries just as well plus have better toolkits for creating games.

Perl 5 is dead in the sense that COBOL is dead: all of the work is maintenance work; there are no entry level or intermediate positions; experts can still find work and will be able to for a long time.

Perl 6 does lots of great stuff but that alone isn't enough. Without a PyGame, Rack, and lots of other pieces, it's just a neat language design. Whether Perl 6 kicks ass very much still depends on where people take it. In a very real sense, Perl 6's success depends on me. I need to port Continuity to it (and its native coroutines!). I need to take more features from Seaside and show them off. I need to play with SDL stuff and make good abstractions. Busy, busy, busy!

-scott

For myself, I regret all the time I've spent learning and using it. Perl and C++ are languages for those who don't know better. I know because I've used both extensively. Powerful text handling facilities? Perl? You are kidding: Emacs Lisp burns it with a blow.

Now down-vote me like ants gone mad. If you have less than ten years of experience "struggling" with code, and you haven't learned a bunch of languages beyond mainstream ones, then you just can't understand.

> A current example is the "Who's hiring" thread which is now on HN: Most of the requirements are C/C++/Java/PHP/Python/Ruby, and almost none are for Perl.

C/C++/Java/PHP/Python/Ruby? Really? I was expecting HNers to be a little more innovative.

I was expecting them to be less insulting, but you still get upvoted.

Care to explain?

Community plays a large role here, I think.

The Perl community (both 5 and 6) overall has a practical can-do attitude. This attracts users.

Perl 5 seems to have more grumpy (though still helpful) users.

Perl 6 has Larry and lots of courteous, friendly, and helpful users. It's a community you want to be a part of.

The Python community has a "no, you're wrong -- that's not Pythonic" feel to it which I think turns a lot of users off to Python.

So, I think Perl 6 does have a chance. Personally, I'd probably be more on-board with Perl 6 if it didn't look so darn complex.

It isn't "dead" anymore than the Norwegian language is "dead".

It might just not be your first choice for your next project.

It's just pining for the fjords?

Kidding aside, it still does well here:

http://www.langpop.com/

Although if you put Ohloh and Freshmeat at 0, it does significantly worse.

I think most of the reason we don't care is because DDG's strengths have nothing to do with Perl -- except for maybe how easy it is to deploy/keep running and regular expressions.

No, Virginia, Perl is not dead. Not as long as there is more than one way to do it, or a hacker trying to finish something that was due yesterday.

Perl, as we know it, might pass from this earth. But the spirit it embodied, that first we should use duct tape to build on the work of others then write glue to make it stick, that getting-things-done was the primary goal --- this is too close to the core of our restless selves. A thousand years from now, there will be some startup somewhere with an urgent need and a hacker that strokes his chin and says, "I think I could write that in Perl[1]..."

[1] replace "perl" with your favorite language. Pick the right tool for the job. Sometimes means "the tool you are most familiar with", but that says more about you than about the language.

SysAdmins are slow to discard a good tool; hell, some of us still use bash. Perl 5 has been dominant for most of my career in this arena, and things will be quite slow to change.

I do see that Python is beginning to replace perl in the places where perl5 replaced bash in the earliest parts of my career... I remember back in the late '90s it was common to maintain two versions of perl on a system. Now, perl5 is stable... you almost never need more than one version of it, but I see systems (especially RHEL systems) with more than one version of python (sometimes more than two. Gah!)

As opposed to what? (Do all the cool kids now use zsh? That's my best guess.) Bash just had a major release, as well as a point-upgrade to that. How is Bash now a poster child for out-of-date good tools that people won't let go of?

a) Perl was used for EVERYTHING web-related in the early 2000s, but other languages and tools have come around to supplant it.

Several commenters have already said, "oh man I had to deal with this legacy perl code and it was awful," and yeah, that's a common experience and makes them think, "Perl is a terrible legacy language, I can't wait to trash it on my Ruby mailing list tonight." The negativity propagates and then people like you wonder, "is Perl dead?"

b) Web frameworks are one of those tools where frameworks like Rails and Django have all the hype. If you want to whip up your startup idea into a minimum viable web application, the trendy choice is Rails or Django. I've used Perl web frameworks like Catalyst and I'll be the first to admit banging out your "It's like Facebook... But For Cats!" startup idea is a lot faster in Rails or Django.

c) As Steve Yegge said in one of his blog posts:

'As I've done for a great many other programming languages, I've bashed on Perl's technical weaknesses at length in the past. To my continued amazement, the Perl folks are the only ones who never get upset. They just say "Haha, yeah, boy, you're right, it sure is ugly. Heh. Yeah, so, um, anyway, I'm going to get back to work now..." It's awesome. I've gained so much respect for them. It's almost enough to make me go back to programming in Perl.'

In my experience (which of course is just as anecdotal at Steve's), this is very true. Zed Shaw writes yet another blog post blasting whatever technology crawled up his ass and died, and we just smirk and update our modules on CPAN. But while that means we're not getting caught up in the "narcissism of small differences" (to refer to an earlier commenter), it also means we're not part of the noise on the web. There will probably never be a "Perl is a Ghetto" blog post written, and while that's obviously a good thing, it can also lead to the perception that, "man, nobody's talking about Perl, nobody's even bashing Perl, is it dead?"

d) That said, in my opinion these languages don't hold a candle to Perl when it comes to back-end engineering. We love talking about startups here at HN and thus, we talk a lot about startup problems and their solutions. But if your startup actually grows into a real company, you're going to encounter problems like, "we need a system to allow our analysts to manage our SEM campaigns and reconcile our cost and revenue" or "this partner doesn't have an API so we need to spider their interface to get the daily data and import it into our data warehouse." And any company that dismisses Perl as an option for those problems just because of (a) (b) and (c) is doing their company a disservice.

TL;DR -- Perl's strengths don't match the trendy topics on communities like HN, but it still has real value for real business problems.

http://www.modernperlbooks.com/mt/index.html

The real issue is that a language dies when new people stop learning it. Python's the language-du-jour of programming education (and has a strong position in science as a Matlab replacement, thanks to Numpy), Ruby's got Rails to give it momentum, PHP has Wordpress and Drupal as gateway drugs, Clojure and Scala are the JVM's great hopes, F# is the CLR's, and C#, Java and C++ will give you access to a lot of jobs.

Where are the new Perl programmers – in bulk – going to come from?

The world of non-programmers, same as always.

One of the best aspects of perl is the rock solid runtime, they have really gotten that right. Many of the newer languages like java, python & ruby have VMs that turn belly up after a varying amount of time, but perl just keeps running.

I prefer coding in ruby or clojure and I don't really like the object orientation syntax in perl. I'm looking forward to try out perl6.

Personally I don't expect Perl 6 to have a noticeable impact soon, I've read about it and I've never thought "that's what I've been missing all the time."

Let me tell you what I'm really missing -- something even simpler than Python which would allow me to draw the random graphical things with basic interactive possibilities but with the ease of old Basic languages. I've used tkinter a few times but every time I have to make something new I just discover I've forgot all the illogical things I had to do the last time, and the old source is not of much help, I know I'll have to spend trying a lot just to make something simple, so I lose the will to even start again...

I'm not really a game developer or have any idea about SDL, but from the Perl feeds I read (I think this instance was from Planet Iron Man) I gather that the SDL development was recently revitalized. They have their website at http://sdl.perl.org/ and since the Latest News entry at this time is from the end of August, it seems up-to-date.

So, there would need to be either a large enough crowd able to maintain the bindings for the engines and their extensions, or we need a more generic approach to C++ foreign library access. Since there are people working on better C and C++ FFI's,

I'm hoping for the latter. But that's probably mostly because I'm no good at C++, and such a layer would be my only way to use external libraries without available bindings.

However: many of us believe that Perl's day has come and gone and that truly modern languages like Ruby and Python have supplanted it. Absolutely true for me; I never use Perl when I can use Ruby -- not because of political reasons, but because Ruby is more elegant, readable, and concise.

As always, YMMV.

In what ways?

Certainly not in testing culture, nor available libraries, nor the power of features such as language extensions or object systems, nor in flexibility.

Screencasts, perhaps?

As others have written, Python and Ruby fill the same niches and have about the same features.

Spend a couple of minutes thinking about why on in Java or C++ (the answer is - tons of modules it uses).

Now try harder question - why not in Ruby or Python? ^_^

The world is the way it is, because it got that way. ^_^

Hope it makes more sense now, even if you don't prefer that style.