Unifying the Two Worlds of Perl 5


Perl 5 has two separate poles around which we users orbit when considering the historical stages of Perl 5 adoption: system administrators and developers.

While explaining the meaning of the phrase "Modern Perl" the other day, I realized that there are two categories of users of Perl 5 when we consider the use of Perl 5.

One category uses Perl 5 because it's ubiquitous. It's already installed and configured (whether as part of the default OS installation or a shared hosting package or a helpful system administrator). It's easy to begin. Copious tutorials abound, the core libraries are sufficient, and Perl's lack of ceremony means that they can write baby Perl and get their jobs done and that's as far as it goes.

You're in the other category, almost assuredly. I am. We use the CPAN. We look forward to upgrading to Perl 5.14 and Perl 5.16. We see something like MooseX::Declare or Plack::Middleware::Auth::Basic and can't wait to replace custom code in our applications with a component other people have written, documented, tested, and maintained. We're comfortable with a community built around the simple structures that have arisen from community consensus regarding the CPAN.

Modern Perl, as I see it, is an invitation for the people in the first group to join us in the second group.

With that said, we must keep in mind the concerns of the first group:

  • I'm not necessarily a programmer.
  • I'm not necessarily a system administrator.
  • I don't understand how to manage dependencies effectively.
  • I don't know which modules to use.
  • I'm stuck with an ancient version of Perl 5.
  • I don't know which book or tutorial to read.

... while removing technical and social barriers to encourage them to join the second:

... and more.

Not everyone in the first group will migrate to the second, but given that the evolution of Perl 5 is primarily in the hands of the CPAN these days, we can only do novices a service by making the CPAN ecosystem—code and tribal knowledge—available.


Never met a sys-admin that had problems with dep management. Dependency issues tend to be something created for us by programmers who don't have realistic constraints.

As Aristotle also pointed out the issue is more complex though I would not draw the lines the way he did. I also find it funny he put me in the "Windows and GUI Stratas". If I am working on something that benefits those areas it is because I think they were way underrepresented and underserved (if there was such a word) in the Perl world. I am mostly a Linux user and I do a lot on the command line. I also use the Internet. Which probably means I am also in the web-strata :)

Anyway, I think there are a lot of people out there who write big applications on Perl use some CPAN modules - but probably not enough and maybe not the advanced ones. Many of the write "ancient Perl", don't write tests, don't write documentation and get the organization to the point where they rather rewrite it in another language than try to improve the coding standards.

I hope they will also see Modern Perl as an invitation to further improve their coding capabilities.

And another though. Why would the sysadmins and other similar people even want all the extra features that come with all the Modern Perl? I agree to things like 3 param open but why should they need to use Moose?

I hope we can agree that Moose and OOP in general are not needed for a 100 lines long script but are very useful for a large application.

Moose is certainly no requirement for Modern Perl applications, but Moose where appropriate is a characteristic. I have plenty of good code that avoids even the use of functions, as a five line program which saves me two minutes a day (and never needs any maintenance) is a great use of Perl.

Passing write roles on the filesystems, I see other "two groups":

1)People using it "just by work", like any other tool.

2)Technology lovers and people who get up from bed each day with a desire to improve.

I think that in both of your groups, sysadmins and developers, you will find people on my two groups.

Maybe some sysadmins in the "technology lovers" group, may get to try to move to the "developers" group, and keep enjoying the experience.

I reached Perl at work, doing typical "sysadmin" stuff (ninjutsu).

Now, sometimes I spend my hobby time, trying to improve my Perl skills.

Why? because when I discovered it, did the job really well.

Learn baby Perl, write and fix a complex (and long in the time) problem, was about a few hours with vim and a browser.

Thats why I fallen "in love" with Perl as "sysadmin".

Next weeks I started a homemade monitorization system (web side on CGI) and in less than a month I had a working version with all the planed functionality.

Then I discovered all the wonderful community, tools, documentation etc behind that interpreter.

Other way to "hook" people, is improving what they get without asking or need. But some people, on some linux distributions, keep looking at perl as perl4, and they prefer to pyframeworks for create nests of indented elsifs.

