Perl needs The Solution

[jimt]

I think perl needs a general attitude of something I'm going to very generically call The Solution. This is completely contrary to the concept of TIMTOWTDI, but please bear with me

As was fairly reasonably stated over in Perl is dying, I think Perl is in trouble and I think the community isn't helping it (for the record, no, I am not the author of the original post there). The general Perl philosphies are cool and all and have their place, but I think they're serving to drive away potential new users of the language to others that are less scattershot.

At it's root level, I think it boils down to corporations (well, everyone) wanting to minimize risk. On the one hand, this is a dangerous proposition since as you minimize risk, you tend to also minimize creation, invention, new thoughts, and so on in favor of making things safer. But, if you add too much risk to a project, then your chance for success drops off so much that you're in dangerous territory. Risk vs reward progresses in some sort of bell curve shape, and I think we're perceived as being too close to the risky edge.

The classic saying in IT circles was "Nobody ever got fired for buying IBM." And it's been re-adopted all over the place. "Nobody ever got fired for buying Microsoft," "Nobody ever got fired for choosing Java," "Nobody ever got fired for betting against the Washington Generals." The lists go on and on and on.

The flipside (real or assumed) is that people do get fired for choosing less known or buzzword compliant or expensive solutions. If I chose IBM to provide my mainframe and it broke, then it's a fluke and I made the right choice. If I got a mainframe from Xerox and it broke, well, I should've gotten one from IBM.

So, in vague generalizations, it's already an uphill battle in a lot of places to get Perl accepted as a viable alternative. More people have heard of Java or .NET or Ruby on Rails AND (just as importantly) more of them have heard positive things about those other technologies recently. This is a knock against Perl. But there are positives that can overcome it.

