How Does a Programming Language Stagnate?

by chromatic

A lengthy thread on the Perl 5 development mailing list has asked if there's self-generated FUD about the future of Perl worth debunking.

I'm not the person to ask about the viability of using Perl 5 for new development projects in your own environment (and I can't wait for Perl 6), but I had an interesting thought about how to gauge the suitability and evolution of a language today....


Aaron 'Teejay' Trevena
2006-06-23 04:15:28
One thing you haven't mentioned is perl jobs and projects..

I've been looking at, and it shows a steady growth in perl both the number of perl jobs, and the share of perl jobs.

I've also had more freelance work than I have time for, and am working on a new mission critical project handling, scheduling and providing data feeds and briefings for pilots and airlines. Rather than moving from perl to another language, all this work is either new or replacing existing perl or PHP with new Perl.

One thing that I've noticed is the presence of Perl code that hasn't been updated at all for 2 to 4 years, and is often 6 to 8 years old - there has been so much progress in last 2,4,6 and 8 that it's possible to replace hundreds of lines of code at a time by updating to modern modules and ways of doing things.

I've also noticed more standardisation appearing than the perl community is given credit for. Particularly among developers I work with on a freelance and contract basis : those that are involved in the perl monger community are using unit testing, packaging their modules to pass Kwalitee test, using CPAN modules more consistently, and following better practices.

I think that the increasing number of workshops, conferences and technical talks, as well as the high quality of articles and books available together with projects to normalise and standardise some areas of CPAN like Date/Time, Email, etc are having a really healthy effect.

I don't see any stagnation here, I see that Perl is still the cinderella of languages, doing the hard work, while the ugly sisters get all the attention ;)

2006-06-23 12:15:54
Good points, Teejay.

I wonder if the better development practices you mention are spreading throughout all of Perl development, or if the kinds of places that hire good freelance and contract developers have sufficient community connections that they learn and follow good community practices soon after their discovery.

2006-07-01 10:20:41
Hi chromes,

You're right, the perception of Perl "languishing" is due to some shortcomings well outside the core language. In the web app arena, it's self-inflicted.

Rails is hitting a sweet spot with "convention over configuration" with regard to Java (and all its frameworks). Perl programmers naturally reach for Catalyst, hoping for the same "programming within restrictions" experience where convention has already sorted out the best/easy way to get things done.

Then we find that Catalyst is nothing like Rails -- too many choices. Do I really want to hear how flexible Catalyst is? No, I want to hear how simple it is -- that's what frameworks are for, right? Simplicity, not infinite choice.

Something "canned" like Rails just feels so smooth compared to the choice-heavy Catalyst which makes me stop, think, choose and question whether I made the right choices before I can get working. That's annoying.

It reminds me of the old office software debates about "best in breed" vs. "suite". Rails is an all-in-one suite, Catalyst is an "a la carte" menu of choices.

A lot of programmers don't get going on something until they thumb through an O'Reilly book on the subject. Unfortunately with Catalyst, the book will be 900 pages long, and the first half will cover configuration like choosing which templating system, object-relational mapper etc. Bleh.

What ever happened to the notion that Perl "just works" and "understands what you mean"? The language is great, we just need a more monolithic framework.

