Monday, 15 October 2012

Modern Perl and the lack of "great" programmers

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

1 comment:

  1. I think that your history of Perl is somewhat inaccurate, particularly in its characterisation of "pre-Moose" object oriented programming in Perl.

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