Perl as a career option

http://www.linuxcareer.com/perl-as-a-career-option

by lmedinas • 12 years ago

72 50 12 years ago

peatmoss• 12 years ago

An article about Perl invoking Slashdot discussion certainly feels anachronistic. I quit Perl relatively soon after Python's debut, though I still miss the feel of the whole Free/Open Source software movement during the Age of Perl. No doubt Perl and CPAN helped build the house we now live in.

Moto7451• 12 years ago

I went from working at Silverlight shop to a Perl shop two and a half years ago. The experience has been great. The article hits the nail on the head in terms of pros and cons.

The learning curve going from C# to Perl wasn't that bad. Both are expressive and share a number of idioms. Moose is easily one of the best parts of the toolkit and the one thing I miss most when doing Objective C and C# projects.

bsg75• 12 years ago

Coming from shops that were all about Java, Rails, and C# (but using Python myself), I was surprised at how much new (performant) Perl my current company generates. This is probably part of the reason for my new found love of Awk.

Perl is still a viable language, and a lot of the choice comes down to taste.

oalders• 12 years ago

There is mention at the very bottom of this article that a great way to improve your Perl skills is to participate in the Google Summer of Code (GSoC) or the Outreach Program for Women (OPfW). I've been involved in the selection process of both of these programs for The Perl Foundation this year and in the past. This year The Perl Foundation is participating in both programs.

I spend a lot of my open source time working on Perl and specifically https://metacpan.org We have both a GSoC and an OPfW participant currently working with us. They're learning a lot and contributing a lot of really great work back to the project.

If you do want to get involved in something like this, my advice would be to get to know the project you want to be involved with well before the deadline. Reach out to one of the project leaders. Find out how you can get involved. Start contributing patches as soon as you can. When the time for applications comes, ask for feedback on your proposal _before_ you submit it. Writing a strong proposal is a skill in its own right and something that will benefit you in your later professional life as well.

Conversely, if you lead an open source project, don't wait until the call for submissions to start trying to recruit students. Get the word out early so that you can better judge who would be a good applicant.

Having this kind of experience under your belt can help a lot when considering Perl (or other languages) as a career option. I'm happily coding Perl full time, but even if that's not the path you eventually take, it's still a great tool to have access to.

krylon2• 12 years ago

Back during my training, I used to do practically all of my coding in Perl. I loved it. Then I stumbled upon Python and Ruby, and I did not look back for a long time. When I did, I realized how much I disliked Perl's type system (or lack thereof). I sort of drifted around for a while between Python, Ruby, and Lua (although I do not really like Lua as a stand-alone scripting language, it totally rocks as an embedded scripting/extension language).

About 15 months ago, I started working as a sysadmin at a smallish (~100 people) engineering company, and I re-discovered Perl. I am not sure I would like to implement any largish piece of software in Perl, but as a scripting language for system administration, it still rules. Especially on Windows, which still feels like a downright hostile environment for programming.

BugBrother5• 12 years ago

I don't really get what is different with Perl and the other scripting languages for types, but check Moose.

E.g. http://search.cpan.org/~ether/Moose-2.1210/lib/Moose/Cookboo...

Quite OK for one of the scripting languages, imho.

  has 'employees' => (
      is      => 'rw',
      isa     => 'ArrayRef[Employee]'
      default => sub { [] },
   );

krylon2• 12 years ago

Yeah, learning Moose has been on my todo-list for a while now. Back when I still used Perl almost exclusively, I hardly did any object-oriented programming in it, and when I did, it felt awkward. Moose looks like a game changer, both for OOP in Perl and for typing. Right now, I have a lot on my plate, but once my schedule clears up a little, I will look into it. Thanks for the hint! (For sysadmin-scripting, non-OOP Perl is entirely sufficient, though.)

jaryd• 12 years ago

For anyone interested, DuckDuckGo is hiring Perl engineers... https://duck.co/help/company/hiring

eliben2• 12 years ago

Perl is on the sure way to become the COBOL of the scripting world. I'm saying this as one who invested years into learning and applying Perl everywhere I could. But seriously, it's a done deal now. Move on.

Yes, there are still companies with large Perl code-bases. Large Perl code-bases need a lot of maintenance (sigh). So Perl programmers will be in some demand for a few years at the least. Hence the analogy to COBOL.

