
Why You Can't Hire Great Perl Programmers - draegtun
http://www.modernperlbooks.com/mt/2011/01/why-you-cant-hire-great-perl-programmers.html
======
Deestan
An often overlooked option is to look for a great programmer who knows _any
other language_ well and is willing to learn your shop's pet language. Hire
him, provide some learning room, and he'll be up to Level Competent in no time
compared to the time you need to spend looking for "a great Volvo driver".

~~~
ig1
I've seen companies that have tried this and failed miserably. While
programming languages share a common basis there are significantly different
paradigms between say Ruby, C++ and Perl. While a good programmer could
probably pick up any of these languages it'll probably take them a few years
before their productivity is at the same level as someone of the same ability
who has experience in that language.

~~~
lukev
A few _years_? Strongly disagree. Months, tops.

It's key that you do have people who are already good with the language on the
team for them to learn from, but if that's in place, a genuinely good
developer is going to be able to pick up on the new paradigm pretty easily.

~~~
ig1
I'm not talking about learning the syntax of the language, but things like
design patterns, maintainability and readability. You need to read a lot of
code to understand what works well and doesn't and it's language specific.

Understanding the Ruby way of doing things is different from understanding
Ruby. Understanding when to use meta-templates in C++ is something you only
learn by reading a lot of templated code.

After a few months you'll probably have only worked on a single code base on a
tiny part of a project. You've no-way of understanding the ramifications of
your design decisions will have on the project in 2-3 years time. You need to
see multiple projects go from design stage to long term maintenance to
understand issues such as where bugs get introduced, how code decisions impact
maintainability, etc.

~~~
lukev
That's what I'm talking about, too. Design patterns aren't that hard.
Maintainability and readability are obvious, if you've got good examples to
follow.

Sure, it may take a couple years for a developer who's absolutely stuck in the
mud. But a good developer _already_ knows multiple languages, _already_ is
familiar with multiple paradigms, and is capable of meta-cognition to
recognize what the new patterns are, how they are useful, and apply them.

~~~
ig1
If you think maintainability is obvious I suspect we're talking about
different things when we're using that term.

------
efsavage
Perl is great for programming, it ranks high on creativity, expressiveness,
conciseness, and general language coolness.

Perl is horrible (relative to other choices) for development, it ranks low on
readability, refactorability, consistency, dependency evolution.

~~~
grammaton
Arguably Ruby and Python rank just as high, if not higher, on all of the first
line, and do so without Perl's cruft and bloat. There's more to a language
than just it's syntax, and even if Perl can have some pretty compact syntax -
and it certainly can - that doesn't make up for it's weaknesses in other
areas.

Namely, it's Object Oriented programming that is a bad joke, it's weak-ass
multithreading, the fact it's a walking memory leak, it's attempt to shoehorn
two completely different variable scoping paradigms into one language, it's
vast and bewildering array of special cases and exceptions to it's own
rules....I could go on and on.

Disclaimer: I have used a great deal of both Perl and Ruby.

~~~
kscaldef
Wait, are you saying that Ruby _doesn't_ have "weak-ass" multithreading,
horrible memory leaks, and screwed up variable scoping?

~~~
msbarnett
I'm curious as to what your issue with Ruby's variable scoping is? It seems
very straightforward and intuitive to me. Especially compared with Perl's mix
of dynamic and lexical scoping.

~~~
kscaldef

        irb(main):001:0> x = 0; xs = [1,2,3]; xs.each { |x| puts x }; puts x
        1
        2
        3
        3

~~~
msbarnett
Oh right, that bit of unpleasantness. Mercifully, that's been fixed since 1.9:

    
    
       ruby-1.9.2-p0 > x = 0; xs = [1,2,3]; xs.each { |x| puts x }; puts x
       1
       2
       3
       0
       => nil

