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.

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.

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…

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… :)

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.

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.

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.

http://lui.arbingersys.com/

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.

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.

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.

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 …)