Peter Scott
2006-07-06 08:04:27
Paradoxically, much of the resurgent Perl 5 development can be viewed as evidence of stagnation, or obsolesence. (I tried to find a less inflamatory term there but failed; I'm really trying to imply something less drastic than "end of life" and more like "senior citizen".)

As a long-time Perl developer, I find the latest Perl6:: modules and the similar "convenience" modules very helpful, but what do they imply for new developers? When new people complain that certain tasks are onerous, and a Perl elder tells them, "Hey, just use SUPER, NEXT, Attribute::Handlers, IO::All, IO::Prompt, Perl6::Say, Getopt::Euclid, and Perl6::Rules and your code will be so much leaner," what do they think? Where's the coherent pattern in this mix of modules, or even the roadmap? You have to either get PBP or be plugged into the Perl community fairly well to be in on that news. It all looks great to us who are already there, but it forms a rising barrier to new entrants who look at, say, Ruby, and realize that they can have much of the same ease and simplicity they'd get with the spiffy (or Spiffy) Perl modules just by reading the one little Ruby book. Like Ptolemaic epicycles, these patches on Perl 5 could be viewed as attempts to patch up an inadequate foundation.

That's harsher than I'd like it to sound but I want the point to be visible. It's the reason why I've been waiting so eagerly for Perl 6 for so long, because I see it as the solution that brings more fresh blood into Perl. I have a little nightmare: We've probably all experienced some aging guru at the workplace who was married to some ancient language. People will be talking about how to write, say, linked lists in C, and this person will say, "Hey, that's a piece of cake in RPG/COBOL/JCL" and go off and do it in fifteen minutes to prove it. And it works, but no one else can understand it or be bothered to try to understand it. And my nightmare is that we end up like that. Which is why I so much want Perl 6 to succeed.

Stagnation is a tricky thing to wrap the brain around. How do empires fall? With all those resources, they should be able to last forever. But they never do. Stagnation isn't a uniform affliction; it starts in one place and works its way to the others like some sort of digestive process. Recognizing it at the outset is the hard part.

2006-07-06 11:56:47
That's an interesting point, Peter. To me, it sounds like the recurring debate over core and modular features.

It's a shame, for example, that Perl 5's built-in metaprogramming facilities are so clunky. Ruby has a clear advantage there.

However, when it comes to finding and (often) installing extensions, Perl 5 has an even larger advantage with the CPAN. It's difficult to argue with over 10,000 available modules -- but if you don't know what you want or how to find something that takes away the pain, is that really an advantage?

Like you, I look forward to better defaults in Perl 6. That's clearly one necessary improvement.

Peter Scott
2006-07-06 16:27:46
I intended a more important point than revisiting the core/modular split (not that I wouldn't rather have io() and say() in the core than getgrent() and shmctl(), but not to get sidetracked...) Modules like SUPER and NEXT are pragmata designed to make Perl behave the way we (for large values of "we") think it should have behaved to begin with. Attribute::Handlers is the same; who's going to try and do much with attributes without it?

Then there's Class::Std. It is my understanding that aside from inventing something so powerful, a major reason for creating it was to provide a standardized method for writing O-O classes so we could end so much time wasting caused by the dark side of TMTOWTDI. I've been giving presentations on Class::Std and telling people to just use it so they don't have to spelunk around CPAN and read numerous articles to try and figure out what they should be using, but many people seem to want to keep the debate going, and I think that hurts us when people can go use languages like Ruby that haved moved past that.

So you've got to be clued into which "hip" modules to load just to get Perl behaving the way many people think it should. The standard documentation doesn't have a roadmap leading people in this direction; they pretty much have to dig around and keep up with the latest Perl news and books. I've got no problem with requiring people to be clueful to join in the game, but learning what amount to arbitrary incantations doesn't accomplish that.

Of course, Python and Ruby will go the same way after a few years if they're as successful as Perl, because this richness is a mark of maturity. (I'm looking forward to rubbing a few smug noses in it when it happens.) But it's also a mark of a legacy system. And the only cure is reinvention. Perl borrowed from many languages and improved upon them; now Python and Ruby borrow from Perl and add their own improvements. The only answer is to innovate. Jefferson thought there should be a revolution every generation; same here.

Yes, Perl is ahead - considerably - in areas like CPAN, but as I was alluding before, stagnation happens nonuniformly. The Persian campaign can be expanding the imperial frontier at the same time the citizenry is wobbling around from lead overdoses.

I would take a different tack if we didn't have Perl 6 coming up. I am convinced it will take the programming world by storm and I'm just frustrated it's not released yet.

2006-11-12 22:34:12
I still use Perl for my sites (,, as well as tidbits of code, prototyping (even if the app will end up being in Java) and a whole host of things.

My work bought me Komodo from Activestate so I could do my Perl and Ruby coding when needed. I agree that more of the focus now is on modules like CGI::Application, Catalyst etc etc and not so much in the language itself. Yes .. there is a big gap between 5 and 6, but perl 5 is still useful.

I am also a little embaressed to admit it, but I probably still largely have a coding style like it's perl 5.005_003. I first learnt Perl 4 at university, then upgraded from 5.001 to 5.005_003 in my first job. Perl 5.6 came and I didn't change that much, even with Perl 5.8 .. same thing.

Perl still fills a gap. If need to grok a log file, do some web scanning (WWW::Mechanize is cool) or prototype something, Perl still helps me out. I do like Ruby as well, and Agree the whole Rails thing has made web dev easy in that environment compared to CGI::Application with Class::DBI, but you know what? I still maintain an Perl Web App I wrote 6 years ago .. with a homegrown templating system, and it still works.

I think the whole "perl is dying" thing comes from people seeing other languages and frameworks in the limelight. I think one of Rails biggest successes was a build a web application in 15 minutes tutorial in 15 minutes, and watch the video if you can't be bothered doing it .. and it looked pretty. C still has its place in microprocessor programming and OS level stuff. Perl also has it's place as well as PHP. The whole Sapir-Whorf hypothesis (which Ruby language creator Matz talks about as well) talks about language influencing thought, and perhaps our thoughts influence the programming language we want to "think" in.

I think the language grows through the modules, and it's still growing. Like you mentioned in the comments, CPANs modules for Perl5 are a huge strength for the language.

2007-07-18 08:26:57
I think this pretty much sums up the problem with perl

Dramatic decrease in new projects and new developers.