Perl as a career option
linuxcareer.com
linuxcareer.com
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 :)
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.
thanks, 'sgood. have an offer in Berlin, will be weighing it against a potential offer from London over the next few days. :)
Seven days after I sent them the passport scan I got an email explaining "While we impressed with your background and experience, we have concluded that other candidates' qualifications more closely match the requirements for this position.".
I guess my age wasn't a good fit.
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.
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.
My point was, to take a simple example, at places like Booking.com [new] people will typically find out about the used CPAN Date classes from the code or their table neighbour. Not by rolling their own or crawling all of the CPAN before finding DateTime.
But sure, the internal code will be a bigger issue.
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".
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.
Evaluating true and false, or just simple comparisons, can be a mystery. Heck, just figuring out what's going to be a syntax error or not depending on if a variable was declared, defined, interpolated. Or referencing a nested data structure when one of the elements doesn't exist. Even just general conventions and best practices fills its own O'Reilly book. We haven't even begun talking about regular expressions.... Then there's the autoloader, and constants, namespaces, scalar/list context, signal handling, ....
Part of the difficulty of Perl is that you can write code that works perfectly until the clearly-obvious hole you left is triggered and a fatal error occurs, and then you get to learn about the debugger. It takes years to use all the parts of Perl that have weird magic or complex, non-obvious functionality tied to them. Saying you could use it all without problems after only a few weeks is really misleading.
The fact that there is a "strict" mode at all speaks to how difficult it can be to get the language right.
But, evaluating true and false in expressions is tricky in a lot of languages now. PHP is notorious for it. That's why you shouldn't mix data types. Regular expressions are no longer the sole domain of the Perl hacker, they're a regular staple of JavaScript and PHP and the commandline and other utilities.
Look, here's the thing: the response to avar has pretty much been, "you guys are doing it wrong", which is a seriously uncool armchair quarterback thing to say to someone else, especially someone that's a part of something as big as booking.com. If in fact their hiring process was as unutterably broken as you seem to believe it is, wouldn't you've expected their business to collapse in a pile of inscrutable bugs by now?
I'll readily agree that there's a vast difference between a coder in any particular language, and an expert in that language. That's why the experts get to define the language conventions used by a business, and the coders get to follow them. That's why there's testing and debugging and staging.
I try to assume least level of incompetence in other people on HN. Maybe instead of declaring things about their code base that you have no actual knowledge of ("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."), you could instead ask, "How do you guys handle training the guys that aren't very familiar with Perl quirks like int@_ vs $#_?"
And i'm not assuming any level of anything. If you learned spanish in Spain, you can't just go to Mexico or Venezuela or Argentina and pick up the local dialects, because there's different grammar and vocabulary and pronunciation you won't know until you run into it. Trying to write a paper in those countries after only using their dialect for a few weeks will land you with mistakes. I don't think this is a controversial thing to say. (And this is assuming you're picking up a very similar language; trying to go from Spanish to Portuguese would be nearly impossible in just a few weeks)
>>which is a seriously uncool armchair quarterback thing to say
Imho, you read too much into the discussion. Everyone knows that Booking.com must be doing a lot of things right for their particular problem set and situation. It is a high profile place that attract good talent. (I am hardly alone in assuming they aren't too stupid to listen to Ovid et al.) Their situation is unusual and the resulting specific differences in methods will be questioned, because of their high profile.
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.
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.
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.
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 { [] },
);[1]http://search.cpan.org/~gfuji/Mouse-2.3.0/lib/Mouse.pm [2]http://search.cpan.org/~haarg/Moo-1.005000/lib/Moo.pm
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);
}
}
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.
"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.
Perl is still a viable language, and a lot of the choice comes down to taste.
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).
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.
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.
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.
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."
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.
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.
Iirc, he has trolled in Perl discussions before.
For a multi-million dollar development with more than 6 developers, code is the least of your worries.
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.