The next stage is how Perl (and the Perl community itself) operate. TIMTOWTDI is fun and all (as I emphasized in What's wrong with re-inventing wheels) and there's nothing wrong in recreating things. But I will also admit that all of these myriad solutions create confusion in newbies that they wouldn't have elsewhere.

Say you want to create a simple dynamic website. Maybe you'll choose PHP. Templating there is easy. It's just...well...PHP. Or you could use Perl and choose Mason or CGI.pm or Template::Toolkit or Catalyst or HTML::Template or Template.pm or Text::Template or god knows what else. Your risk has now increased dramatically over PHP. PHP has The Solution. Perl has many solutions, advocated by different people for different things. They're supported differently. They may fade away and be replaced. You could make the wrong choice.

Say you want to create a new class to store some data. Ruby is easy. Just define your class and you're done. Perl makes you worry about blessed hashes or arrays or scalars or coderefs or inside out objects or whatever else. You could choose wrong. This is a fundamental basic part of the language that you could potentially screw up and make your life miserable about later on.

As a side note - I went to one of the talks on inside out objects at YAPC this year and it was a good show. But I was also sitting there thinking, "I shouldn't need to care about this stuff."

And I don't know how to fix this. It's a careful balancing act between being too strict and too flexible. I don't want to turn CPAN into PEAR, but I don't want to have 80 different ways to do things with no way to easily pick the "right" one, either.

Maybe it's a documentation and community issue. Maybe introducing users to simply blessing hashrefs as objects is the right approach and having a footnote that it can actually be anything and they can read more at XXX is all it would take.

Maybe it's some sort of definitive list of "you should use this" that's trivial to find and easy to read through. How to define what stuff goes on that list is left as an exercise to the reader. But I think it'd be invaluable for a new user to be able to hit CPAN and click on a link that says "Best practice" and bring up Class::DBI and Text::Template and CGI::Application (or whatever) and they know that they should download and use those.

Even better - their boss then knows that they should use those, too. And it minimizes risk. If one of the "best practice" modules doesn't work right or breaks or ceases development, the programmer gets to point to that rating and say, "Well, I chose the best practice one." This doesn't stop you from going off and re-inventing your own wheel or downloading something else, but you're doing it with the knowledge that it's not necessarily consider the "best solution". You're adding to your risk.

Perl's flexibility is one of its greatest strengths, but it also makes it pretty scary to new users. So how can we minimize risk for them and make them feel comfortable that they're making safe choices? Oh, I also don't think responses along the lines of "read PBP!" are going to cut it. I don't need to go out and buy a book to know how to do templating in PHP, and I shouldn't need to buy one for Perl, either.

The community is also right out. People bicker and argue and have different opinions. Let everyone who uses perl put their two cents in towards defining The Solution(s), but have a clear list of what those recommended solutions are so the n00bs don't ignore us in favor of somebody else.

[ptum]

I think that trying to make Perl (or its community) be something it is not to gain marketshare is doomed to failure on both counts ... I don't think you'll be able to convince the Perl community to abandon the TIMTOWTDI philosophy and I don't think it would substantially change marketshare even if you could. Better to acknowledge Perl's strengths and weaknesses and apply it where it can best shine. No sense in using a phillips-head screwdriver when a flat-head is called for.

Yesterday I sat in a meeting with a PHB from another group who wanted our group (with mostly Perl expertise) to take on a project for him. He had apparently read a few magazine articles and was therefore (at least in his own mind) competent to dictate the architecture and implementation details. Unfortunately, he was unable to articulate his requirements in any way.

I mentioned I would probably use Perl in developing the GUI for his low-bandwidth, not mission-critical analytical tool, and he dismissed Perl as being unable to produce a tool sufficiently flexible for his purposes, which made me laugh.

Ultimately, however people perceive Perl, it is hard to argue with this basic fact: Perl gets stuff done. Whenever I find someone who is skeptical about using Perl to solve a problem, I ask them to give me a trial period of a week or so. I've never found anyone who thought I should switch to some other, buzzword-compliant technology, once they saw how responsive and adaptable I can be when delivering solutions in Perl.

I think it is also a little melodramatic to talk of people being fired for choosing a technology that is not buzzword-compliant. I've never seen anyone fired except for being a jerk or betraying their company's interest in a public way -- mostly we're talking about the possibility of missing a promotion because you take a risk and fail. Or perhaps I've only worked at companies that expect and forgive a certain level of risk-taking and failure. Personally, I'd rather try to do what is best for my employer (even if it means I might fail) than choose a 'safe' solution out of cowardice or personal greed.

[perrin]

Your idea that the number of choices on CPAN is what's holding Perl back doesn't seem supported by comparison to other languages. Java has about a million choices for doing anything (witness the ongoing web framework wars), and it's doing quite well. And for the record, most of the experienced PHP users I know use a templating tool like Smarty.

You may have a point about the TMTOWTDI aspect of the language itself. I'll be touching on some of this, and discussing ways to minimize risk in perl code at OSCON later this month.

[jimt]

I think one of the key words there is "experienced" - most of the experienced PHP users I know use a templating tool. And that's cool - let the more experienced users use a different tool. But that doesn't change the fact that to the beginner, PHP itself is the way to go.

So our little newbie starts off just using PHP as the way to do things because it seems obvious that that's the way to go. Then they get more experienced and switch to something else.

That approach is probably what I'm advocating more than anything else. Some way to consistently say that when you're starting out and need a persistence layer that DBIx::Class (or whatever) is the way to go. So that's the out of the box solution that the new person knows is safe to try, and later on they learn what they're doing and can more easily switch to something else.

That way, people approaching the language can see that there's a widely considered "good" (if not "best") way to do things that they should look at first, and after they've actually learned how to use the language and are comfortable with things they can start evaluating other solutions AND make a wiser decision as well.

Otherwise, the neophyte will need to learn the language and then figure out which approaches to take, which modules to use, which decisions are good. It adds complexity and risk and that's what I think we need to help alleviate.

[perrin]

I'm not sure a real newbie needs a persistence layer at all. They should probably use DBI directly. But regardless, I still don't think that too much choice has been shown to be a significant problem for language acceptance, as evidenced by Java. The language with the fewest choices is probably Ruby, and it is currently way below all of its competitors in terms of jobs and popularity (though not in buzz).

I think too much choice is more annoying for people like us, who already know that we want a good perl persistence layer and don't want to wade through CPAN looking for it. The solution for that is a combination of community (CPAN ratings, mailing lists, PerlMonks) and building expertise at identifying good modules. There's no simple answer for it because the question "What do you want from a persistence layer?" is pretty complex.

[ForgotPasswordAgain]

I ++ you for obviously putting a lot of thought into it, but I have to argue with a lot of what you say.

First I'd like to make a clarification. You seem to compare on one hand the whole Perl language with on the other hand specific solutions in other languages. PHP is a hypertext preprocessor. Ruby on Rails is for creating web applications. Java is a general-purpose language, but its web solutions are as myriad as Perl's and at least as complex and confusing (in true enterprise spirit).

I think it boils down to corporations (well, everyone) wanting to minimize risk

Then those corporations can contribute to creating their own solutions. Some of them may even be wildly successful and become a canonical solution.

TIMTOWTDI is fun and all ... all of these myriad solutions create confusion in newbies that they wouldn't have elsewhere.

Newbies will be confused in any case because they're newbies.

And there are myriad problems. You want there to be one problem that you can solve with The Solution, but there isn't.

PHP has The Solution. Perl has many solutions, advocated by different people for different things. They're supported differently. They may fade away and be replaced. You could make the wrong choice.

It may seem right now that PHP has The Solution, but I think you're wrong. The Problem is not a single unchanging thing. For example, how do you do "AJAX" in PHP? I don't know, and maybe there are good solutions now, but I'd bet that three years ago there weren't any The Solutions for it. There might not even be a good solution in Perl, but I doubt that trying to solve every possible problem with The Solution is going to lead to a good solution.

Similarly I think that in five years Ruby on Rails will start to seem creeky. It's all the rage now, but the problem space will change, people will want different features. Ruby on Rails, and these kinds of The Solutions, will be unable to adapt; they require you to conform to a predetermined set of conventions. There was an article I read recently in some Linux magazine which went on about how "constraint equals freedom", referring to how the conventions in Ruby on Rails let you worry about other things. The problem with this, I think, is that you can't rely on other people to know what your problems are and will be in the future. And when you need to come up with a better solution for something, you don't have a good foundation on which to build it.

Say you want to create a new class to store some data. Ruby is easy. Just define your class and you're done. Perl makes you worry about blessed hashes or arrays or scalars or coderefs or inside out objects or whatever else. You could choose wrong. This is a fundamental basic part of the language that you could potentially screw up and make your life miserable about later on.

I don't agree that it's fundamental. If you want a safe solution, you bless hashes. With Ruby, according to what you're saying (I have no idea), you apparently don't even have an option. I'm not sure why this is better.

I went to one of the talks on inside out objects at YAPC this year and it was a good show. But I was also sitting there thinking, "I shouldn't need to care about this stuff."

You don't. There are other solutions. You can wait for a couple years, see if the inside-out objects fad pans out, then start using it if it turns out to be all that and a bag of potato chips.

You also don't have to stay with Perl. It may be that it's doomed as far as web development goes. If that's what you do and what you think about it, why stick with Perl? There are apparently already solutions to your problems. Why are you reinventing those wheels in Perl?

Maybe it's a documentation and community issue. Maybe introducing users to simply blessing hashrefs as objects is the right approach and having a footnote that it can actually be anything and they can read more at XXX is all it would take.

I'm not sure where you got the impression that things were otherwise. You go to Perl conferences, so yes you're aware of the more advanced object-oriented techniques, but most books and the perldocs like perlboot and perltoot use hashes. Maybe you're basing things on one specific books, "Perl Best Practices"? I personally don't agree that inside-out objects are a best practice. They seemed more like "something Damian thought was cool at the time".

Perl's flexibility is one of its greatest strengths, but it also makes it pretty scary to new users. So how can we minimize risk for them and make them feel comfortable that they're making safe choices?

I don't think we can. They're newbies. They're going to make catastrophically bad choices due to their lack of experience.

I don't need to go out and buy a book to know how to do templating in PHP, and I shouldn't need to buy one for Perl, either.

Like I said above, I think you're comparing apples and oranges. Perl is a general-purpose programming language. PHP is made for preprocessing HTML.

I also disagree that you won't have to do a lot of hard reading to be able to do templating well in PHP. Yes, you can slop something together, no problem, but you can (and many people do) do the very same thing in Perl. You can't just download a training program into your brain like they do in The Matrix.

The community is also right out. People bicker and argue and have different opinions. Let everyone who uses perl put their two cents in towards defining The Solution(s), but have a clear list of what those recommended solutions are

There will never be such a list unless a dictator comes out and demands that everyone else accept their list as the canonical one. Everyone else won't. You want to put Catalyst on the list? Why not the replacement that its former lead developer forked off? Why not Jifty? Why not recommend more common low-level modules like HTML::Mason, Template::Toolkit, HTML::Template? You want to put XML::LibXML on the list? Why not XML::Twig, XML::etc... Want DBI? Why not DBIx::whatever or Class::whatever?

Now if you wanted to assemble a big matrix comparing all the options, explaining their relative strengths, features, weaknesses, that'd be great.

Well, I'm getting tired and have work to do, so I hope that didn't come off as trollish. Good luck.

[eric256]

"Maybe you'll choose PHP. Templating there is easy. It's just...well...PHP" The reason PHP is popular is because it is so easy to do web apps. Thats great. The reason I wont do any more projects in it is because it is a bad template engine that encourages bad code design and makes it hard if not occasionaly impossible to break out of the "PHP is the template engine" whole. It would be like if formats where the only way to do formating in perl, it would be great if what you wanted fit in that model, but it will suck when you need something more or something less.

There are pro's and cons to having the One Right Way. The perl community as a whole seems to have decided that for most cases there isn't One Right Way. Sometimes we go the other way though, witness DBI if you doubt it. If you need a language that has one way and when things go wrong you can point and say "well they told me this was the best way" then please by all means use a different language. I for one am getting tired of finger pointing and ass covering. Either make a choice, go out on a limb, experiment, take risks and be intelligent, or go home, but don't try to make Perl into the next PHP.

Does that sound eletist and arogant? Maybe, but I think that sometimes people should take a stand and say they are right. Maybe I'm wrong, but I'm at least willing to make my own choice and stand by it. I'll be happy to even admit failure when wrong and come up with a new solution and adapt. You'd be surprised at how often being honest and true works out better than just following the sheep.

[zentara]

I've generally stayed out of these "perl is dying" threads because I see it as a troll. Sure Perl5 is dying, but we are all dying.... so what? Should your boss fire you because he knows you are dying? You might counter with,,, "yeah but it's still 50 years away", and I'm still very useful right now. What counts is what can you do while you are still alive.

Perl5 is still very much alive, and will die eventually and reincarnate as Perl6..... then we will all have that youthful zest and the belief that it will all go on forever.... but even Perl6 will die one day.

Maybe its just my take on it, but it seems that most of the criticism of Perl5 is that it is too difficult to easily produce high-performance web applications. To me, the web is just a sideshow. Plain old Perl5, with maybe FastCGI, is good enough for almost all the web work out there. If you need more speed, it's cheaper to add more hardware, than it is to learn another language.

As far as "corporate acceptance" goes, thats a crock of crap. From what I've seen, corporations are interested in one thing.... making it cheaper, not neccessarily better. So if Java, Net, and Ruby on Rails can make these homogenized web pages cheaper, allowing them to reduce their staff sizes( or outsource), that's their business. but I'm not giving up my favorite tool because of that.

So the next time you lament the lack of programming jobs, and the increasingly homogenous look-and-feel of the web, just remember.... you asked for it....it's the efficient economical Solution.

[phaylon]

++ on this.

In the, about, last six months or so I heard "Perl has too many choices" from many sides. And I say "No, damnit!" Primarily, I don't care about language popularity. I care about the job that has to be done, and which I'm using a language for. If popularity would influence this positively, I'd care for sure. But I just can't see any advantage over what Perl already has. It is mature, has a large and experienced userbase. And it has a code library behind it with solutions to over a decade of problems people encountered.

I know, and experience every day, the FUD that's spread around Perl in the world. That it's slow, old, ugly, write-only, and all the other stuff that is told by people who most of the time never worked with Perl beyond a CGI script that was written badly in the first place. And a big bunch of those people seem to only be able to argue through mockings and invalid claims.

To be honest, I don't think you could even convince those people even to evaluate what they are saying. It's not what they want. They don't want to know how good or bad Perl is, they just want to state that "at least their script doesn't look as ugly as PERL".

Concerning the beginners and the choices: As someone absolutely correct stated above, beginners *will* be confused. The outscream that Perl has too many choices says, in my opinion, more about the complainer than about Perl. There he has five to ten modules in the same problem-area, which give him different solutions. Even if there were only one module, that doesn't say it's the right thing for the job, or that it couldn't be done "better." After all, there must be reasons people start new modules in already cpan-covered problem-spaces.

Nailing down your problems, the frames of your project, the goals, the risks, the priorities and finding the best fitting solution, in short- and long-term is nothing anyone else can do for you. It's a fundamental part of software development. In my opinion, stuff like CRUD is partly used by the wrong people. It should be a shortcut on your way, a way you know, a way you have planned. It should not be a try to hide the programming part of programming. In my opinion, CRUD should only be used by people who know what they're doing.

So rather than ranting "Awwww, there's more than one module for my job! Now I actually have to look at them, read documentations and stuff!", people should start being glad that they have this. CPAN is more than a library for code, it's a library of experiences. Good ones and bad ones, but nonetheless, it's there for everyone who seeks it.

Ok, this got a bit longer. Just regard it as a very long and loud scream into a pillow :)