lazyloop• 12 years ago

When was the last time a COBOL project has generated as much buzz as Perl's Mojolicious has just yesterday? https://news.ycombinator.com/item?id=8095574

eli2• 12 years ago

That's a little unfair. COBOL just isn't well suited to problems solved by a new web framework. Batch processing of financial data is important, but it ain't likely to generate buzz.

walshemj• 12 years ago

Wouldn't COBOL be classic scripting - one funny thing at BT we had a lifer COBOL guy (20 years plus on mainframes) join our perl team - he found the transition hard "where are the Divisions" was one quote from him

spikyobjects4• 12 years ago

Maybe you just weren't a good enough programmer for Perl?

eliben2• 12 years ago

That's entirely possible. Perl's trajectory in the past 7-8 years is, after all, consistent with all the stars staying and all the bad programmers leaving.

avar3• 12 years ago

I think it's a bit odd thinking of programming languages as a career option. I work at what's one of the biggest if not the biggest single employer of Perl programmers (Booking.com), and we don't specifically hire people with prior Perl experience. We hire people with relevant programming experience and bring them up to speed on Perl.

Anecdotally we've hired people who've had years of Perl experience who haven't done all that well, and people who've had no prior Perl experience who've just picked it up on the job and been very productive contributors within days or weeks.

The unstated assumption with articles like these is that you'd be losing out if you don't get experience with the "winning" platform, but in my opinion a much better way to become a good programmer is to get experience with a wide selection of toolsets and programming languages. Even if none of those toolsets are widely used commercially.

Having said that if you're interested in Perl as a career choice we're always hiring :)

fennecfoxen2• 12 years ago

You're "always hiring", but your interviews are remarkably short on actually writing any code and if someone asks too much about your approach to maintaining software quality (in light of your cowboy-coder reputation) you'll question whether they're "pragmatic" enough to work there and lose interest. Which I guess was probably things working out for the best, but Amsterdam was a fun city. Perhaps I'll find another employer there someday. Looking at London and Berlin in the meantime. :P

avar3• 12 years ago

I quizzed my interviewers for about an hour on how Booking did things and why when I had my interview, and I still got hired. Besides, like everyone if we don't hire someone we don't tell them why due to liability reasons.

So if you had an interview and got rejected maybe it was for some completely different reason, I've certainly never heard about someone getting rejected because they asked too many questions.

You might get rejected because you don't seem like a good fit though. I commented on this a bit more specifically in a Reddit discussion a while ago: http://www.reddit.com/r/perl/comments/1mkdl4/what_exactly_is...

Anyway, it's unclear from your post whether you tried and failed at an interview with Booking, or whether you used to work there. If it's the former I'd be happy to help you with another try.

Like any employer we'd rather not hire one right person than hire ten people we shouldn't have hired, so statistically we reject some candidates that would have been good fits.

BugBrother5• 12 years ago

Booking.com is a big place where newbies will be sitting with lots of experienced people they can ask and discuss with over lunch/coffee.

I doubt that smaller places will see so fast ramp up that they don't bother to hire people that know the language environment. The language in itself is quite irrelevant, but building a taste and learning the standard libs (here -- CPAN) takes time. That goes for every environment.

Edit: It would be interesting to hear the experience on this at other big shops? Maybe material for an academic article, someone?

Edit 2: I might add -- the differences between the scripting languages seems a bit overblown in the article. The languages (Perl, Ruby et al) aren't that different. Here I argued about the environment and standard libraries, which takes many, many hours for at least Python and Perl. And for taste -- to not have anonymous functions in Python needs changes in how you code. And so on.

avar3• 12 years ago

Almost all the libraries you deal with are in-house. Which is part of what I'm pointing out, most of getting up to speed in any company is learning about their domain-specific codebase, not the language they happen to be using.

You're certainly at an advantage if you know some of those things already, that goes without saying. I'm just pointing out that many people seem to overestimate the impact of the programming language on the overall stack. Knowing DB workflows, distributed programming etc. is much more important than knowing language trivia which you can mostly trivially look up.

collyw2• 12 years ago

I think it's a bit odd thinking of programming languages as a career option. Look at 99% of the jobs ads out there and they are looking for specific languages.

