Hacker News Reader

It sounds like "being a perl programmer" was one of the main characteristics you and your boss were looking for in the beginning... this is a red flag for me- if I am learning more about a job and they seem too concerned to get a "perl programmer", "java programmer", etc, I know to steer clear- it means the people designing the software and managing the projects think its hard to learn a new programming language which means they themselves probably arent good. At moment, there are plenty of programming jobs, and there seems to be a demand for perl programmers- probably because it has fallen out of favor with fresh grads and also a lot of the perl openings are for working on existing code base instead of a new shiny project. I dont blame the kids- they should go work at start ups. But they shouldnt for a moment buy into the anti-perl sentiment that pops up at software meetings and conferences (perl 6 jokes are just easy one-liners for people with no imagination).

The problem revolves around being able communicate what's going on. If you try to be helpful and informative and say something like "Object-oriented software engineer (Perl)" as your job post title, you immediately (a) get every schmuck who once did testing with Perl who is now searching for 'perl' to apply, even if they don't know any OO, thus jamming the interview process, (b) immediately get most anyone else to say "ewwwwww, Perl, I'd never be interested / I have no experience". You have to end up saying "Object-oriented software engineer in a dynamic programming language", request people in with experience in (e.g.) languages such as Ruby, Python or Perl, and only mention that it's actually in Perl further down the post once you've got their attention with the rest of it. This is a trifle more manipulative and less straightforward than a decent straightforward honest software engineer would instinctually prefer. Anyway. It's true, a couple of of the best candidates actually hired there came from Python backgrounds.

By contrast, I assume you can say something like "Object-oriented software engineer (Python)" or "Object-oriented software engineer (Ruby)" (or Frontend Engineer / Backend Engineer / etc) and not have this particular set of problems. I don't know what problems you would have, but... not those.

Now, to be fair, it worked marginally better when the company-recruiters weren't all jerks about letting us post a programming challenge with the posting (because it didn't fit in with a preexisting workflow)... which makes it easier to find the random Spanish major with decent programming instincts and a little Perl. But still.

If you're the rare actual-really-good Perl programmer looking for a job, I am aware of two places willing to hire you, one in Sunnyvale and one in NYC.

Most of the great Perl programmers I know either have full-time jobs or have little desire to relocate. (I'd entertain interesting short-term telecommute gigs now and then myself.)

Are there really any compelling reasons to use Perl over Ruby for greenfield projects (i.e. not legacy maintenance)? I've written maybe a dozen medium-length Perl scripts (but nothing very large) before I got into Ruby, and I can't seem to think of anything that Perl does that can't be done at least as well in Ruby.

Honestly not trying to start a religious war here - just curious - and I think it's fair to compare the two languages as they are both runtime interpreted and have relatively similar characteristics (and obviously Ruby took a good dose of inspiration from Perl, anyway).

Are there really any compelling reasons to use Perl over Ruby for greenfield projects....

That's exactly what I'm doing. Reliability is only one reason I chose Perl over Ruby, but upgrading three real-world applications my business relies with their dependencies on to a new major release of Perl 5 in an afternoon while doing other things and only having to intervene three times is a tremendous boon.

Upgrading from Ruby 1.9.2 to 1.9.3 wasn't that easy.

It depends on your infrastructure. Some setups just don't have an infrastructure setup to make the transition easy.

For me, personally, these are some of the reasons:

* I've had more years of Perl than I have of Ruby. While there's not a massive difference it comes a bit easier to my fingers and brain.

* The testing framework is better - it's much easier to integrate different styles of testing and integrate tests running in other languages

* I can usually get more people to do my work for me with CPAN than I can with rubygems

* Moose has some interestingly different ways of breaking up abstractions (Moose is the de facto way of doing OO in Perl now. Moose is to Perl as CLOS is to Lisp)

You're probably not going to be suddenly more productive if you switched to Perl - but there are some plus points. As does Ruby of course.

Swings or roundabouts. Your choice :-)

The reasons I would cite: the Ruby development community leaves a lot to be desired from a sysadmin's perspective. We went through similar pains with Perl, but they're mostly a decade or two behind us. With Ruby, there are multiple concurrently maintained trees, it's hard to sort which one should be "primary" on a system, and you have to do a lot of serious grokkage to understand that RVM isn't really intended for maintaining system Ruby installs, but a local per-user developer instance. Which, when what you've got Ruby for is managing chef, is a more than slightly whack.

http://www.lucas-nussbaum.net/blog/?p=617 http://www.lucas-nussbaum.net/blog/?p=681 http://news.ycombinator.com/item?id=2059964

