← Интервью /

Interview with Curtis "Ovid" Poe (September 2014)

How and when did you learn to program?

I first learned to program back in 1982, when a geometry teacher let me play with the computers in the lab, even though they were for older students. I taught myself BASIC and by 1984, I had written a relatively full-featured (for the time) graphics editor for the TRS-80, but the graphics were so low-res that any image took several screens (and files) to build and you could dump them out to dot matrix printers. Students in the computer lab lost a lot of time playing with it. A couple of years later, I was writing a text adventure (for fun, I still didn't have a programming job) and I remember that my test sentence took eight seconds to parse in BASIC. That sentence was "hit the skeleton with the sword, take his ring and then walk north and touch the alter." I taught myself assembler to speed that up and later learned C. Sadly, because I lived in a small town and had no degree, I stopped programming entirely by 1988 and only programmed sporadically until 1998, when I got my first real programming job. I've been doing it full time ever since.

What editor do you use?

I use vim, but it's due to muscle memory, not because I have any particular feeling that vim is necessarily better or worse than other editors. I was forced to learn to use vim at my first Perl job in 2000. I hated the damned thing and kept working through the tutorial. Today, I have a heavily customized vim setup which is fantastic, but makes it very hard to pair program because I can navigate a code base so fast in vim that other developers can't follow what I'm doing. Or I change a line of code and suddenly, tests are running in the console and I've never left vim. Or I hit <leader>rb and suddenly my entire project is being rebuilt. Or I select a range of lines and bam, extract method! I'm fast at refactoring and cleaning up code, but it's mainly because of all of the tools I have built into vim.

Curiously, the fact that my vim setup is so powerful might be a drawback in the "text editor versus IDE" debate. I don't consider myself particularly talented in vim, but nonetheless it's sometimes painful to watch other developers use the editor. In my years of experience, I've found that most developers never learn to use their editor properly. Thus, a standard, generic IDE means that while there may be some bloat (I'm looking at you, Eclipse) and lots of features that are never used, developers can easily share tips and tricks by simply pointing out shortcuts or menu commands. My environment is heavily setup for how I program and it would be hard to share or explain. It optimizes me, but it doesn't optimize the masses. I suspect an IDE could be better for that. I actually tried to make a pared-down version of my vim setup because other devs kept asking for it, but it was a mess.

When and how have you been introduced to Perl?

In 1999, I was working as a COBOL programmer for an insurance company and befriended one of the Unix admins. He kept telling me to check out this thing called Perl. I was trying to fix a problem with a COBOL program that was converting a CSV file from an NT system to the fixed-width format that COBOL prefers. COBOL has many weaknesses and working with text is one of them. The code was 150 lines long, but that's because the author didn't understand how the COBOL's unstring function worked. I got it down to 80 lines of COBOL. Out of curiosity, I tried it in Perl and got it down to 10 lines of clean code, and that included error checking. When that Unix admin left to start his own company, I happily jumped ship from COBOL to Perl.

