Promoting Perl

After this weeks discussions about naming a shovel a spade, and how that would increase sales in the hardware store. I hope to start a substantive discussion around promoting Perl.

Dear Reader, please don't let the above metaphor become a stumbling block. Your ingenuity is desperately needed.

The first hypothetical question I would pose is:


  • If you had $10,000 to promote Perl - what would you do with it?


Please don't get lost on the dollar figure. This is intended to be an exercise in stretching the imagination.

Another question pair is:


  • What meaningful metrics could be used to measure Perls growth? (github stars? ithub commits? cpan releases? others?)

  • What activities could be co-ordinated and performed, that would increase these key metrics?

A quick Google search (or, DDG) provides many peoples thoughts about growing open source projects:

Reading through them all, they have many of the same themes:


  1. The Project being useful and high enough quality to be taken seriously

  2. Great documentation

  3. Open to contributions

  4. Content creation and Syndication

In reference only to Perl 5, i think point 1 of the above can be ticked off. Certainly, the recent deprecation of CPAN in favor of MetaCPAN has done much to add to point 2 (Great Documentation) - and no doubt more can be done in this area. There is after all, no perfect introduction of explanation - difference people will "get it" from one perfectly good introduction but won't from another.

Lowering the barrier to contribution and regular contribution (point #3) is a topic covered frequently at YAPC's. Tools like Dist::Zilla have helped enormously in making contributions to CPAN. Similarly, Github has helped perl as much as it has helped every language, in making contributions more straightforward. I would be very interested to learn about tools and platforms in other languages as effective as dzilla+cpan+cpantesters+etc. That said, maybe we as a community need to talk about them more... much more.

Which leads to point 4, which after all the above waxing lyrical, is the area I hope there can be more discussion.

To answer my own hypothetical question as to what I would do with $10k - I would hire a PR firm to push content out there. Publications (digital and print) are desperate for high quality content and contributions. In contrast to a marketing firm (which runs ads) a PR firm looks for ways to get the client's name out there through opportunities to be seen - so provide quotes, to provide content etc.

Alternatively, I would use the CPAN PR Challenge as an inspiration of sorts to run Blogger of the month / year awards. Of course there can be various categories, which would allow more people to be recognized whilst steering content creators to provide a variety of diverse content. Awards ceremonies are also an excuse to dress up, get together, (drink), and get lots of media coverage.

Both might be used together - generating content, then pushing it out as far and wide as possible.

A related option, would be to have grants around improving the websites, tutorials, introductions (even Docker containers) of key Perl software.

There may also be some easy opportunities to improve tooling, to automatically shout out to social media and news websites about new releases. Once upon a time, the dist::zilla twitter plugin kept #perl busy - i think twitter hates API's now (and frankly, Twitter is dying). But new perl releases don't get a mention on sites like Phoronix (whos purpose is to get clicks by curating release notes in to news articles), lwn, even slashdot.

What are people's thoughts?

9 Comments

Are you promoting Perl, or pecific projects written in Perl? These are not the same thing.

Who are you promoting Perl to?

1. Software Developers?
2. Management?

I don't think (1) is difficult, as long as they have a reason to use Perl. For full-time, professional developers, that means paid work that uses Perl, which means working on an existing codebase or creating a new codebase, which gets to (2).

Convincing manager's to approve the use of Perl has some obstacles, beyond convincing them it's a good development language:

- Dreadful legacy codebases written by amateur programmers. These generally need to be rewritten, and unless they already have good Perl developers on staff, they are more likely to be rewritten in another language.

- The availability of Perl developers to hire, often on-site (because they want them to train other developers on using Perl).

This is serious issue outside of major cities like London or New York that have a lot of Perl developers. (How many developers want to relocate to a smaller city or rural town with less cultural amenities, diversity, public transport, perhaps impoverished?)

I've had a manager tell me that Perl is fine, but it's much easier to hire C# or Java developers, because they are learning those languages in university courses.

(This is related to the issue of workplaces not hiring enough junior developers to train them in Perl.)

- The cost of Perl developers, in part because there are less of them, and in part because many are are senior developers.

From a manager's point of view, there's a crappy code base written in Perl, but they can easily hire 2-3 C#/Java developers of various skills to rewrite it, vs one senior Perl developer.

Thanks for bringing this up Dean. As I read through it I was composing a comment which - as I scrolled down - is almost exactly what Robert had already written :-)