Update: Corrected some typos

[rob_au]

This approach and philosophy was manifest within the Perl5 Enterprise (P5EE) project some time ago - See the web pages http://p5ee.perl.org/ and http://www.officevision.com/pub/p5ee/ for details. This project however did not progress further than some initial architecture designs which were then followed through with a relatively alpha implementation that did not address some of the core goals of the project.

I mention this as it may be worthwhile to review past endeavours in this space to prevent making similar mistakes.

[Mutant]

I don't agree that the diversity of CPAN is a drawback of Perl. On a slight tangent to this discussion, one thing I would like to see is a better organisation of CPAN. e.g. if I want a web-based templating system, I'd like to be able to browse through some categories, drill down into web, and find a list of templating systems that might suit my needs. If it was linked into ratings, reviews, annotations, etc. even better.

In case there's already a site that does this (it wouldn't suprise me), I'd like to add that this functionality should be built into CPAN, so that it's something people will use automatically, rather than after they've been playing around with CPAN for a few months, and managed to find a link somewhere, or ask the right question on PM. The categories, etc. would also need to be maintainable by people other than just the module authors.

As I said, I think varied options in modules is a strength of Perl, and is something many other languages have (actually, Perl is one of the most diverse in this area). I just think this strength needs to be taken full advantage of.