saidajigumi• 12 years ago

Agreed, but reading between the lines of these ads, there's a world of difference between an ad which is "we're looking for a great developer who will use <language X> to do [...]" and "we're looking for a <language X> Developer".

In my experience, the latter presentation tends to actively drive away the best candidates, and communicates a lack of understanding of the job to be done. This is not an absolute; sometimes you really do need a specific skillset. For example, one great company I worked at almost universally hired solid developers regardless of particular checkbox skills. We knew that the good ones would come up to speed, and we'd often benefit greatly from cross-pollination from differing backgrounds. However, there were definite instances where we needed a true specialist, e.g. in a specific, deep platform UI framework. Then we sought and found solid developers who were also top of their game in the needed skills.

In the latter ad copy above, a "<language X> Developer" often has the connotation not of a targeted specialist hire, e.g. "expert in <language X>". Instead it comes across as lazy recruiting: "warm body who checks off this box".

cyorir• 12 years ago

I completely agree with this. In some cases focusing on a single language or set of languages can be a good idea - especially when it is a language in high demand and it means you know the ins and outs of a lot of different frameworks a la javascript. However, there is no downside to studying a lot of different languages because it gives you general experiences that you can apply to other languages, it helps you pick up new languages and toolsets, etc. The most basic example is that a programmer who only works with imperative languages should dabble in at least one functional language, because that can change the way you view algorithms, data structures, and overall program layout.

peterwwillis3• 12 years ago

It seems to me that doing something as a career, you're expected to be really good at it. There's no way anyone can just pick up Perl and write good Perl code without a dozen best practice errors. Hiring someone who doesn't know Perl very well basically guarantees a high rate of bugs in your codebase.

thaumaturgy2• 12 years ago

Most of the traits that make good Perl code are the same traits that make good anything code: concise but readable, sensible naming conventions, useful comments, sensible logical structure that's not too complicated.

There are certainly a lot of things about Perl that are unique, but some time with the camel book and a few weeks of practice should sort that out for anybody with several years of production experience in another language.

VLM• 12 years ago

Two common Perl problems:

People think Perl 6 is merely an incremental change of Perl 5

People thing pre-MOOSE pre-ModernPerl is the same as post MOOSE post ModernPerl because they're both Perl 5.

One problem with the article is thinking "a" language is your career. That's just weird.

collyw2• 12 years ago

I have been thinking about looking for a new job. I seem to be fairly well paid here as far Spain goes, so I was looking at the corporate option as they are the only ones that seem to pay more. Its all .Net or Java. And they ask for in the job ads. I agree there is a fault in turning down an experienced developer because he (or she) hasn't got experience with a specific language. But that doesn’t mean it doesn’t happen. All the time.

bane2• 12 years ago

Perl is an awesome tool to have under any developer's belt. It's likely that somewhere during the course of your development you'll need to hack together some one-off script to do something and Perl is likely the best tool for the job and will probably already be on your system. It's worth it to learn it for no other reason than it's probably the most productive tool for this kind of use-case available. It'll also give you some ideas for your main development languages in how things can work, and the "perl way" of doing things will bleed into that. You'll start to look at some of the overly complex line consuming ways of doing things like "reading in a text file to a string" as moronic and will start to write abstraction libraries to "fix" your other languages.

I know this is a limited view of Perl (and I'm a huge fan of Perl and using it in various key places has helped provide for a not-insignificant percent of my lifetime career earnings). But Perl 6 has effectively killed Perl.

It's a case of announcing too early and getting the entire community to back off from investment of resources into new Perl code when Perl 6 feels like it's been just around the corner for years.

Regardless of how you think of Perl 6 (an incremental upgrade or a major overhaul) the effect has been the same in almost every Perl shop I'm aware of. People backed off of new Perl 5 work, expecting it to stagnate (it didn't, but perceptions are hard to overcome) and waited and waited and waited for the version # in their perl -v to increment to 6.

Since they were going to switch to new code anyway, why not try out the half-dozen other languages that have soared in popularity since? And now you end up with the situation we have now.

Perl 6 also provided a long standing competition target for other languages to hit. It allowed other languages to figure out what Perl 6 was and wasn't going to bring to the table and hit the kinds of things that people really needed.