Ironically, many Perl devs write Perl like C, but I started writing it like COBOL (that's too long of a story to explain). It was the Perl community which happily embraced me and taught me how to really program. I'm very grateful for that.

What are other programming languages you enjoy working with?

My favorite would be Javascript. Writing things like my 3-D rotating star map brings me silly amounts of pleasure in areas that Perl just isn't well-suited for. I've also had fun writing Python and Ruby, but sadly, I've had Perl on my CV for so long that companies willing to offer me contracts in other languages simply won't pay as much as I can earn with Perl.

What do you think is the strongest Perl advantage?

Perl's strongest advantage is the community, hands down. I've watched other language communities struggle with issues that the Perl community dealt with a long time ago. It's a bit older than other communities and I feel there's more of a sense of maturity in the community than I find in other languages.

Other than that, I would say the Unicode support is phenomenal and while the CPAN does have a lot of cruft, once you know your way around it, there are many excellent modules out there that turn hard programming problems into trivial ones.

What do you think is the most important feature of the languages of the future?

Concurrency. We're not really facing it yet, but Moore's law is coming to an end in a decade or less. If we want faster systems, a robust concurrency system is imperative. Forking is often too expensive for many smaller programs and threads are a nightmare (how many experienced developers can tell you the four conditions necessary for threaded code to lock?). I recall Jonathan Worthington describing threads as the assembly language of parallel programming and as a former assembler programmer, I have to agree. All it takes is one tiny, tiny overlooked bug and you have a nightmare of a hard-to-reproduce problem on your hands. There's a huge amount of work being done in better concurrency models and we're going to need them in the future. If chips can't get faster, we have to take advantage of concurrency if we want to see those performance increases.

(Though there's a small part of me which feels that CPUs will become so cheap and widespread that many devs will still have plenty of work just cranking out standard code to get stuff done, no concurrency required)

How did you like the experience writing Beginning Perl? What was your biggest motivation?

When Wiley first contacted me about writing the book, I was going to turn it down. My wife, Leïla, had just given birth, we had just moved to Amsterdam, and life was chaotic. However, Leïla was insistent that I write it, telling me that she'd take care of our daughter. It was hell for both of us. I spent eight months writing what I think may be the largest Perl book written by a single author. My technical editor, chromatic, did a heroic job catching all sorts of issues in the work, but sadly, typos crept in. I'm still happy with the book and the reviews have been fantastic, but I wish I had more time to fix the typos.

Here's a little inside story that I don't think I've shared before. On one of my early drafts, I made a joke about terrorism (in a programming book!) and my editor asked if I thought it was appropriate given today's political climate. I simply replied "yes." Generally speaking, I defer to the editor's judgement, but in this case, I put my foot down. Shortly thereafter he was assigned to work on another book and while I was told that it was merely an internal reorganization, I always wondered if he was so offended by my sense of humor that he didn't want to work with me. That leads me into giving a shout out to Mary James, Maureen Spears, and San Dee, three incredibly awesome people at Wiley who worked with me on the book. If it weren't for them, I doubt what little was left of my sanity would have remained intact. I can't speak for other's experience, but given mine, I'd happily work with Wiley again.

Are Perl books still popular if judging from the purchased amounts?

That depends on how you define "popular." I'm happy with the sales of mine and given what I know, my book is doing better than some others, but that being said, there does appear to be a decline in the Perl book market in general. Because I do a lot of freelance consulting and training through http://www.allaroundtheworld.fr/, I see that Perl is still a popular language and new projects and companies are springing up and using it all the time, but there's been a public perception that Perl isn't as strong as it was. I think that's hurting the book market.

What was the reason to write yet another testing module for Perl? How is it different from others?

I've written many of them, but I'm guessing that you're referring to Test::Class::Moose. I originally wrote it to be an xUnit replacement for Adrian Howard's venerable Test::Class module. Unfortunately, the latter is showing its age, while Test::Class::Moose is designed to be a modern xUnit framework. What surprised me is that more and more companies are starting to adopt it because it's so powerful. Once you get used to it, it's easy to use, but it's truly an "enterprise ready" test framework.

Out of the box it gives you faster test execution, easy-to-use parallel testing (including being very easy to write parallel schedules for), reporting, slicing-and-dicing of test suites (only run tests that are relevant to what you're working on), tools for migrating from Test::Class, running tests in different contexts (thanks Dave Rolsky!), and complete Moose integration for powerful OO testing capabilities. I still remember demonstrating it for a company in the US and they immediately agreed to adopt it when they saw they could trivially run subsets of tests based on differing customer requirements.

That being said, I've toyed with the idea of writing Testament. This would be a successor to TCM which would solve two of the biggest problems: it would stop people from thinking that it was only useful for Moose-based code, and it would allow the company to choose what testing modules they wanted to bundle, rather than simply accepting Test::Most as the default.

Why do you think people should have experience living and working in different countries? What are the benefits of being an expat?

It's easier to hate someone you don't know. I currently live in France and I must say that most of the stereotypes of the French are dead wrong. They're not arrogant. They're not lazy. They're not dirty. They're a warm, rich people with a fantastic culture and a deep appreciation of great food and wine (and, well, bureaucracy). In fact, I've lived in five countries and every one is different from what outsiders think. The main thing you learn, if you get to know the locals, is that people are, well, people. We're not "Americans", "French", "Japanese", "Iraqis", or anything like that. We're people. When you've lived in as many countries as I have, you learn that most people are inherently good and it's the unfortunate tendency of the news to report on the bad stuff that really warps people's perceptions.

Being an expat is one of the most rewarding things any person can experience, particularly if you find yourself long term in a country whose common language is different from your own. Even though we're all fundamentally the same, the way it's expressed is different from culture to culture and when you experience that first-hand, you can have a beautiful understanding of why people are the way they are. I wholeheartedly recommend it.

Among many things you're doing the recruiting job in a special way. Can you tell us how is your way of doing it differs from the common one?

There is a very low barrier to entry for recruiters. All you need to do is say "I'm a recruiter" and bam!, you're a recruiter. This pushes quality down and prices down. Companies tend to spend very little on recruiters and then complain bitterly when they get what they pay for. Recruiters, in turn, often just scan for keywords, have no understanding of the position they're recruiting for, and then push the CVs to the companies. Wash, rinse, repeat.

We don't like to do that and we've turned down recruiting contracts asking for us to just throw CVs at them. We like to work with companies who want a recruiter to send them quality candidates, particularly for hard-to-fill positions, and are willing to let us do the job right. That entails understanding the hard skills the company needs (the measurable technical skills), but also the soft skills (work with deadlines, convince colleagues, handle rapidly changing requirements, and so on) necessary to fill a role properly. We actually interview the company to start this process.

When we're ready, we start interviewing candidates. We first filter CVs. If they get past that, we generally administer a technical test — the vast majority of candidates wash out at this point — and then we assess their soft skills using what is called a "structured interview". Unfortunately, they're not well known to hiring companies, but unlike your typical interview (which isn't much better than random chance in assessing good candidates), structured interviews are excellent predictors of whether or not a candidate will be successful in a given role. They take more time to learn, to conduct, and to assess, but it means that when we hand a candidate to a company, their final interview can be little more than "would I want to hang out at a pub with this person?" and there's much less risk.

I might add that this works well with our specialty in international recruiting. If your company is in a small town, such as Parthenay in France, you might find it very hard to attract French workers to it. In fact, even though France is part of the EU, EU citizens moving to France typically want to move to cities such as Paris, Bordeaux, or Nice. Who wants to move to the middle of nowhere? Well, a company in Parthenay whose willing to open themselves up to the global labor market is now flooded with candidates who would be delighted to live in France, even if it's a small town. That's where we come in: we tell the company how immigration works, how they can sponsor employees, how the European Blue Card works, how relocation is handled, and we handle the recruiting process to ensure that candidates moving to France are already prepared to be integrated, plus are excellent choices for the company to hire. It's a huge amount of work, but I love being an expat and it makes me very happy to see others realizing their dreams of living abroad.

What are you thoughts on Perl's future?

Perl is still doing better than many people think. It was incredibly popular in a space that was ripe for competition, and now that competition has arrived, its market share has declined. Unfortunately, many people who don't understand economics have misunderstood. When there's a low barrier to entry in a hot field, competitors will arise. This means, the leaders often have a reduced market share, but those who don't understand economics see the leaders as failing, rather than competing.

Currently Perl is still one of the fastest dynamic languages, has magnificent Unicode support, and a thriving community. Part of what's hurting has historically been two things: lack of method/sub signature and lack of a decent core OO system. With Perl 5.20's new signatures, we now have fantastic signatures. And Ricardo Signes has said that if he gets a decent MOP (metaobject protocol), he'll put it in core. With that, two of Perl's biggest limitations will be gone and our OO system won't be on par with other dynamic languages: it will leap-frog them entirely. At that point, I feel some of the biggest technical issues will be behind us, though marketing is still something the Perl community hasn't done well.

That being said, our marketing push over the last few years has seemed to revive the morale of many in the community. Now is the time to push it beyond the community.

Should we encourage young people to learn Perl right now?

We should teach them to program. While I'd be happy to see more young people learning Perl, in reality, once you're a competent programmer, you should be able to pick up most languages. Don't tie yourself to a single technology.

Questions from our readers

Will you write another book on Perl? Or maybe other language or technology?

Right now, I don't know, but I have no plans in the works. I've thought it would be fun to write "Perl for Crimelords", showing a novice programmer using Perl to improve the efficiency of a criminal syndicate. It would certainly get noticed, but perhaps not in the way we would like. That being said, I'm so busy with my company, being a husband and father, and books pay so poorly that I don't anticipate getting around to it.

How to find a job overseas?

This would take far too long to cover here, I'll punt and and direct people to the "Start Here" page on my expat blog.

Interviewed by Viacheslav Tykhanovskyi (vti)