[talexb]

Say you want to create a simple dynamic website. Maybe you'll choose PHP. Templating there is easy. It's just...well...PHP. Or you could use Perl and choose Mason or CGI.pm or Template::Toolkit or Catalyst or HTML::Template or Template.pm or Text::Template or god knows what else. Your risk has now increased dramatically over PHP. ...

Huh?

It seems that you're equating more choice with more risk. How does that work?

If I have more choice, then I pick the solution that works best for me. Some time ago, my colleague and I looked at templating systems you mentioned, decided on one of them, and went ahead. The solution we chose (Template::Toolkit) works absolutely fine for us. And I'm currently investigating Catalyst (and therefore DBIx::Class as well) and CGI::Application for future projects. I'm glad there are choices -- I'd hate to be stuck in the mid-90's, doing print statements inside a Perl Module for mod_perl.

The community is also right out. People bicker and argue and have different opinions. Let everyone who uses perl (sic) put their two cents in towards defining The Solution(s), but have a clear list of what those recommended solutions are so the n00bs don't ignore us in favor of somebody else.

Sure, there's a lot of discussion in the perl community. Should we all keep our mouths shut? Not much is going to get done if we're not allowed to discuss things. And if you're looking for a single solution for every possible programming challenge under the sun, I'd have to say it doesn't exist.

