Monday, July 27, 2009

Perl's popularity problem...

There has been a recent flurry of blogs on Perl's perceived popularity problem:

I'm a little cynical. Many good insights and areas for improvement are identified. But Perl needs to gain mindshare. And the only way to do that is to deliver the goods: Perl needs best of breed and/or innovative killer apps...

There is very little going on today which makes Perl relevant to anyone outside the Perl community. The reality is that Perl isn't much on anyone's radar except the people who already use it...

The insights which particularly appealed to me are:

  • Perl5 and Perl6 could definitely benefit from a "This is not your father's Oldsmobile" slogan. Perl doesn't market itself well.

  • Perl could use a modern clean cohesive comprehensive web portal which borgs the best of what the scattershot sites out there provide: CPAN, PAUSE, Perl Mongers, perldoc, perlmonks, ironman, use.perl, perlbuzz, the various community SCM repositories, professional training, perl jobs, etc. An effort to unify those disparate sites and services into a cohesive whole using modern and enlightened Perl would give Perl5 a chance to redefine itself.

Perl may look dead to outsiders, but there is a lot going on within the Perl ecosystem. There is: Perl6 (std, Parrot, Rakudo, SMOP), Moose, Catalyst, DBIx::Class, The list will vary from one Perl programmer to another. There is Padre, which shows promise of being of interest to non-Perl developers. And new in-roads into Bioinformatics. But O'Reilly and James Tisdall laid that foundation back in 2001 and 2003.

Another problem we need to answer, is why projects which are bootstrapped with Perl leave it behind?

Git, Linus Torvald's SCM love child, was originally assembled with a whole lot of Perl duct table, bubble gum, and glue. But if you visit, you'll be surprised by how irrelevant Perl now appears to be to git.

Where are the new exciting, relevant solutions which use Perl?

Maybe they exist, but we're not aware of them? Muldis Rosetta is a truly relational RDMS (not SQL) being developed by Darren Duncan. Sounds interesting and promising... Does it work? Is it fast enough? Is it ready for use in production environments? Can it work with DBI, DBIx::Class, ODBC, JDBC, etc? Why aren't more developers involved with it?

Mojolicious looks like a fresh new MVC. In a fairly crowded field, it may be hard to distinguish itself. Take a look at Sebastian Riedel's recent Mojolicious::Lite blog.

Where are the other fertile grounds from which new solutions will arise? What other projects are out there which are using Perl to solve something new or solve an old problem in a better way?


  1. Have you seen the Google Wave video? I have and I am hooked now - if there is something that opens new horizons in Internet communication - then it is Google Wave. It is packed with clever ideas, and if it delivers, and it has the backing of the Google giant, it will change what we think about web applications. I really hope that the Perl community notices it - it is a bet - but if it works - then it will open a whole new field for hacking (and it will obsolete a lot of current web apps).

  2. I think the biggest problem with Perl's image is that it doesn't fit a specific problem area.
    Perl is not necessary or even considered popular or 'best' for web applications. This stopped more or less after CGI scripts got modernised and PHP came along.

    Perl isn't particularly good at building User Interfaces, making it a very unlikely choice for GUI applications.

    Perl can do all these things, in great part thanks to CPAN, but, as a general programming language, it's not known to be the master of any of these.
    The area where Perl keeps being strong are the usual: system administration, bioinformatic and general scripting for small jobs (and sometimes bigger ones). In short: niches.

    There is nothing wrong with that and it's going to keep people using Perl for solving lots of problems for a long time to come but unless Perl becomes really good at solving problems that mainstream developers, those who write line of business apps for instance, care about, then Perl is going to stay low key.
    Again, nothing wrong with that.

    Maybe we should, as a community, dare to confront other languages and frameworks head-on and *prove* that Perl is a 'better' (faster to develop, offers better performance, better reliability, better maintainability, better testability, better integration, etc) option than other offerings in some areas.

    Instead, we tend to keep talking about Perl like a general-purpose thing that's kindof pretty good but maybe a bit too general to attack any narrower-purpose offering head-on.

    In the end, for Perl to win the hearts of the masses, it needs to solve today's problems better than what the masses are using.

    Maybe Perl's problem is an issue of defining what it's supposed to be for.

  3. Hey Garrett,

    Great to see this conversation unfolding. Many thanks for the link.

    There are several new posts today on this topic around the Ironman ecosystem. Hope you'll do a follow-up post, as you have some great points and I would enjoy seeing them expanded on.


  4. Hi, I have a couple jobs that I would like to advertise on your site or via an email list to inform your readers about Perl programming jobs. Please get back to me as soon as you get a chance.

    Look forward to hearing from you.