
Perl as a career option - lmedinas
http://www.linuxcareer.com/perl-as-a-career-option
======
avar
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 :)

~~~
collyw
>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
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".

------
oalders
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](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.

------
Moto7451
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.

------
krylon
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.

~~~
BugBrother
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...](http://search.cpan.org/~ether/Moose-2.1210/lib/Moose/Cookbook/Basics/Company_Subtypes.pod)

Quite OK for one of the scripting languages, imho.

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

~~~
krylon
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.)

~~~
simcop2387
You should also check out Moo[2] and Mouse[1]. They both try to be simpler
versions of Moose without the compile-time (and runtime) performance issues of
Moose. They do that by dropping some things like metaobject protocols and
other things that are great for introspection but may not be something you
really care too much about. They both try hard to keep syntactically the same
as Moose when possible so that you can most of the time use them all
interchangeably.

[1][http://search.cpan.org/~gfuji/Mouse-2.3.0/lib/Mouse.pm](http://search.cpan.org/~gfuji/Mouse-2.3.0/lib/Mouse.pm)
[2][http://search.cpan.org/~haarg/Moo-1.005000/lib/Moo.pm](http://search.cpan.org/~haarg/Moo-1.005000/lib/Moo.pm)

~~~
kbenson
Additionally, Moops[1] may be useful to get some extra sugar going. It's a
meta module that includes a few other modules to give you a sane (Moose/Moo)
object model, plus function and method signatures through Method::Signatures.

For example:

    
    
        use Moops;
    
        role NamedThing {
           has name => (is => "ro", isa => Str);
        }
    
        class Person with NamedThing;
    
        class Company with NamedThing;
    
        class Employee extends Person {
           has job_title => (is => "rwp", isa => Str);
           has employer  => (is => "rwp", isa => InstanceOf["Company"]);
    
           method change_job ( Object $employer, Str $title ) {
              $self->_set_job_title($title);
              $self->_set_employer($employer);
           }
    
           method promote ( Str $title ) {
              $self->_set_job_title($title);
           }
        }
    
    

[1] [https://metacpan.org/pod/Moops](https://metacpan.org/pod/Moops)

------
VLM
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.

~~~
collyw
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.

------
rz2k
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](https://news.ycombinator.com/item?id=7373038)

------
bsg75
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.

------
jaryd
For anyone interested, DuckDuckGo is hiring Perl engineers...
[https://duck.co/help/company/hiring](https://duck.co/help/company/hiring)

------
peatmoss
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.

------
bane
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).

~~~
spikyobjects
> 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.

~~~
bane
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.

~~~
wwweston
> 5 is a moving target, and the island of stability (Perl 6) seems to be just
> around the corner forever.

The idea of 6 as an island of stability and 5 as a moving target is exactly
backwards.

And Perl 5 has had fewer breaking changes than any of its popular scripting
siblings... Ruby (1.8 -> 1.9 anyone?), Python (oh, yes, let's talk about 2 vs
3, shall we?), or PHP (in which build flags introduce breaking changes, let
alone stuff that's come with some 5.x dot release).

> 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?

It doesn't matter what it'd cost at this point because there's no reason to do
it, nor is there any visible time on the horizon at which you'd need to do it.
Like the GP said, 5 is production, 6 is where people experiment with language
features, and 5 has shown that it has plenty of future through regular stable
releases and feature enhancements since 5.10 (released 7 years ago!).

> 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.

Every technical decision maker worried about the Perl 5->6 transition over the
last few years is someone who didn't actually do the kind of diligence a good
technical decision maker should do, and hopefully that's a one-off mistake
rather than indicative of the general quality of their judgment.

~~~
chromatic
_Every technical decision maker worried about the Perl 5- >6 transition over
the last few years is someone who didn't actually do the kind of diligence a
good technical decision maker should do._

That's unfair. The current motto of the p6 faithful has become "It's a sister
language not intended to replace Perl" over the years, but a lot of things
have changed over the years. If and when a usable p6 is released, who knows
what the motto will be then?

You brushed over the Python 2 to 3 migration, but at least that one had a
coherent strategy. It's not an easy strategy, but there's an end of support
date for Python 2. There's a widespread effort to port libraries and
frameworks and projects to Python 3.

That hasn't happened yet for Perl. It's not clear if that's ever going to
happen for Perl. No one is exactly sure how much of the CPAN p6 will support,
if any.

Will people start writing more new code in p6 instead of Perl? Will people
port code from one to the other? Will p6 be able to use existing libraries?
Will those libraries be usable in the same process?

When will p6 be stable? When will it have documentation? When will it have
support, from a community point of view or a vendor or bundling in a supported
distribution? When will it have tool support? What is its deprecation policy?
What is its support period? Who will use it? What will they use it for? How
much training do they need? How much do they charge? How easy is it to hire
them?

There are so many unknowns. It's unfair to sweep them under the rug and say
"Everyone should know that Perl is Perl and 6 is something else and the latter
doesn't matter."

~~~
wwweston
> If and when a usable p6 is released, who knows what the motto will be then?

I guess I don't see why that's an important question when:

\- there's no horizon on which a complete implementation (or stable target for
a spec/test suite, for that matter) is promising to arrive

\- 5.x has demonstrated it's a living/growing branch with as much a future as
any open source project

\- By comparison, for something like Python, the concrete reality of having a
plan for changing horses midstream seems to be more painful than just keeping
on with Perl 5

Or are those false assumptions?

I don't really expect everyone to keep up with everything about Perl. I'd
certainly had no idea 5.10 was even a glimmer in someone's eye for over a year
after it had come out because I was busy with front-end work and PHP projects.
And I'm responding partly because maybe I've missed something again and this
is a learning opportunity.

At the same time, when someone speaks up as the GP did and asserts that
technical decision makers have done their homework and picked things like
Python or Java by comparison to insulate themselves from the spectre of
version shifts and associated porting costs, I think they may have earned
themselves a challenge.

~~~
chromatic
_there 's no horizon on which a complete implementation (or stable target for
a spec/test suite, for that matter) is promising to arrive_

That _is_ the problem.

The future of Perl is very, very difficult to predict. 14 years ago, the next
major version was announced. It was explained and designed and promoted in
public by gathering the community's list of 361 technical flaws.

P6 is now older than Perl was when P6 was announced and no one can tell when
or if P6 will replace Perl. That includes developers as well as users and
technical decision makers. If you start a new project in Perl today, how long
will it be supported? Will you be able to hire or train enough developers?
Will you be able to retain them? Will P6 ever replace Perl?

Python has its difficulties with the gradual adoption of Python 3, but at
least there's a consistent and coherent story about community expectations.
Perl doesn't have that, and that, to me, as a technical decision maker, is a
huge risk.

------
eliben
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
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](https://news.ycombinator.com/item?id=8095574)

~~~
eli
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.

~~~
spikyobjects
As opposed to Perl, which was designed as a web framework language?

~~~
eli
Point taken, but Perl has a (very) long history of being the glue the holds
websites (and everything else) together. I think perl files in cgi-bin is the
first time I ever connected a database to a web page.

~~~
spikyobjects
COBOL has an even longer history processing business and financial data.
Perhaps COBOL is the secret sauce that hedge funds use for high frequency
trading?