------
Vivtek
There are Perl programmers who don't use CPAN? Why in God's name would they
fail to use CPAN? I worship at the _altar_ of CPAN; CPAN is my life and my
oxygen. CPAN is the reason I will stick with Perl until the stars go out and
the works of man crumble to dust - except for CPAN, for CPAN is eternal.

~~~
sethg
In my first job as a Real Programmer (rather than as a tech writer looking for
excuses to write code), one of my first tasks was adding features to a script
that read a particular kind of XML file. The parser, such as it was, was
entirely hand-rolled; if you changed an input file so that it had a space in
between tags instead of a newline, the whole thing would break. I wasted no
time rewriting it to use XML::Parser.

In my _second_ job as a Real Programmer, I had to add features to a script
that parsed scripts in the Informix Perform Screen language. Again, this was
hand-rolled. I wasted no time rewriting it to use Parse::RecDescent.

I think simply knowing where to look things up puts you in the top half of
professional programmers. Possibly the top quartile.

~~~
pavel_lishin
> I think simply knowing where to look things up puts you in the top half of
> professional programmers. Possibly the top quartile.

Having just re-read "A Deepness in the Sky", I really want to make a
programmer-at-arms reference.

------
lelele
> One of the persistent rationalizations for not creating new software in Perl
> is that it's difficult to find great Perl developers.

One of the persistent rationalizations of Perl mongers is that Perl still has
that much of an edge.

If it's difficult to find great Perl developers, that's because less great
developers flock to Perl (if at all, maybe current great Perl developers are
people who have learned Perl some time ago). It is that simple.

Perl in its days used to be a great language for those who looked for a
"creative" one to learn, and allowed to do things other languages didn't. PG
has said Perl was a language for hackers.

Nowadays, there are way more options if you are looking for a learning
experience, and I dare to say that many alternatives are way more rewarding
than learning Perl, and have a much better effort/learning ratio. In the same
time you are memorizing what value every standard function returns in what
context, you could be composing functions in Haskell or building massively
concurrent Erlang systems. Heck, even the humble Javascript allows you to
perform mind-bending dynamic feats. Other languages offer multiplatform
support (native, Java, .NET) which Perl lacks.

~~~
chromatic
_If it's difficult to find great Perl developers, that's because [fewer] great
developers flock to Perl._

I would like to see non-anecdotal evidence for this.

 _Heck, even the humble Javascript allows you to perform mind-bending dynamic
feats._

It's also borrowing features Perl has had for _years_. Hm.

 _Other languages offer multiplatform support (native, Java, .NET) which Perl
lacks._

That definition of "multiplatform" differs from mine. Perl 5 runs on more
platforms than the CLR and JVM do.

~~~
Dove
_Perl 5 runs on more platforms than the CLR and JVM do._

In theory. In practice, if it runs on one JVM, it runs on any JVM. No
questions asked.

Perl is full of, "Oops, that crashes on Windows" traps. If you know where they
all are, you can avoid them, but it's hard to be sure you've found the last
one. The fact that the camel book has a section with tips for porters is
telling.

There's a big difference between Java's robust guarantee of portability and
perl's "best effort" philosophy.

~~~
chromatic
_In theory._

I have Perl code from a decade ago that still runs on VMS. Can you show me
similar Java code?

 _The fact that the camel book has a section with tips for porters is
telling._

The Camel book is a decade out of date.

------
mmaunder
I first learned about serious Perl development working for eToys.com. The web
application scaled to a cluster of hundreds of machines and saw extremely high
traffic. We had a large team working on it without any problem. The European
warehouse management system was also written in Perl and was my baby.

After seeing what Perl can do in terms of development speed, maintainability
and speed of execution I've never looked back. I've worked on a ton of great
projects since then and today I run my own startup with a tiny team, a tiny
cluster and we serve over 600 application requests per second all from
modperl, nginx, apache and mysql.

I've seen languages come and go over the years and here's what I've thought:

