I have worked for an consulted for some of the companies mentioned in other responses to this thread. I can attest from personal experience that one large web a

I have worked for an consulted for some of the companies mentioned in other responses to this thread. I can attest from personal experience that one large web application (>6 million uniques / month) is using an Enlightened Perl stack (Catalyst + Moose + DBIx::Class), as well as several internal projects for house-hold name companies (Walmart, Marriott, American Red Cross for example). More directly I have been responsible for the back end of at least 2 applications in the iPhone store. The most recent of which is an app called ParkingMobility. ParkingMobility tracks disabled parking places via user submissions on the iPhone. The REST server that powers this app is 3,344 lines of Perl, and 32 lines of shell (mostly for our continuous integration server). The reason I chose Perl is first familiarity, I use Perl daily and have for over 10 years now. I have been working with the specific tools in this app, Catalyst, Moose, and KiokuDB for at least 3 years. None of these projects is older than 5 years old, though Catalyst turns 5 later this month. Second though is that these tools have provided me with a quick and agile development platform. The server for ParkingMobility for example had one developer[^1] and went from roughly scratch[^2] to release in a little over a month of developer time. This includes 95% coverage for my test suite and two large design changes (one after we'd sent the client a second release candidate). The app is broken out into 46 files, the largest of which is 183[^3] lines long. This code is (to me, and most of the people I work with) still highly legible if a bit idiomatic. The conciseness means that at any given point there is only so much context you need to be aware of at any given point in time, much like lisp. Does this give some reasoning of why some of us still choose to write large projects in Perl, even if you haven't heard of them? [^1]: To be fair, I have a partner who did 100% of the iPhone client while I did 95% of the server code. He's waded in and done cleanup work while I was unavailable as the owners are his clients. [^2]: I'd written a similar application previously so I had the architecture but I rewrote basically every line for ParkingMobility [^3]: The Controller for adding/updating/retrieving new Locations (ie Parking Spots). Since this is the main functionality of the App, and I tend toward fat controllers and thin Models personally I think 183 lines is reasonable.