While you and I might be very comfortable plucking the good stuff from CPAN (or rolling our own) there is a large number of would-be Perl users that are intimidated by the vast number of options.

They come from many different paths, but certainly one of the most common is the group that comes to Perl in need of server-side interactivity for their AJAX/Flash/Email form or similar.

Reading the Perl literature (and lore) you can see that we like to brag that Perl makes easy things easy, and hard things possible. We say things like "Perl lets you start out talking baby-speak." However in order to get up-and-running with something as simple as a JSON-aware guestbook backend for an AJAX website we have to understand many things:

• User permissions and paths for installing modules from CPAN.
• What CPAN is in the first place.
• Which JSON module do I choose?
• Which CGI modules do I choose? (Remember this is probably on a shared-hosting account.)
• What does "500 server error" mean?

Otherwise the would-be-Perl-user just runs off to $OtherLanguage and remembers Perl only as a difficult-to-use, impossible-to-understand language from the 1990's. Next time they want to do something interesting (i.e. image-thumbnails on the server, with filters or other effects) they will remember what a PITA Perl was that first time around and go with $OtherLanguage like last time. Even if $OtherLanguage doesn't have CPAN and the awesome library of tools, they somehow feel Perl is opaque, intimidating and out of reach.

When the person needs to pay rent (not "take risks") they will search Google and go with the first tutorial they find that works for them. Hand-holding is great when you are trying to learn (and pay your rent at the same time).

Although Ruby and PHP are technically inferior to Perl in several ways, they are very popular with newcomers because they are easy to get started with.

I think that if there were a kind of "Training Wheels Perl" environment that included the kinds of things people are doing with Ruby and PHP without too much pain, we would see Perl begin to gain in popularity with the newcomers. Perl could lose that "Difficult" image it has picked up.

I remember a while back, listening to a guy laugh out loud, "Oh no, we won't be using Perl for this (haha) no way. Those guys have got to have 10 pound brains just to understand it! No! (hahaha) We'll be using PHP. Perl is just way too complicated (hahaha)!" Perhaps a bit extreme, but that's the consensus.

Sure, maybe it's just marketing, but I know what I'm doing and it still takes me a few hours to go from a fresh install of CentOS/RHEL/Ubuntu/Fedora/whatever to a working server with the following installed:

• Apache httpd2
• Apache libapreq2
• mod_perl2
• MySQL 5
• DBI
• GD
• Imager
• DBD::mysql
• Apache2::ASP
• Class::DBI::Lite
• JSON::XS
• Test::More
• Devel::Cover
• Devel::NYTProf

I've streamlined the process a great deal and it still takes a while. I can imagine what it takes for a newcomer to get up-and-running with some of the more advanced tools like Catalyst + Template::Toolkit + DBIx::Class.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.