Java: In the late 90's I wrote a few java apps thought it was a cool language.
But I didn't like that it was proprietary. I also had the opportunity to ask
Steve Balmer about the Visual J/Sun lawsuit while I was at Credit Suisse. The
whole thing just turned me off and I moved on. Thankfully I did, because today
it's still dog slow to develop and to execute and now it' belongs to Oracle.

PHP: Embedding your code in your HTML seemed like a bad idea and still does.

C: I've seriously considered switching to C for web apps over the years, but
the performance gains haven't justified the increased complexity and added
time to code or prototype.

Ruby: I first dabbled in Ruby in 2005 but realized it was Perl in the early
90's and that startups are risky enough. I still eye it keenly, but it just
can't touch ModPerl's performance and stability and more importantly, it's
availability of libraries. It will one day though and then I may just drop
everything and join the party.

Javascript on Node.js: This is the most exciting development and web languages
since Perl simply because you can write asynchronous apps (single thread that
handles 1000000's of clients concurrently) in a high level language. I'm
already using Node and am REALLY looking forward to more libraries being
available and to them being more stable. Things like db drivers, crypt libs,
date, html and text manipulation libs. Node is the way of the future.

~~~
ido

        Thankfully I did, because today it's still 
        dog slow to develop and to execute and 
        now it' belongs to Oracle.
    

Can you name a language beside assembly, c and (in some cases) c++ that
executes faster than java, in any significant way in anything but very
uncommon circumstances?

Nobody says you have to like java, but unsubstantiated anti-language
propaganda doesn't really add much to the conversation (as perl user you
should be the one to know ;)

~~~
grayrest
> Can you name a language beside assembly, c and (in some cases) c++ that
> executes faster than java, in any significant way in anything but very
> uncommon circumstances?

The VM is great, but the Java community's "best practices" are insanely
stupid. It doesn't really matter how fast your VM is when web requests are
going through a couple dozen filters or getting serialized/deserialized to
XML.

~~~
brown9-2
No one is forcing you to use other people's best practices, poor choices can
be made in any language.

~~~
grayrest
> No one is forcing you to use other people's best practices

This is only true if you only work on your own code or you call all the
technical shots.

Part of working with other people is coming into agreement on how things are
done. When you're working on someone else's code, you play by their rules.
Nobody forces you to do this, but if you don't you're generally not someone
most programmers would want to work with, professionally or privately.

This tends to occur on the job when you get something dumped on you with a
time constraint. Your options are to use other people's practices, argue that
yours are better (which usually requires a restructure and pushes back the
time constraint), or quit. Nobody forces you to go for the first option but
the second two are the more difficult paths.

~~~
brown9-2
But in this case of "on the job", isn't your real problem with the employer's
best practices and standards? Surely there are lots of people and teams out
there writing Java in ways that aren't insanely stupid.

Teams can use even the most pristine language and introduce a lot of dumb
ideas and practices into it. I think you're beating up on the language
unfairly.

~~~
grayrest
> Surely there are lots of people and teams out there writing Java in ways
> that aren't insanely stupid.

This is true. I know of a number in Java and a lot more in JVM languages. To
be clear, this isn't about my work since I rarely have to write Java and my
coworkers are smart so the code is relatively good.

> I think you're beating up on the language unfairly.

J2EE was a travesty. Java class hiearchies are ridiculous. The codification
and practice of design patterns is excessive. XML gets used all over the place
for all sorts of things. None are required for the language, but they're
encoded into the best practices of the community. The whole point of best
practices is to help people avoid dumb things, but somehow the Java community
got it wrong. I blame the consulting industry and the design goal of trying to
protect people from themselves.

If you love Java, are super productive in it, and your programs blow
everything else away, power to you. I know two guys who love Java and are
faster than I am at implementing an algorithm even with the LoC advantage I
get in my preferred languages. The language is what it is with advantages and
disadvantages. My inability to get over its flaws shouldn't hinder your joy of
programming.

------
strick
I'll give you one more reason: they decided to start coding in python and ruby
instead.

