← Интервью /
Interview with Neil Bowers
How and when did you learn to program?
In 1980 my Physics teacher brought a ZX-80 into class (a kit-built computer only available in the UK). Sometime after that the school got a Commodore Pet and I started playing round on it. The same physics teacher took a few of us on a trip to London, where I bought my first book about writing programs (mainly games like Hunt the Wumpus) in BASIC.
Some time after that I got my first computer, a Vic-20. That was the start of my addiction.
There's no one time I can point to and say that is when I learned to program. We're always learning, but there are definitely milestones and key experiences I can point to. For example: I spent one undergrad summer working for my CS department, porting a VLSI design program from Unix to VMS, to run on the graphics terminals we had. I had a lot of guidance from a postdoc (thanks Neal!). I learned a lot about C, make, software in the large, graphics terminals, perseverance and when to ask for help.
What editor do you use?
I use vim.
My first experience with a true text editor was SOS, used on a DEC-10 in my first year at University. At the end of the year I got an account on a Vax running BSD Unix, and had my first exposure to vi. After SOS it was fab. I also used Eve and EDT at Uni, but whenever possible I wanted to use vi.
I periodically try new text editors, and I had an extended affair with emacs in the 90's, but whenever I need do some serious editing, I always want vi.
I laughed when I read in your RJBS interview that he said "I'm not a Vim zealot or even much of an expert". At the QA hackathon last year I sat next to him working on a PAUSE testsuite. I came away thinking "man, I need to improve my vim knowledge!", and subsequently bought a book. I better read it before this year's hackathon! :-)
When and how have you been introduced to Perl?
In the late 80's / early 90's I was doing a lot of text processing, writing scripts with a lot of awk and sed, as was a friend in the department. He came across Perl and said we should take a look. Wow, pretty wild.
I moved to New Mexico and was working on a visualisation and image/data processing system written in C, which had to work on as many variants of Unix as possible. We had a wide range of machines on our desks, and would get loaners as well. When I got there, they had a build system for compiling across all the machines, which was a collection of shell scripts. I rewrote it in Perl 4 and had great fun. From that point on I steadily wrote more and more Perl.
What are other programming languages you enjoy working with?
Perl has always seemed like the language which best matches how my brain is wired. Scala is the first other language where I've felt something similar, but I haven't done enough to know if it's just a crush.
A bunch of Perl people did an online course on programming languages, and seeing their tweets made me wish I'd signed up for it. I fancy playing with Haskell, Clojure, Rust and Go. Someone should do a language challenge: a language per month with randomly assigned tasks!
What do you think is the strongest Perl advantage?
CPAN and the community around it, but then you might have expected me to say that.
Personally, I find myself able to express myself most efficiently in Perl, though some of that is obviously just down to experience.
But what really makes me efficient in Perl these days is CPAN. That can be at very different levels of abstraction, from a full-blown framework to a single sub in a utility library. Writing a script for the Pull Request challenge at the weekend, I needed to randomise an array. I could easily have done that myself, but I thought "probably something in List::Util", and sure enough, there was shuffle().
Among many ratings/graphs on your website which one do you think more people should know about?
It's not quite a rating or graph, but I'd say the adoption list.
Open source is largely built, and particularly maintained, in spare time. People's interest, motivation and time for it naturally ebb and flow. They scratch an itch, release some code to CPAN, then move on. Later on other people have that itch, but the code may need some work before it provides the right scratch.
If you want to learn about CPAN, the toolchain and the community, but you don't have an idea for a module of your own, then find a CPAN distribution in the need of some love and which appeals to you, and get to work.
Once you've done that, I suspect you'll be more likely to release something of your own as well.
Do you think CPAN needs curation?
Ha! Yes, it does. Actually, I think that curation needs to take a number of different forms:
Removing distributions from CPAN entirely. You need to be careful doing this, because you've no way of knowing whether a module is being used, other than when a module is used by another dist on CPAN. But there are very old dists on CPAN that haven't been usable for years. And with a long enough deprecation cycle, there are plenty of more recent dists that could safely be removed from CPAN, I think.
Deprecating modules, particularly when there are one or more better dists for doing the same thing on CPAN. Deprecating a dist is the right thing when a dist is no longer going to be maintained, but you can't remove it (yet), because there are other dists on CPAN using it (and don't forget DarkPAN). Any::Moose is a good example; it's now deprecated, but there are plenty of dists still using it at the moment. Hopefully they'll gradually be moved to Moo, or Moose.
Improving the documentation for modules. Obviously third parties can only improve the doc by sending patches or pull requests. AnnoCPAN was kind of an attempt to address that, but unless it's fully integrated with services like MetaCPAN, that's never going to take off. Github has made me much more likely to submit a documentation improvement.
Writing a good SEE ALSO section in the doc for your modules is one of the best ways you can help people who are looking for modules, because it aids discoverability on MetaCPAN, for example.
Community generated metadata / annotations. Favorites are one mechanism we have for this now, but tagging and other types of metadata could be provided externally from distributions themselves. CPANratings is a good idea, but one problem is that if you improve a once-badly-rated dist, it can be hard to to improve its ratings (eg by getting negative reviews that are referring to a previous release). This sort of annotation should let us identify the "best of CPAN", without needing a separate CPAN for it.
Convergence. Where there are a lot of modules for doing the same thing, there is often no obvious "best" module: each is prioritising different things, for example. Sometimes, but not always, it would benefit CPAN to take the best parts of various modules and work towards a single "best of" module (hopefully based on one of the existing modules, rather than adding a new one). It's not clear what the motivation is here for the authors, since the individual modules were probably created by people scratching their own itch. Case in point: I've tried doing this with Olaf Alders, related to one of my reviews, but we both keeping getting distracted with other projects.
The toolchain and documentation need curating as well. Right now it's clear that it's not as easy as it should be for people to start contributing dists to CPAN. It's easy to write the code, but getting from there to a good dist on CPAN is non-trivial.
Bringing in ideas from other languages and tools. We're terrible at this, for the most part.
What is CPAN Pull Request Challenge? How can one join?
It's a challenge for 2015 to encourage people to contribute to CPAN and get involved with "the community" a bit more. If you sign up, then on the 1st of each month I'll send you an email with a randomly selected CPAN distribution (which also has a github repository).
You have one month to do at least one pull request. You can choose to do more if you want. The idea is that you should do something useful for the dist, which might be fixing a bug, improving the documentation, updating it to follow modern CPAN conventions, or improving the coverage of the test suite, for example.
It's based on the following thoughts, which I had after participating in the 24pullrequests.com challenge:
> Every dist on CPAN can be improved in some way that is useful to CPAN. > Following on from a thought above, that way could be deprecating it. > Picking the repos for the 24pullrequests challenge was hard. So I'll just > randomly assign one to you. One a day was too much like hard work. One > a month sounded a lot more feasible. I score CPAN dists according to some > measure of "worth someone looking at", and select from the highest ranking > dists.
The hope was that people might have fun while learning a bit more about the toolchain, and improving the overall quality of CPAN at the same time.
You join by emailing your github username to me: neil at bowers dot com. If you've got a PAUSE id, let me know that as well please, so I can make sure I don't assign any of your dists to you.
Did you expect CPAN PRC be so popular? What are the next steps?
Not at all. I've come up with a couple of CPAN related challenges in the past, and based on those I expected a dozen or so people might sign up. There are 372 people signed up to the PRC at the moment! There were three waves of signups: first when I posted it on my blog in late November, resulting in 20 signups. Then I posted about it to blogs.perl.org on Christmas Eve, and got another 50. Then someone put it on Hacker News on New Year's Eve, and the email started pouring in!
There's an IRC channel and emailing list, where participants are helping each other, for example with ideas on what to do, but also in usage of github, Travis, etc. It's a very positive supportive channel, because everyone there is trying to do the same thing. Plus there's a self-selection in the population as well. We're all the same kind of nutters, maybe?
I expect a hundred or so of those to drop out over the next month or two, but at the moment the energy is really high, and lots is getting done. It's very satisfying and slightly scary.
What's next? I'm working on extending the scheme I use to rank distributions. When people get their assignments, the email they get lists any known ideas, to help people get started. The more we can give people things like this, the more likely they are to pick at least one of them and submit a PR.
I had originally planned to start a second challenge, but this one is keeping me plenty busy at the moment. A secondary challenge I will be starting soon is to encourage more people to put their CPAN distributions on github. If you do (and the metadata lists the repo), then it will become a candidate for handing out in a later month.
Where do you work right now, how much time do you spend writing Perl code?
I work for a company called Cogendo, which I started with a friend when we were both made redundant.
Should we encourage young people to learn Perl right now?
It depends on how young you're thinking?
My son is 7 and has so far slightly engaged in Logo. I wouldn't try him on Perl yet, but will probably try some other language soon. I think children are better served with a less complex language, which is simpler and thus easier to learn.
He mainly thinks computers are for Minecraft and flash games right now.
Questions from our readers
When CPAN Report 2014 is coming?
Ha! Hopefully soon. I planned to do it around New Year, but then the PR challenge took off. Now everyone's got their February assignments, I'm hoping I'll have time to finish the CPAN Report.
When I first got these questions from you, I thought "Oh I'll have that done before I've replied to your questions!". Hmm. My yak shaving tendencies don't help.
There will be a different slant to the report this year. I think you need to be careful what figures you present in a leaderboard, as it can easily end up driving a different behaviour than you intended, or hoped for.
A different theme each year is no bad thing anyway, to keep things fresh.
How long is your cpan review backlog and when to expect new reviews?
Before I give you a number, I should explain: whenever I realise there are a number of modules for doing roughly the same thing, then I think "that's a potential review", and put it on my trello board for reviews.
I have a number of reviews in progress, and some that are just a list of modules, and others that are just a card on trello.
Altogether my backlog has 22 reviews. The next review I'll publish is on Exporter modules. I've written up most of the 40+ modules, and even did a talk on it at the London Perl Workshop last year. I keep getting distracted from finishing it. See answer to previous question :-)
What do you think is the best way to give back to the Perl community?
Sign up for the Pull Request challenge and do at least 11 PRs in the rest of the year! :-)
I think the best way to "give back" is to help other people in concrete specific ways, particularly beginners. Helping others often requires you to learn things. I'm learning a lot doing the PRC: people ask me questions and I'll think "oh, I've no idea. That might be useful to know though, so let's find out".
And if you want something more to do, adopt a distribution on CPAN. Polish it up and possibly be ready to hand it on.
If you don't want to adopt a distribution, contribute to some of the less "fun" parts of CPAN development & maintenance: improve the documentation, fix a nasty bug, or improve the test coverage. It's a lovely surprise for an author to get a PR for one of those.
And blog about it. Share your experiences and encourage others to as well.
One of the bits that's making me most happy about the PRC is how friendly and helpful everyone is being towards each other.
Interviewed by Viacheslav Tykhanovskyi (vti)