I'd like to collect some opinions about the following things. I am
referring to some of the recent posts on linked-in, about recruitment
and the lack of "great programmers".
A bit of history in my (possible distorted) view:
When
OO appeared there were debates on the fact that has certain
disadvantages over procedural like speed and being more verbose (over
the advantages of allowing abstraction and allegedly being better for
organizing huge code).
Then, in Perl's world, there were voices
saying that one should not bother to learn OO perl because it is not a
real OO, it is more a set of cumbersome conventions than a proper OO
implementation.
Finally Moose appeared and practically defined a sub-language, a lot of "sugar" to overcome the base language OO limitations.
Now
everybody jumped happily in Moose's boat and no-one talks about
procedural Perl and, more important, they don't accept anymore
procedural at interviews.
Like OO Perl is more than just another way to structure Perl code.
I call "There Is More Than One Way To Do It" in my support. True, I read somewhere: "Because TIMTOWTDI, don't assume that you can do it any way you want" but I tend to disagree for most of the situations.
In
my opinion, the main purpose of any application is to meet the specs
and also to be done in the allocated time. If you think of the
application as a black box, and you managed to make it work as expected
and tested it thoroughly from any angle, I really don't understand why
would anyone would care *how* it is inside the black box. Is like, you
can hit a nail with a hammer or with a pair of pliers and to a certain
extent the outcome will be the same, depending of the wood's resistance.
Of
course, when it is about interacting in a team and if there is a
defined programming style, the applicant should converge to it, to
respect the house rules. Still, it doesn't mean that procedural Perl
should be a reason to reject a candidate at technical interview time.
It
seems that only few companies are still willing to allow time for
learning and they all ask for guys that can "hit the ground running"
(again, mind you, we talk about a style not about core programming
skills). But no one can know everything needed at the new job already.
If (s)he knows everything, there is a chance (s)he might be tempted to
look somewhere else for a challenge.
I think that's
why a lot of recruiters/companies complain about the fact there are not
many "great" programmers on the market. (BTW: Define "great". How? By
compiling a list of technical questions that all "great" programmers
should know? This might be a wrong approach. See http://it-quirks.blogspot.com/2012/10/modern-perl-recruitment-contd.html).
I
bet there are lots of good Perl programmers but they get rejected (and
possibly going to other languages) because they were considered as not
fitting the target company's programming style. The companies are
incredible picky these days about the style, and the middle layer
(agents) is escalating this much more by not knowing what's really
about.
And then the advertised job stays on the market
for 6 months or more and the agents and companies, at unison, lament
about the fact that "great" perl guys are a scarce resource. Maybe
giving a chance to any Perl programmer that can do the application no
matter the style, would be more beneficial for the company. Put in
balance the 6 month fishing for the "great" programmer versus few month a
"regular" guy can learn the new environment's specifics, style, etc.
Maybe it is time to admit that we're not so many out there, therefore you need to be more flexible. Otherwise, wait.
I'm
not trying to diminish the importance and role of OO Perl or Moose. I
would just love that the recruitment wouldn't be so exclusive about it
nowadays, because things can be still done very well and fast, the
procedural way. Besides I don't think that it'd take more than few weeks
for someone to adjust from procedural to OO style of the company. Not
to mention that OO design sometime is a separate job in many companies,
and in the end the programmer ends up writing code inside the same
class, not needing to know the big OO picture.
So, how hard you think it is for an "regular" perl programmer to switch from procedural programming to Moose?
I think that your history of Perl is somewhat inaccurate, particularly in its characterisation of "pre-Moose" object oriented programming in Perl.
ReplyDeleteFor projects of any reasonable size and complexity, the OO approach is going to be more flexible and maintainable than a procedural version. I don't think anyone who has done any serious software engineering in the last thirty years would disagree with that.
I know that "classic" Perl 5 OO can look a bit like it's been bolted on the side of an existing language. That's because it was bolted on the side of an existing language. But that doesn't mean that people avoided using it. Damian's "Object Oriented Perl" book shows just how powerful and flexible classic OO Perl can be. I've been using Perl for over fifteen years and in that time I've only used procedural code on a handful of tiny projects.
People used classic OO Perl not because it was easy to use - but because it was the right way to write large projects in Perl. That has been true for fifteen years.
Then Moose comes along. And suddenly OO in Perl gets far easier. That's why people switched to Moose in such large numbers, because it made their lives easier. I don't know many people who switched from non-OO Perl to Moose. But that's because I don't know many people who were using non-OO Perl before Moose arrived.
I assume that's also why people don't want to employ Perl programmers who don't have OO experience. As I said above, OO programming is usually the best approach to a large project and anyone who has learned to code in the last thirty years who doesn't use OO techniques as a matter of course is immediately suspect.
If you're a programmer and you don't know about OO programming then you should really spend time learning about it. CPAN is full of good examples of OO code that you can learn from.
It boils down to these two facts:
* OO programming is usually more flexible and easily maintainable than procedural code.
* OO programming in Moose is very much easier than classic Perl OO programming.