Perl 6 in 2009

lots of interesting and new stuff happened in perl5 land in the last 5 years. Major perl5 releases and lots of interesting projects. To name a few (mainly related to the web, which is the area that matters to me):

- Moose http://bit.ly/8J7qJu

- Plack http://bit.ly/4NhAOl

- Tatsumaki http://bit.ly/4zJbWG

- AnyEvent framework http://bit.ly/4ODUiX (with a lot of extensions: XMPP, irc, etc...)

- strawberry Perl on windows

- About day to day usage: NYTProf3 is out http://bit.ly/6drmyT

The community is vibrant as you can tell by looking at github, stackoverflow, perlmonks, http://ironman.enlightenedperl.org/ etc

Yann

If you are referring to business/commercial projects in the last 5 years then this is what I know:

1) Direct knowledge: I've been involved in a few medium to big projects for two of the big car manufacturers. Currently involved with big reporting / MIS web projects for two of the biggest car rental companies.

2) Word and mouth from ex-colleagues & friends: Perl is heavily used in the financial market, especially here in City of London. After Java, there were lots of Perl programmers who were unfortunately given the boot during the recent financial crisis :(

3) From the grapevine (ie. web!): http://bit.ly/5S7UMa This link mentions a list of companies that have had Perl apps built for them in last 5 years.

    "I would like to know what motivated your choice of language"

In my case its mainly because I'm more competent in Perl and its been my main language of choice and circumstances for well over 10 years now.

I have and continue to use & play with other languages/frameworks but given a blank slate I think Perl would probably still come out has my #1 choice because of CPAN and its maturity (language & VM).

My company's publishing system runs on Perl 5 (and some LaTeX macros). That's the core of my business.

We used Perl 5 because we know the language well, because it has great tools, because it scales from command-line programs to big systems, and because a lot of what we need is serious, fast, and reliable text processing. I have a great deal of confidence that any bugs we find will be easy to resolve, whether it's a problem in our own code or a CPAN component or the Perl 5 core itself. (There have been few bugs; all of them in our own code.)

Lots of stuff that's built in Perl, doesn't really advertise itself as such. From my own experience in building products over the last 5 years, MailChannels Traffic Control ( http://mailchannels.com/product/ ) is built in Perl with some C where stuff needs to be speedier and Enquisite's products ( http://www.enquisite.com/products/ ) are all heavily Perl based on the back end with Flex RIA front ends.

I'm currently working on a new startup that's built in Perl as well. I picked it because I have lots of experience with the language (and as usual, I'm doing something "tricky" where a solid understanding of the language will really help), it deals well with the problem domain I'm working on, and I need both a good web framework (Catalyst), a backend job queuing and processing system (POE) plus a bunch of infrastructure bits that are conveniently already on CPAN. I've also noticed that finding good Perl people to work with has never been much of a problem, but that may just be an artifact of location (Vancouver/Victoria) and previous experience (I know a lot of ex-ActiveStaters). My experience has been that some of the more hyped languages/frameworks have a lot of snakeoil salesmen jumping on their bandwagon, which can make it tricky to discern the talented from the talkers.

One of the problems that the Perl community has (I think) is a lot of us don't really hype Perl that much as being the driving force behind some of the cool products we build in the same way that the Rails community, or some of the more "popular" frameworks/language communities do. This can lead to the appearance to outsiders that we're not innovating and that cool stuff isn't made in our favourite language. Rest assured, we are; it is.

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.