~~~
zoul
Oh please. It’s been shown over and over that modern Perl is a very pleasant
ecosystem to work in, can we spare such childish comments for other websites?

~~~
chawco
This may be true today, but there is a cadre of developers who will never find
out. Perl was our bread and butter 10 years ago, but we moved on when Python
and Ruby came to the forefront, and have never looked back. To get people
interested in it again Perl can't just be 'pleasant' -- it needs to be better
in the way Python and Ruby were better back then.

~~~
matt_p
it is better than they are now, let alone how they were back then :)

------
ZeroMinx
A few years ago I was interviewing people for a Perl programming position. The
general level was _shocking_. Asked to rate themselves, many would give
themselves a close to the top rating, where later it showed they had never
done OO, didn't know the basics of unit testing, etc etc. Sad state of affairs
indeed.

I really doubt this is unique for Perl though.

~~~
NickPollard
Object-Oriented isn't the only way to code. Never having done OO doesn't make
someone a bad programmer.

Unit-testing is a bit less forgiveable.

~~~
Raphael_Amiard
> Never having done OO doesn't make someone a bad programmer

Well given the current landscape of programming, yes, it does make them very
bad programmers. If you haven't explored the most common programming paradigm,
you're a bad programmer, or a 1st year student.

~~~
NickPollard
'Most common programming paradigm' it might be, but people's exposure to it
will vary by domain.

Would you say that someone who has been coding embedded systems for 30 years
in assembly and minimalist C is a bad programmer just because they've never
done OO? Despite the fact that for what they're doing it might be a bad
choice, and they've specialised into an area that is vastly different from
what you might expect as the norm?

~~~
msbarnett
> Would you say that someone who has been coding embedded systems for 30 years
> in assembly and minimalist C is a bad programmer just because they've never
> done OO?

If all that's been doing for 30 years, then probably, yeah. They might be good
at their _job_ , but an overall good programmer? Maybe they were great 30
years ago, but if they haven't raised their head to look around at the
evolution in the industry and kept up with newer trends and developments, the
level of skill atrophy would be quite large.

------
colinstrickland
I spent a year or so trying to help a company I was working with hire
experienced perl developers to work on existing code. Pretty much all of the
candidates were way below the standard required.

I came to the conclusion that this was probably a question of maturity. I
think experienced perl developers are now an enclave of older programmers
who've stuck with it and are now entrenched experts. They're all too
expensive.

There seems to be a generation gap, presumably where everyone ran off and
learnt ruby or python, as perl 5 was perceived to be stagnant, for whatever
reason.

I think what remained in the available salary bracket was either people who
weren't very good, or were too new for it to show either way. Anecdotal, of
course, but it reminded me of other job markets I've seen entering the first
phase of an eventually near terminal decline.

------
staunch
I just hired a great Perl programmer days ago. It took just a few days. I will
hire more soon. Compared wih hiring for a lot of other positions it was quite
easy.

I picked him out of 40 people. Most of them didn't really know Perl well, but
the code of the people that did stood out very clearly.

------
natch
Great, just what Perl needs: more FUD about Perl. /sarcasm

There are different measures of greatness. Using exclusively the most modern
Perl idioms is one measure. Another measure is getting shit done. Another is
writing code that can be read by the average Perl programmer.

IMHO the second two of those are way more important than the first one [edit:
note I did not claim that any of them are mutually exclusive]. The author of
the blog post is pushing a good agenda (promoting modern Perl) but doing so
with tactics that end up adding more harmful FUD to Perl's already shaky
reputation.

~~~
chromatic
_The author of the blog post is pushing a good agenda (promoting modern Perl)
but doing so with tactics that end up adding more harmful FUD to Perl's
already shaky reputation._

How so?

If Perl can't survive the honest admission that a lot of people writing Perl
aren't great programmers, that the design of the language encourages people to
be able to write baby Perl and still get their work done, and that the
existing core Perl community needs to find these people and encourage them to
improve their skills, then Perl doesn't deserve to survive.

