Unfortunately, I don't think corporate support can do much about the decline in market share of Perl usage for dynamic sites. I read (was it netcraft?) that php gaining market share at Perl's expense, and I believe it.

When I started programming Perl just over a year ago, I fell in love with it. I am realistic enough however to see its flaws. The sad truth is that if a beginning web developer has to choose between two languages, the first experiences are the ones that count. You can do 99 things right, but if one little thing is wrong, you move on. I'll share some of my experiences.

Speed I own a pentium-83 (megahertz, that is), running linux, php, apache, mysql, mod-perl, etc. Speed differences are very obvious. I created a small dynamic page. I made equivalent php and Perl-cgi pages. The php-page ran approximately 18 times faster than the Perl-page, which was of course due to the latency caused by starting perl.

Being very much in love with Perl, I was determined to speed up my script using mod-perl. First I used the Registry handler, which reduced the speed difference to a factor 10 (in favor of php). Still disappointed, I wrote a handler. Finally, my Perl-script ran about 10% faster than the php-script.

Now the Perl-version was compiled, optimized, etc, while php was interpreted.

Ease While converting the script to an apache handler, I opened another can of worms. If you want to know why, read the documentation for installing and running mod-perl programs. Local variables becoming global is one of the pitfalls. Basically, you have to design programs in a different way if you want to benefit from the speed. If your deadline is yesterday...

Paths So simple, yet so painful. Php allows you to include a file in your script, and so does Perl. This is used to store a global configuration, like database names, hosts, names, etc. Now if you run scripts inside a handler, the script path is no longer the directory the script resides in, but some root (document? file system? It has been a while). So in a 'require once' you must now put the full path name to the configuration. Now this is fine for custom-built software for one-time use, but not for software that you want to distrute. You simply don't want to instruct users to modify the main part of your script. Big big turnoff.

Maintenance If you want to benefit from the speed Perl offer, Perl allows you to tap right into apache. Handler scripts get compiled and run inside apache, resulting in a blazing performance. The downside is that you also need rather direct access to the web server (its configuration files), and if you want to update your script you need to restart the web server. This is fine for dedicated web servers/farms like Slashdot, or amazon where there is only one user, but this is a no-no for web-hosting companies with hundreds of users. If web-hosters allow you to run Perl, you will likely get the horribly slow cgi.

Conclusion I am sure there are solutions for all of these problems. I have not looked for long. But I think I should not. If you turn off your users the first time they use your product, it does not mean that your users are not trying hard enough. It means that either your product still has a long way to go, or, if you are convinced that your product is the very best there is, that you don't understand your users.

Future? The question is of course whether we want perl to be as popular as php. Being popular has never been a goal for Perl, but rather a consequence. I think Perl definately has a place in web-world, for high-performance, dedicated sites. What makes Perl well-suited for this job makes it hard to use for the average user. This is not a bad thing, because power-users will still find their way to all the good things Perl (and mod-perl in particular) has to offer. Keep in mind too that php was heavily tuned for the web, whereas Perl is just good at many things. Perl may be the swiss army knife of programming, but I only use the saw on my own swiss army knife for cutting bread.

To come back to the original article: will corporate backing help? Actually, I think that Activestate has been doing an awesome job. If Perl really wants corporate support, simply follow the money trail: web-hosters and high-profile sites.

Web-hosters will be only be interested if it means fewer headaches instead of more, so zero security concerns serving hundreds of users with an out-of-the-box installation.

Developers want frameworks like Mason with no installation issues and they want to be able to use it on any webhost without access to the server configuration.

High-profile sites are only interested if they are convinced that it is the cheapest option for them in the long run. In that area you are directly competing with MS's C# and the rest of the .net framework and Java (IBM & Sun). Believe me: free lunches can be *very* convincing.

---

---

• 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.