The only addition I have to make is that when I see businesses moving away from Perl - apart from the difficulty of finding developers - it's because many other companies they depend upon via Web services don't provide Perl APIs. They leave it to the Perl community to implement and maintain it themselves rather than spending enough to maintain their own. Two examples are Amazon AWS and Stripe.

This means that the quality and comprehensiveness of the APIs on CPAN is dependent upon the resources of those using the companies' services.

In summary - if the Perl community could make it clear that there's still enough business for those companies to justify the expenditure of developing Perl API - perhaps by outsourcing to the Perl community - that would be a good way to stop the exodus.

Andrew's point about API support is a good one.

I'd like to add that while it's great to have "killer apps" written in Perl that are widely used, most companies won't care whether they are written in Perl. Their developers won't be looking at the source code or submitting patches.

Anyhow, if we want to promote Perl, then the best way is train new developers to learn the language (train developers in companies, provide training courses, not just at YAPC but other open-source/web conferences).

By training, I mean in modern Perl (Moo/Moose, plus Type::Tiny, Moops), web frameworks (PSGI, Catalyst/Cancer/Mojolicious).

Also do training/promotion of the excellent testing frameworks in Perl.

Focusing on how Perl can be used with common APIs, as well as how it plays well with other libraries, languages and frameworks is also important, since it's rare for a company to be using a single language.

We also have to remember that not everyone will be a full-time programmer. Bioinformaticians will more likely come from a biology or mathematics background.

O'Reilly used to host "Perl University" training courses. We need to bring something like that back. It's easy for a manager to think that Perl training is a good idea and then forget about it, but if there are regular training courses held in major cities, then that they will be more likely to act on it.

When there are more people who know Perl, they will be more likely to use it. This will encourage more services to provide/maintain Perl APIs. At it will mean there's a larger pool of Perl developers for companies to hire.

But that said, I also think we have to face up to the fact that there are more programming languages to use, some of which are popular or perhaps even better suited to specialist areas.

I have a great deal of experience providing training in various forms from lectures to part-time courses and 3-day workshops. I've found that the most successful formula is to train new hires as part of the on-boarding process.

Booking.com is doing exactly that: https://geekuni.com/case-studies/booking

(Note, for transparency - I run Geekuni)

Perl has a couple of major strengths [1], and some problems.

Personally I've found that there's no normal programming activity I can't do with perl that I can't do with any other similarly positioned language. But there's not a lot of perl being taught these days, and a lot of people teaching perl don't really have the capability to do so. I've spent the last decade trying to get my programming game as disciplined as I can. I would have done it in another language, but perl is fun, and I'm a self-teaching type person with a non-typical programming background. Perl is really well suited to such people. I've also had absolutely no problems finding perl work over the past 5 years, to the point where it's stopped me from learning other stuff and where I get the squicks when I dip into python, ruby and javascript in similar niches.

So to cycle back to the point, which is that perl has some major strengths. These are:

1. The CPAN and the fact that the test suite runs by default on every install. And that people have put big effort into making multiple versions and multiple module trees on the same machine [2] work nicely together. And that backwards compatibility is a major priority - yes this also causes problems, but personally I only want to pay attention to interesting things, not boring things like what other maintainers have been doing.
2. Perl scales. While perl will scale vertically and horizontally to the amount that you need (look for stories about the BBC iplayer from circa 2009 for examples) it also scales well in codebase size. Give me an example of another language which scales from throwaway one liners to hundreds of thousands of lines of code written over decades?
3. There's more than one way to do it. Perl is flexible. This is a major strength and a major weakness. If you learn discipline with perl you learn discipline elsewhere with the art of telling computers what to do. I've been doing a bit of Arduino C lately, and my perl skills have really helped. For example I hate switch statements in perl, but I've been able to adapt C code to be much cleaner by virtue of C switch. I've also been able to think about pointers (i.e. thinking about how dynamic method dispatch might work) in C much faster because of my perl skills. However the flexibility is a problem in an industry where pumping stuff out is prioritised over quality of workmanship.


[1] said strengths might also be its weaknesses.
[2] docker & co make this less relevant unfortunately

> If you had $10,000 to promote Perl - what would you do with it?

I open small Perl workshop in 10-20 people by Borrowing rental space Regularly.

And We talk about Perl each others and develop Perl open source or service.

And write blog about the meeting with some pictures.

Just a thought: Maybe we do not see often contribution in perl because projects just work. They just do not require 24/7 attention after implementation.

Leave a comment

About Dean

user-pic I blog about Perl. I am now in California