To help research for a talk I’m giving soon I asked the OPEN mailing list:
Please spare a few moments to jot down your thoughts about the Perl language, CPAN, the community. Even if you don’t use it. In fact, especially if you don’t use it. How would you choose a language to develop a new web project? How would Perl rate, and why?
The OPEN mailing list is “is a community-based mailing list for the discussion of general Web, Internet and related technologies” in Ireland. The participants have an eclectic mix of web related jobs and interests. There’s certainly no bias towards Perl.
I’ve tried to distill the key points and group them into topics. In the process I’ve made some slight edits.
Just in case it’s not completely clear, these are not my views, they are a summary of the assorted views of others. I offer them here to give some insight into how Perl is viewed outside it’s core community.
General:
- Perl is seen as a sys-admin language. Still used for back-end jobs.
- PHP is easier to deploy at front end stuff.
- Perl is still more powerful and easier to deploy backend.
- Too complex compared to PHP. Code overly obtuse.
- For web development Perl is losing ground to the more mainstream languages such as Java, PHP, .NET etc.
- Perl is over complex and out of date, a sort of Cobol of the scripting world.
- Perl has aged well. Its no longer the only choice for tasks but it is still very useful.
- Perl 6 is killing Perl (slowly). But Perl is still popular, see http://www.tiobe.com/tpci.htm [I plan to do a post about apparent significant errors in the TIOBE results — Tim]
- Perl community has a great reputation.
- If scripting language were spanners:
- PHP would be plastic spanners (too brittle)
- Python would be Gold (too soft)
- Perl is pre 1989 Ironmongery (not the cheap west german crap)
- I know what type of spanners I want in my toolbox.
Skills Availability:
- Perl developers are now hard to find and expensive to employ when compared with the general over abundance of say (let’s face it, mediocre) VB.Net developers
- Whilst some might say that clients are just jumping on the bandwagon by demanding things be built using .Net framework etc. This may be true to an extent, but there is the logic of accessibility, maintainability and affordability being applied here.
- There’s no point in having something built by an individual or small team, to find that 2-3 years down the line the original team are nowhere to be found and the system requires major re-working/upgrading etc. and there’s only a tiny handful of “experts” available to take over (at somewhat large expense).
CPAN:
- Perl has some nice features. The best is that when you install a piece of Perl software on Linux, it works. It is very easy to locate and download the modules you need to get it going. Python, in contrast, tends to have modules all over the place.
- CPAN is a bit of a mixed blessing. Using it tends to fall into sorcerer’s apprentice mode and the associated dependency hell;
Maintenance and Maturing Coding Styles:
- I found that I couldn’t read scripts six months after writing them. At that stage I switched over to Python.
- My style in Ruby programming is so different it’s hard to be sure it’s the language (when maintaining or extending Perl and PHP code I now backport the Ruby way of working to those languages where possible) and not the fact that I got the language and the ‘Ruby Way’ simultaneously.
- I trust the code I write in Perl, PHP and Ruby because it’s not opaque (unlike J2EE for example, which is an appalling hellhole of a world of hurt).
- My personal reason for choosing Ruby every time is that It Makes Writing Really Good Code Really Good Fun. Or as Why so poignantly put it “You’ll be writing such beautiful code it’ll make you cry”.
Hosting and Delivery:
- Many cheap hosting packages don’t work well out of the box with perl.
- I’d love to do all my dev in perl (and still so when other languages let me down), but PHP is so much more entrenched in the web hosting arena and totally painless in most ways, that perl takes longer and is harder to support.
- I have developed Perl into standalone items using PDK and it runs & runs at clients sites without any hassle.
Frameworks:
- Use of development frameworks is leveling the playing field between languages so it’s a personal choice and familiarity rather than any language offering that huge advantage.
- I don’t see Perl as being big in the web-framework world. It is just not on the Radar. PHP, Python and Ruby is all that I see. I am familiar with the Zope stack so I would use that for a new project. It is just too much of a learning curve to switch.
- Ruby/PHP/Python and a couple of others have market and mindshare; These guys also have really good ‘frameworks’ for the click-and-drool brigade (eg Rails).
- Perl is not getting nearly as much attention as Ruby and Rails, despite the rapid development of the excellent Catalyst.
Many thanks to those to responded: Diarmaid Mac Aonghusa, Paul Grant, Dave Wilson, Paul Mc Auley, Kevin Gill, Lee Hosty, Tony Byrne, Brian Greene and Fergal J Byrne.
Not this... 
What will ultimately kill perl is it’s readability.
In fact, I think perl is the least readable among the “scripting” languages,
with ruby and python leading the way.
(I prefer ruby because I can freely choose if i want to use embedded domain
specific languages or not. With python one too often has the impression that you
are told how to solve a specific problem. This may be fine, but you lose flexibility,
like when it was decided that a case/switch menu is a bad thing for python …)
The lack of CPAN-ish centralization doesn’t seem to hurt Python as much as it would Perl. With Python, batteries are included, so I haven’t yet felt pain equivalent to randomly picking from a field of N CPAN modules until finding something that actually works (or exhausting the list).
Could somebody please explain what is so “unreadable” about Perl code? I must be really dumb because I’ve never really understood that part. Surely that has to do with coding style? I’ve written loads of Perl over the years, and I don’t find it more difficult to read than any other code. Just like any language, Perl has its rules. Abide by them and you will be fine.
When people want to make the (false) claim that goto in C is bad, they normally produce really horrible code that nobody in their right mind would write, and use that as proof of the uselessness of goto. In a similar way, when somebody wants to claim that Perl is unreadable, usually that person will go out of their way to write exceptionally sloppy Perl code. Not fair, but many people fall for it.
Nowadays I use Ruby (and probably Python) more than Perl. One of the things that attracted me to Ruby was that it had a few of my favorite Perl syntax elements. Python less so, and it took me a lot longer to start feeling comfortable with Python.
A few things in Perl’s favor:
1. It feels solid. If I need to do something sensitive, I’m still likely to fall back on Perl, rather than Ruby or Python. (Well, to be fair, Python also feels solid, but Ruby is still catching up)
2. Awesome community. Perl people tend to be laid-back and friendly (at least the ones I’ve encountered. The Ruby community at large is also friendly, with the possible exception of the Rails crowd. Python is a great language but large segments of the community are horrible. They’re rude and elitist. They cannot tolerate even a hint of criticism of their language. Feels a bit like a cult at times.
3. Documentation. Perl books and other forms of documentation tend to be a joy to read, unlike the documentation for *ahem* certain other languages.
I have been trying to learn Perl. Have to say it was not enjoyable. It’s just too different from other languages that I know of (C/C++, Java, Python, Shell scripting, lisp etc). Even if I could implement something in Perl, I would hesitate to do it because I am not sure if my colleagues (who know mainly Java)can understand it. I think shell script and Python would be a lot more easier for them to read.
That said, I still think Perl is a useful language to know, because it’s installed in every *nix I work on (even if it’s only version 5.0). CPAN is impressive too.
Hello she. Lack of readability clearly hasn’t killed perl5, and perl6 is much more readable for typical code.
Several people have raised the readability issue. It’s like the old adage that “you can write Fortran in any language”. Sure Perl let’s you write messy unreadable code that only you can understand and only for that day, but it also let’s you write code that others will regard as beautiful: http://jeremy.zawodny.com/blog/archives/009873.html#comment-39486
Perl has a cultural norm of allowing you to express yourself through your code in any way you like. You can treat your code as hack, engineering, craft, or art. That’s why “There’s more than one way to do it” is such an important concept to those who care about how they express themselves. Personally I value that greatly. I take great care of how the code looks and reads. Others don’t. That’s their choice.
With regard to domain specific languages, once you see how grammars-as-classes work it should be clear that Perl 6 is an ideal platform for domain specific languages.
I made a reply at Perlmonks, but thought I’d drop a line here as well. You might be interested in looking at LUI, the “language usage indicators” page I’ve recently created:
http://lui.arbingersys.com/
Hello arbingersys. LUI looks interesting. It *really* needs graphs though! The few numbers I looked at have changed significantly already.
Like any statistic, the limitations of those in LUI need to be understood carefully before people quote them. Ohloh, for example, only covers a small fraction of perl development activity released through CPAN. (This may be true of other languages to a greater or lesser, and changing, degree.) Metrics are fun, but extracting information from them is tricky.
Speaking of community, a few years ago I was at OSCON and I was talking to two PHP programmers. I didn’t say anything rude about PHP, but they ripped into me about Perl. A few other PHP programmers joined us and one asked me “yeah, but have you ever used any other languages?” I replied “Assembler, Java, C, COBOL, Prolog … ” and one of the first two PHP programmers died laughing and one of them said “Prolog? No wonder you’re so messed up!”
The other PHP programmers laughed and I excused myself and walked away. I know that not all PHP programmers are like that, but I’m hard-pressed to remember such an obnoxious group of people (though one took me aside later and apologized for the others).
This is the one thing I *really* hate about programmers. So many of us like to take swipes at others for ill-considered reasons, and without considering the feelings of others.
Yes, graphs would be a definite improvement. I’m still kind of waiting to see how LUI shapes up. I cranked it out about a week ago when I had a couple days downtime, and it could be better in a number of ways. (I have planned, but haven’t had time, to query Perlmonks for suggestions.)
My idea for LUI was that, unlike tiobe, it wouldn’t try to endorse or interpret data, but just display a list of metrics that I (or others) felt were useful. ohloh’s metric is purely ohloh’s perspective, and is only as useful or important as the interpreter assigns it to be. It might need a better description to help with understanding its value. Also, it may be weeded as a metric, if it turns out to not be of high enough quality.
Also, you’ve given me an idea for another metric, if I can figure out how to get it: assessing the “CPANs” of various languages, to compare their size, activity, users, etc.
Since you mention TIOBE, arbingersys, I *strongly* suggest you try replicating their method and results. I did it manually for perl and python and perl came out with three times the hits of python – a very different result from what they show. They’ve not replied to my email querying their results.
“Since you mention TIOBE, … I *strongly* suggest you try replicating their method and results.”
Sounds like a good idea. I’ll have to re-familiarize myself with their method. I read it over once, long ago. (By the way, thanks — I’ve gotten two metric suggestions I hadn’t even considered, and I haven’t even queried Perlmonks yet… :)
I have worked in Perl for more than ten years, mostly to make dynamic websites.
General:
I think the Perl 6 thing is damaging. Wjat I would want from a Perl 6 is something that does the same thing as Perl 5, only with the improvements in speed and functionality we might expect after ten year’s experience. That does not appear to be what we’re getting, which – from my perspective – means that Perl 5 is it for Perl.
I find Perl to be easier than PHP. While PHP may be more readable, it’s complex to code (especially without a cheat sheet) and can be really difficult to debug. Ruby and Rails aren’t stable, nuff said, though they’re very elegant and may gain more of my attention in the future. Python is also elegant, but I can’t get used to the use of white space as syntax (I’m an old fart).
But also, Perl is fast. Especially when you get mod Perl running, it’s very hard to beat.
Skills Availability: it’s almost impossible to find Perl developers.
CPAN:
is OK. But there is a problem with modules that are out of date and not maintained. It’s not as bad as, say, Drupal modules. But it’s an issue.
Dependency hell. There really should be a rationalization of the best modules, and an integration of these into… what, Perl 6? 5.11? We shouldn’t have to ‘include’ an XML processor any more, or CGI.
The idea of storing Perl modules in the system directories (/usr/lib/perl or whatever) may have seemed like a good idea at the time, but wasn’t. People who didn’t have system-level access couldn’t use Perl modules (easily), which caused many of them to flee to languages where you *could* use perl modules (easily). Me, in true Perl style, I simply recoded the modules, until one happy day when I got to sysadmin my own machine.
For this reason, I never really got into the habit of writing modules. For other people, who came into it from another direction, writing modules may be second nature. But for people who only had access on other peoples’ machines (you know, students, staff, users…) writing modules was a bit (ok, a lot) arcane.
Maintenance and Maturing Coding Styles:
Writing object oriented code is a bit awkward. so I find, at least (could just be me).
I document my code, so I have no trouble reading it.
And… the code ‘just works’. I wrote a CMS for a major university site in 2000-2001. I left that employer and went on to a new job. It’s still running, without maintenance, to this day (of course, the fact that it’s almost module-free may have had something to do with that).
Oh – and Perl’s handling of regular expressions is a big plus for me. I described perl to a friend as “a regular expression processor with a programming language wrapped around it.” I haven’t seen anything else manage strings the way Perl does, and managing strings is a big part of my work.
Hosting and Delivery:
I’ve never had a problem. I told someone just today, who asked “where I got Perl,” it’s just there. Which is true (except on Windows, but that’s outside my world…).
Frameworks:
I’m mostly not interested in frameworks. Not because I don’t think they’re a good idea – they’re actually a very good idea. But they’re limiting, in that you’re largely bound by the framework, and they can be difficult to use (there have been some pretty awful frameworks out there).
I really can’t see frameworks being big in a language where it’s as much trouble to install (and manage dependency hell) a framework as it is to rewrite the thing from scratch. Just sayin…
“People who didn’t have system-level access couldn’t use Perl modules (easily), which caused many of them to flee to languages where you *could* use perl modules (easily).”
I think I have to disagree here. The way modules are contained with ‘lib’, it’s quite easy to copy the ones you need locally to your application’s directory, and tell your app to ‘use lib …’ at that location. I did this with Sylbi (http://sylbi.arbingersys.com), and was able to drop the application via FTP into my cheap web hosting. It requires such modules as CGI::Application, Template::Recall, CGI::Session, etc, which I had no guarantee of being available on my hosting provider’s servers.
On a limited access machine, you could build everything you need locally, but obviously couldn’t ‘make install’. Still, all the files you need would be there, and you can pretty easily create your own little repository of “must have” modules.
I think one of the major components that kills perl development on the web is that there are newer fresher development packages, from management perspective it’s very tough to justify ripping down what you have to rebuilt it again in the same language. It sounds much better to say that new language X addresses the old issues that ran into and then sell people on the grass being greener.
From a web development perspective I can definitely see the draw for Ruby on Rails and it’s framework, but I don’t think that it is the golden arrow that trumps perl or other languages in every way.
Perl6 is very damaging as about everyone I talk to jokes about “when is perl 6 coming out” and just adds to the idea that perl is an old crusty language for bitter sysadmins. My thought is perl should go for a more Ubuntu-esque release naming convention and run with dates or something that is far less monolithic than imposing version numbers.
arbingersys, you can even do ‘make install’ if you have non-root access to shell. You need to use Makefile.PL’s parameter to do this. Also you can use CPANPLUS (core in 5.10) for that.
Pingback: Perl Myths « Not this…
I used these “views from the edge” when putting together my “Perl Myths” talk.
See https://blog.timbunce.org/2008/03/08/perl-myths/ for slides and video.
Pingback: TIOBE or not TIOBE - “Lies, damned lies, and statistics” « Not this…