Much of Perl's use is by sysadmins, which means it plays well in their space. By contrast, much of Ruby's use is by web developers, many of them on bastardized MacOS systems (they're born bastards, it's not the developers' fault ;-). Which means that Ruby's packaging is whack.

I don't hack much of either, though work around both. The nice thing about Perl from my perspective is:

1. It's included with the system. I run Debian/Ubuntu boxes if I can possibly help it, Perl is of of the tools used to write a whole slew of system scripts, and as a consequence, it's very well managed within the distro. Red Hat/CentOS aren't far behind.

2. CPAN plays nice. Under Debian, your CPAN bundles are installed to /usr/local/ Debian's just sorting out where to store Ruby gems.

Thanks to chromatic for mentioning perlbrew. I've encountered RVM in the past month or so and have been trying to wrap my head around it. Understanding RVM in terms of perlbrew helps a lot: http://ithaca.arpinum.org/2010/06/13/rvm-and-perlbrew.html

I'm a Perl weenie through and through, and I ask myself this every time I start a new project, because I know one reason I turn to Perl each time is because I am /fluent/. Hiring Perl developers is hard, Perl has some ugly bits, and it's far from 'cool', however:

DBIx::Class, Moose, Catalyst, Template Toolkit - these are a joy to work with. People seem to be just ok that they have Rails, bitch about Active Record, and honestly, just don't seem to love their tools.

TAP-based testing is awesome sauce. Ruby gets this so wrong with all tools checking return values of scripts + the occasional hacked together jUnit outputter. Even the testing tools stolen from Ruby (like Test::BDD::Cucumber (which I may have written)) use TAP and Perl's testing tools all the way down.

Finally: there's CPAN. It Just Works. I started off a Perl dev, and use of any other language's package system has just made me sad face.

Here's another reason: If you are doing work you know you are likely to port to C at some point.

I don't follow?

(and I'm saying this as somebody who love's Perl - I'm not seeing the connection)

Being usually on the other side of the equation, I found that it's pretty hard for a developer to break into the Perl world. To give a personal example, of the languages that I did when I was doing the whole schooling thing (Perl, Java, VB6), I enjoyed coding in Perl the most. Dont' know what it was, it just "clicked". But because folks that were hiring had no interest in new grads at the time (post dot-com bubble), I had to settle for PHP shops since they were the only one hiring. Even nowadays with years of experience with development (sadly still with PHP mostly), applying to Perl jobs gets the "sorry not interested" reply.

Maybe I need to know Ruby or Python? :D

I'm interested. I love Perl, and would love to work for a company that requires me to program in Perl. Care to share which companies are these?

Thanks.

If you're in Los Angeles, check out http://perl.la/. I know my employer (oversee.net) is hiring, and I'm pretty sure many of the others on there are as well.

ZipRecruiter is also hiring perl programmers in Los Angeles (email in profile if anyone's interested).

If you want to work with Perl, http://jobs.perl.org/ is always a good place to look.

I know of ShutterStock (NYC) and Aruba Networks (Sunnyvale) (AirWave team only). AirWave was interesting, but I don't know what they're doing over there anymore since I left and there's been some management shakeups (some of which may have been positive). Shutterstock is where a former coworker went; he says it's snazzy and they just filed for IPO.

I also hear Blekko is all Perl (it's the dmoz directory-people making a search engine. it's got social-search-related features, too, or something like that.) Apparently they have some fancy sophisticated technology for their backend systems (store big bitfield indexes on SSDs with a disk-backed store for the rest, spread across dozens of nodes, etc.) But I don't know anyone actually working there.

If you have the initiative you can look up their job applications yourself :P

Best Practical in Somerville, MA is looking for perl hackers: http://bestpractical.com/about/jobs.html#hacker

(I've been using their perl/mason based ticketing system, RT, for 5 years)

DuckDuckGo is Perl.

http://duckduckhack.com

If you're in Europe, the following companies always seem to be growing their (already large) Perl teams:

http://www.net-a-porter.com/ http://www.lovefilm.com/ http://www.photobox.co.uk/ http://www.booking.com/

Send me a CV and I can make sure it gets to the right people.

http://jobs.cpanel.net (Houston).

Did you announce the jobs at http://jobs.perl.org? I tend to use that site primarily when looking for a job. It's the only one to maintain a high signal to noise ratio, posting there also shows that the company knows about the Perl community and probably accepts its values.

I also know of two places looking for Perl hackers (I'm sure there are more):

  http://www.grantstreet.com/
  http://www.rentrak.com/

The first one is full remote, and I hear they have awesome benefits packages. I had two co-workers go there. I'm not sure if they hire outside of the US though.

Guess it is because perl is mostly used by sysadmins, you know shell on steroids to do the job -> scripting. Other reason can be because perl is changing in details all the time, well mostly adding useful stuff. I remember, in one moment it didn't have switch statement, after one not so big update it had :-)