|There's more than one way to do things|
Perl needs The Solutionby jimt (Chaplain)
|on Jul 18, 2006 at 21:33 UTC||Need Help??|
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.