------
tom_b
The statement that stands out most to me:

"the group of people with a little bit of knowledge (likely due to ad hoc
experimentation and intuition based on previous familiarity with another
programming language or Unix culture or just copy and paste osmosis from a
barely-working heap of sticks left by the previous maintainer) dwarfs that
smaller group of experienced programmers."

I think one of the reasons there are a bunch of people with just a "little bit
of knowledge" is that there are a bunch of gigs where that's enough. I also
think that its a tremendous mistake for people to take these types of jobs if
they have any personal ambitions to reach that "experienced programmer" level.
Unless your personal situation dictates that you have to.

But, the trick is that the ad-hoc experimentation and intuition is a necessary
first step to moving to the next level. I'm personally interested in figuring
out what you need to really grok in a particular programming paradigm/language
to be a really great hacker using that paradigm/language.

------
hippich
I like Perl. I am doing my own non-that-plain-stupid-website projects in Perl
(for plain websites i am using PHP+Drupal). But I have no projects-for-cash
involving Perl at all - looks like nobody is doing it today. And this means I
have no real-world experience too. That's bad.

But I still love this language and will continue do own stuff with it. =)

~~~
Jeema3000
This seems to be a common misconception, but it's still very much a part of
the corporate and business landscape. Do some keyword searches on a job search
engine - you'll see what I mean...

~~~
hippich
I started to earn bucks for living doing PHP development. In the beginning I
tried to work as perl dev, but quickly realized that wordpress and drupal for
freelance is much easier since there so much projects. And even with huge
competition with indian/pakistan $5/hr devs, I was able to keep my rate at
$50/hr..

Now corporate - probably, but I was doing freelancing work, not full time
employee. Nor I had any product to sell to corps (this is what I want to try
tho eventually).

------
drallison
You cannor hire great perl programmers for the same reason that you cannot
hire great programmers--they are a rare breed and an endangered species.
Skills with a particular programming language are not a primary differentiator
between programmers. A good perl programmer is likely to be (or make) a good
python programmer, C programmer, C++ programmer, LISP programmer, etc.

------
didip
Isn't this depend on the job description? There's no shortage of great perl
programmers doing devops related work.

That's the comfortable niche that they enjoy. Why would they want to lower
their salary bracket building web forms?

------
scotty79
This argument is invalid because it should hold also for PHP and there's no
shortage of awsome PHP programmers. There are additional causes why it's hard
to find great Perl programmers.

------
berntb
I liked the article.

But do mediocre Perl programmers _really_ not use Test::More? (-: Hell, even I
do! :-)

Testing has been central in Perl for most of a decade. I browsed "Intermediate
Perl" recently (I'm outsourced and will train a few newbies the coming weeks),
and already that beginners' book did a good overview of testing (mocking
objects, etc).

Let me note that the author isn't exaggerating when he claims "Modern Perl" is
really good. :-)

Edit: Grammar.

~~~
KevinMS
I've known a few good perl programmers, and a few ok ones, and I know for
certain that a lot of perl programmers came out of the dot-bomb days and back
then testing just wasn't part of the culture.

Not misunderstand me, writing tests for published modules was expected, but
with everything from scripting to websites unit testing wasn't that common at
all.

It wasn't a big problem either, because when the perl shop got serious, it
ramped up the QA, and even possibly had a less buggy product than today,
because QA can be brutal, and unit testing can be LAZY and misguided.

Testing fanboys flame me all you want, but I was there, this was common, we
walked to work both ways uphill, but built the foundations of the web you see
around you.

~~~
viraptor
QA is a not-automated repetitive (usually acceptance) testing. It doesn't have
much to do with unittests and they're definitely not interchangeable. If you
compare QA and unittesting... the argument is pretty much misguided.

Ideally, you should have both. And then some more automation. And quick
feedback from automated tests.