Greetings :)

From my perspective there's a somewhat different issue. More and more of the sysadmins (or a lot of the group that's calling themselves 'dev/ops') have a very negative view of Perl and prefer Python since it seems to play more nicely with their preferred tools such as yum, apt, etc. At least that is what they tell me and I work with such a group.

Now, I got one member of the team hooked on local::lib and excited by Plack, using Perlbrew, etc, so this is something that can turn around. For me, I think focusing on how Modern Perl is capable of making their life easier is worth doing, however I don't think they are going to join us in the movement since we seem to have already lost them to other languages for the job they need to do everyday. The most I can think to do is to find ways to make them see Perl in a positive light so they are not tempted to add to the negativity.

Interesting that you comment on the admin angle. I just wrote a proposal and demo code for integrating apt-get (and other distro installers) with cpanminus. Perl distributions install via apt-get by default, with fallback to cpanminus (typically installing to a local::lib.)

I've just posted to p5p, where I learned CPANPLUS has a related functionality, although heavyweight, converting CPAN distributions to debian (or other distro-specific package formats) automatically.

I would like to see better integration of CPAN and distro perl package repositories. Certainly worth investigating how Python et al. handle platform and external dependency issues.

Both worlds are not so far apart as some may think. Nowadays there seems even to be a new "DevOps" wave combining the best of both worlds. See the presence in Fosdem this year: http://www.fosdem.org/2011/schedule/event/devops_more

The complexity of code written by System Engineers is not negligible when you need to manage a server park composed of hundreds -often diverse- servers. And where the architecture is extremely complex. And when an error can and will have consequences of a biblical scale. You get the idea.

A System Engineer may not write code to sell shoes or airplane tickets directly, but may instead build systems to automatically compile cobol, c and java, package it and deploy it according to weird and strict rules. Or create webapps for internal users, etc, etc. And all this without forgetting enterprise politics when people in the "Production Department" end of writing the code when the "Development Department" is not willing or able (budget) to do it. Been there, done that.

Some years ago --while I loved Perl-- I learnt Java purely out of frustration with Perl OO. Moose pulled me back for programs that are indeed longer than a few hundreds lines. Now I am happily writing those programs in Modern Perl. Java is now a very nice tool in my toolkit, but my main language is Perl.

What did System Engineers picked up from developers? The tools, the books (yours is great, chromatic), the testing culture (when present on the other side of the wall, but that's an other story). And yes, the kind of System Engineers I talk about often compile and package their own Perl releases (Solaris ships 5.8.4...) and CPAN infrastructure. What do System Engineers *force* developers to pick up? Release management, policies, attention to the big picture ("it flies on my laptop, why is it slow on a Oracle Sparc M9000 server?").

I don't know if things were different in the past, but System Engineers can be one of biggest Modern Perl allies, not a blocking factor. It pays to keep them happy ("Hey, there is a modern perl version installed on all system!"), we (us, the Perl community) will pay dearly in the opposite case (e.g. look at the present Ruby-Debian problems).


What about those of us with a foot in each group? I use latest perl -- still excited about // (and always will be) -- but I have no use for massive OOP frameworks or huge dependency lists. I use the hell out of CPAN, but I don't want the dozen modules all the "modern perl" stuff seems to depend on. My only real problem is that it's impossible to standardize and distribute a large set of CPAN modules. Right now my only option is to use Haul and tarball up a directory. I don't intend to share site-perl/ from an NFS server to a thousand-node compute grid.

I wish people would spend less time re-engineering Perl syntax and more time making Perl deployable at scale.

Modern Perl: The Book

cover image for Modern Perl: the book

The best Perl Programmers read Modern Perl: The Book.

sponsored by the How to Make a Smoothie guide



About this Entry

This page contains a single entry by chromatic published on February 21, 2011 11:08 AM.

Technical Knowledge Doesn't Age Like Fine Wine was the previous entry in this blog.

The Secret Weapon is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by the Perl programming language

what is programming?