However, Perl can address many programming situations, and it continues to have a great community backing it up. What problem are you trying to solve?

[duff]

Your The Solution is on its way in the form of Perl6. :-) Really.

[spiritway]

[id://jimt], ++ for a well-written and reasonable post. As others have noted, you've apparently given this topic considerable thought. Still, I disagree with many of your comments.

For one thing, I disagree that Perl is endangered, or that it "needs" this or that. And especially I disagree that it should morph into something else, something closer to PHP. Perl is Perl - that's what it is. What you're saying sounds much like the schoolyard logic - if you will be someone different from who you are, kids will like you better. Maybe so - but that's not who you are. Are you really better off if more people like who you pretend to be?

To my understanding, Perl was designed to offer a great number of solutions - TIMTOWTDI is not a bug or a fluke, it is built in deliberately from the ground up. It's a feature. Taking that out of Perl is like taking the caffeine out of coffee or something equally sinful. No decapitated coffee for me.

Your concerns about n00bs is, I believe, unwarranted. Maybe PHP is simpler to use; but is it as useful overall? If it is, I haven't seen it. How about Java? You think a newcomer would choose it over Perl? How much of a language do you need to know, to write a "Hello, World" program? How many lines of code would it take to do it? How many minutes or hours would you have to learn before you could do it? One of the things that helps attract a new user is how easy it is to begin writing useful (or at least, working) programs. But that won't keep them. As they grow, they'll want to get fancier. PHP won't offer much room to grow. Python and Ruby would, but they have their own learning curves.

I also disagree that Perl is in "trouble". It's not as though Perl were a corporation whose life depended on exceeding last year's quarterly profits. If lots of people decide not to use Perl, then ... well, fewer people will use Perl. There won't be any massive layoffs, no major corprate restructuring. The remaining people, including the volunteers who write and maintain Perl and its modules, will carry on - or they won't. At least, we each have a voice in the matter. If we want to contribute money or code, we can. I think there are enough people who believe in Perl to carry it, even if it is abandoned by the mainstream.

What you suggest - coming up with The Solution(s) - might attract newcomers; but have you considered the effect it might have on the old-timers, the people who have helped to make Perl what it is today? You could very well drive these people away, and that would be disastrous.

I think your objections are based on the perception that choice and disagreement are bad things. I .. uh, disagree. A respectful, reasoned disagreement and structured discussion of differences is, IMNSHO, a healthy thing that can result in great benefits. Sure, the Monks bicker here, sometimes. We get into deep, heated holy wars about how to capitalize Perl (or is it PERL, or perl?), as though all our code would evaporate if we got it wrong. But most of the time, the Monks are reasonable and thoughtful, the disagreements voiced inoffensively. I've learned at least as much from the "wrong" answers offered to a quesion, as from the "right" ones.

To be honest, I don't really believe there is any such thing as the "right" answer, except perhaps in some trivial cases. Much depends on what you are trying to accomplish. What is *usually* right may not always be right; it may be completely wrong for your particular use. By having the Monks present all kinds of choices - from the obvious to the subtle, from the ridiculous to the sublime - you learn many things, not just the exact answer to your question. One thing you might learn is how to make good choices. Having someone else tell you, via The Solution, might be comforting. But I believe it's better if you know how to make that choice yourself. Chances are that the programming problems you face will have some unique aspects to them, that won't always fit into pre-conceived formats. You'll need to have options available, know what those options are, and know why one is better in this case than another. To do this, you'll need to practice. And what better way to practice, than to read the posts here and try them out yourself?

Bottom line: I'd rather think for myself and accept the risks, than let someone else do my thinking, and be "safe".

[gloryhack]

If I were a "n00b" wondering if I was making the best choice from among the many options the Perl community provides, and had no clue how to make such a determination myself, I'd hope that someone would point me toward perlmonks.org.

Since I'm not a "n00b", I don't want other people thinking for me. I don't want someone telling me which modules to use. I don't want someone forcing his pet programming paradigm on me. For that matter, I don't want my professional judgment trumped by some groupthink suit dweeb who salivates over the flavor of the month in the trade rags.

"Best practices"... best for whom? Determined by whom? Determined *for* whom? As far as I'm concerned, the best practice is to well and truly know your craft and to always strive to be the very best at it.

Oh, yeah... </endrant>

Myself, I don't care what the corporate world thinks (regardless of the fact that think is far too generous a term for what it is that they do) about anything. I just do my job, and if Perl's the right tool, I use it. Most of the time, it is. If someone who controls my paycheck insists that I use something else, then that something else is the right tool for the job. I won't even argue the point. Life's too short already, I'm not going to waste any of it arguing myself into homelessness.

[TGI]

Modern western, especially American, culture is obsessed with choice. For years we have assumed that increased choice brings increased happiness and satisfaction. It turns out, that this may not be true.

Anyone who makes light of the real costs of CPAN confusion, should think again. CPAN is an amazing resource, but it lacks the sorts of filters it needs to make it quick and easy to evaluate competing tools. The various attempts to add annotation and ratings just don't seem to be catching up with the cornucopia CPAN offers.

I'm not sure I have a solution to offer. I am still formulating an understanding of the problem, and I am very glad that others are thinking along the same lines.

Resources like P5EE or POOP were great ideas, but they seem to have stagnated or died. I think we need some kind of module "moderation" system that is easy to use and community driven. POOP and P5EE seem to demonstrate that we can't rely on individuals to do all the work--we need a collective tool. CPAN has a ratings system, but it seems to be mostly unused? Why don't people rate CPAN distros? Can we use Perlmonks to rate modules?

Check out Barry Schwartz's list of publications for more sources on choice and satisfaction. His paper "Maximizing vs. Satisficing: Happiness is a Matter of Choice"(pdf) is a particularly interesting read.

All this being said, I don't think Perl is doomed or dying, I just think CPAN is getting past the point where it scales well--it's too hard to choose what to use. One or more of the many smart people in the community will come up with a solution. I hope these discussions can help move us toward a solution, rather than a decision to hang a bell 'round the cat's neck.

[samizdat]

I'm glad the PM community mostly agrees with me that this is a meditation worthy of reading. I don't agree with you, though, jimt, that the language needs whacking to become more like PHP. I do agree that the reputation and perception of Perl needs repair.

What I'd like to see is that you take the knowledge and experience you obviously have, and apply your passion to writing a book that describes the elegant and practical subset of TMTOWTDI and CPAN that will make bells ring deep and resonant notes in noobs, PHBs and Perl gurus alike. If you're afraid to go it alone, set up a mailing list or wiki devoted to such a discussion. This was a good start, but it's going to take a bit more than this to convince the whole worldwide Perl community to wear Prussian helmets and jackboots... or even Mercury's winged shoes. ;^D

[ww]

re OP's '...but I don't want to have 80 different ways to do things with no way to easily pick the "right" one, either.'

urge emphasis on '...but I don't want ...no way to easily pick the "right" one, either.' -- precisely for the reasons mentioned elsewhere, including, especially, the notion that absolute standardization discourages or prevents innovation, except in some other arena (for which read, some other language).

[Skeeve]

And I don't know how to fix this. It's a careful balancing act between being too strict and too flexible. I don't want to turn CPAN into PEAR, but I don't want to have 80 different ways to do things with no way to easily pick the "right" one, either.

Guess what: This is exactly how I view Java. But the downside of Java - in my view - is: You have to use these myriads of moduls to get your task done.

In Perl I see it like: I can use one of those modules, but I'm free to do it on my own. And it's almost always easy to do it on my own. In Java it will break my neck trying to do anything on my own.

So I don't think we need the Solution.

[davebaker]

jimt, I agree with you. We need more centralized information about the pros and cons of modules in the CPAN that are designed to do roughly the same thing. A professional programmer might enjoy, and be more efficient at, the process of evaluating each of the possible modules that solve roughly the same problem (e.g., templating), but a non-professional programmer like me really benefits when a more experienced or professional programmer provides some kind of overview.

Another commenter talked about a "matrix" -- that's the right idea.

An example of a very well-written matrix-like overview is perrin's wonderful article comparing templating systems. Oh for a dozen or two more like that one.