My ultimate opinion on 6 is that it's a huge effort/a major rewrite, for some rather incremental changes, without addressing long standing issues with Perl for large-scale development work. There's some really cool stuff in Perl 6, built in grammars are potentially amazing, but I'm not sure a 14 year wait (and counting) was worth it (and yes, I'm aware there are some implementations available, but until perl6 is a default command from the cli in any major *nix distro it doesn't matter).

spikyobjects4• 12 years ago

But Perl 6 has effectively killed Perl.

Oh fuck off, no one has been confused/concerned about the 5 vs 6 version numbering thing for at least 10 years. 5 is production, 6 is where the crazy geniuses experiment with language features, everyone knows that they're two separate things. Since 5.10 we've had major (sub)versions of 5 every year, consistently. And the better ideas from p6 creep their way back into p5 in the way of modules or features in new versions, so it's hardly for naught. The only real mistake was calling it "6" instead of "Dr. Wall and Conway's chimera language of onion and camel goodness" or something.

bane2• 12 years ago

So let's say I decide to put 30 developers and QA guys into writing Perl 5 code for the next year. That's an investment on the order of $6-8 million dollars.

Why should I choose to do that? 5 is a moving target, and the island of stability (Perl 6) seems to be just around the corner forever. Except 6 will be an early, unoptimized version of whatever it will eventually become so I won't want to use it till it's well tested in real environments. Okay so I wait another year after 6 comes out, now I have even more legacy code to deal with.

So what are the metrics to port Perl 5 to 6? I have no idea, nobody really does. What does it cost to move 2 million lines of Perl 5 to Perl 6? The syntax is just different enough that I'll have to add another $1-2 million dollars or so into the long-term budget to port my Perl 5 code to Perl 6. I'm aware there are some conversion utilities, but now I have to QA all of the converted code and check for regressions and then fix them when they show up.

Sure I can just write for 5.xx and just stay there forever, but what if 6 does generally come out? Will the development community just shift over to 6 and now I don't get feature improvements and bug fixes? What's the long-term support case look like? I can't exactly contract the "Perl Company" to ensure I have long-term Perl 5 support for the next 5-10 years. So I'm just guessing and praying that what I'm building will have long-term support.

Or I can just tell my team to build in Python or Java or something else, not worry about all this and save $1-2 million in eventual porting and long-term maintenance costs.

There's actual business reasons for this. Every technical decision maker ruminating on Perl has gone through this, and they've decided to not go with Perl for these kinds of reasons. Which is why there are so few jobs requiring Perl, and why nobody bothers to learn it anymore.

Now, you may be swimming in hundreds of millions of dollars of personal wealth and can afford to make the decision to go with Perl, and that's cool. But unless you're willing to offset instability in the platform with personal investments in thousands of companies and development efforts, you can swear at me all you want, it won't change anything until Perl is again a stable platform and is solving people's problems.

To put the woes of Perl 6 in even more perspective. It's taken so long for Perl 6 to happen that Go, a language that didn't even exist when Perl 6 was announced, had a team formed, was announced, was developed with full-tooling and a robust standard library, went through betas, and is now in production use inside of hundreds of companies in less than half the time than it's taken for Perl 6 to get into some kind of alpha stage from announcement.

rz2k• 12 years ago

The idea that there is some under-appreciated, reliable technology that's already solved a lot of problems people are trying to address today is compelling to me. In fact, I've learned that I almost need to actively ignore short pieces of advocacy in order to keep them in perspective.

"Modern Perl" is an improvement on the coding styles that earned statements like "write once, read never". However, I think it is relevant to read "The Mid-Career of the Perl Programmer"[1] written by chromatic, who wrote the book on Modern Perl.

Realistically, the audience for this article will probably be people who are starting out with programming in addition to their primary job skills. Someone else further along probably isn't likely to choose one programming language for a career specialty.

While you can use Perl for automation, scripting, and data analysis as easily as you could in the past, there are additional tools available now. I feel that choosing Python, R, or Julia, depending on the task, maybe even VB.net is going to get people up and running faster, and also end up being a better starting point for doing more later if people get inspired.

[1] https://news.ycombinator.com/item?id=7373038

Perl as a career option

Related Stories