There are also significant historical issues, though, which may be more significant.

By its very nature, CGI is (relatively) slow, because it needs to fire up a new process to handle each incoming request. Back in The Early Days, Perl and CGI came to be nearly synonymous - an entanglement which persists to this day. (Some job boards don't even have plain "Perl" listings, only "Perl/CGI".)

mod_perl deals with this performance issue, of course, but that opens up a whole other can of worms in shared or managed hosting environments, because installing a new module (such as a mod_perl-based application) traditionally requires editing the apache configuration and you can't let all the end users have that power. So, on most sites, Perl was stuck with using slow CGI.

Then along comes PHP, which is not only mindlessly easy to code for, but it also only requires a single module - mod_php - to be installed and all your users can get the speed benefit of an in-process interpreter instead of having to fire up processes through CGI, without having to give them administrative control over the web server process. It's easy to see why it took off like a rocket.

IMO, if we want to see Perl make a comeback in the web application space, the association of "Perl = CGI = slow" is an even more important problem to overcome than any perceptions about ease of use.

It's a bit like Linux and Windows. Windows XP for sure wasn't technically superior, still it has a huge market share simply because everybody used windows, so it was the easier choice.

Why PHP is preferred over Perl nowadays for web development?.

Is it because PHP is easy to learn compared to Perl?.

But there is hope for Perl, to maybe beat PHP on its own territory: see the article CGI is Dead; mod_perlite is Alive! on perl.com.

PHP is only safer than mod_perl if you run it through CGI or certain configurations of FastCGI, which of course you could do with Perl too.

From a security perspective, sure, but it's my understanding that one user won't accidentally affect another with PHP, whereas it's trivial in mod_perl (e.g. two users with similarly named modules, a normally innocent change in one of many global variables, etc). Please correct me if this is incorrect.

I read the article, looked at their approach, and concluded that it was almost useless. If, for instance, you have a database backed site, the prime cost of CGI is in initializing code and connecting to the database. The approach that mod_perlite takes does nothing to help with those costs.

I'm not a PHP fan at all but I feel that the fact mod_php is basically the only thing you need to do a php 'hello world' in your basic apache installation is one of the reason why people who start web programming go for php.

Maybe one day mod_perl + HTML::Mason will also be part of a default apache setup. A few years ago, this was a bit painful to install while installing php was as simple as yum/apt .. mod_php .

If you want to advocate perl withing your organisation, show something cool you can do in no time. And regarding web development, I think HTML::Mason can give you great satisfaction pretty quickly.

Cheers !

Those that don't have root control over their server need to have perl available in the public directory, which a few years ago was more rare. Now it's pretty easy to find.

I think PHP came into vogue because one could put it in with the HTML to make it interactive/responsive, but I simply create a file called index.pl and distribute/create everything from that script. It gives me total flexibility and interactivity and there's nothing I need from PHP that I can't do with Perl.

Update: I also make use of redistribution by .htaccess which adds to the flexibility on offer.

It's a question I wrestled with recently.

I've used Perl for a longer time than PHP and I like it more. I don't enjoy coding in PHP and neither do I enjoy reading others' PHP code. It's easy to mix PHP code with html and as a resul a lot of PHP code out there is a pain to read (OsCommerce comes to mind).

With Perl, I'm more disciplined and use a templating system to separate Perl code from html. You can do that too with PHP with the aid of a module but because it's easy to include html in PHP code, people tend to fall into this habit (at least I do).

But (I hope I'm wrong here) most stuff I've come across on the Internet seems to suggest that PHP is faster as a web scripting language than Perl - for reasons cited in the comments above. So it's a hard decision to make. I would choose Perl because it's a much more powerful language yet PHP comes across as the natural choice for the web in terms of speed.

I'm curious to hear from anyone who's used Perl on a moderate to heavy traffic interactive site (with MySQL or similar) without using mod_perl - just Perl CGI (vanilla Perl, or whatever it's called). Is the site able to support say 100 users simultaneously?

All languages are different. There are no better languages to code in. Languages have strengths and weaknesses.
The clear choice to use perl or php to backend a site, is the coder.

I went from mainly php to perl 5 years ago.
The vast majority of my work in perl has nothing to do with the web. But when so, I use CGI::Application.

If you choose perl to develop some web trinket- and must present a case. Learn CGI::Application. Take a seat on your workstation and put a php coder in another. See who can code this faster:
Allow use login, allow file upload, allow searching for files.

That will be the end of discussion.

However, this is unjust. Possibly cruel.

Hear hear! I donned the flame-retardant suit before clicking on this node, and was I ever surprised. Not only is Perl the language amazing, the culture is second to none.

One of the things I think has hurt Perl in relation to PHP is database support. Not that Perl has bad database support once you install the DBI modules, but you do have to install the DBI modules. They don't come with Perl.

PHP on the other hand has a mysql library built in, for all intents and purposes. Basically if you can use PHP, you can use a database as part of your LAMP stack. Perl... DBD::Mysql is buggy to install: When it works, it works well, but when it doesn't it can take weeks to get running. (If you can get it running at all.)

I'd love to see DBI and say, DBD::SQLite installed as part of the standard Perl install. That would satisfy 80% of the website database uses, as well as providing an easy upgrade path to more full-featured databases. (And would actually require less setup on the part of the webhost, in many cases.)

Really? I've never run across a vendor distribution of Perl (on multiple Linuxes and a couple versions of OS X) which doesn't include DBI, so I've always assumed it was part of the Perl core.

This is also a two-edged sword, in that PHP traditionally hasn't had anything equivalent to DBI, only database-specific interfaces. So if you wrote your app for MySQL and wanted to switch to PostgreSQL, you'd basically have to rewrite the whole thing if it was in PHP, while most of the transition in Perl would just be a matter of connecting to a different DBD driver (assuming you stuck with vanilla SQL instead of using lots of queries that call non-standard MySQL extensions, of course).

But, yeah, I agree that DBI and DBD::SQLite should be standard if they aren't already.

DBI and various DBD modules have never been core, and probably never will, simply because there's no real benefit to it. It's much work to maintain many core modules, so the plan is to actually remove everything from core that's not needed to run perl, or install other modules.

The philosophy is more that a plain core perl isn't all that useful for many tasks, so it should be distributed with helpful modules from CPAN. So the distributors have a choice, and many make use of that choice (for example the last time I used ActiveState Perl, it came with non-core modules installed by default).

Or to put it differently - there's no good reason to connect default installation with core (where core = "maintained by p5p in the perl repository")

The problem that I encountered was trying to find the appropriate Oracle DBI Driver for Perl on Windows.

Having DBI without the necessary drivers doesn't do one much good.

I'll give you two points of view that you can include it, I started with Perl for more than 10 years since the beginning the problem was the documentation, my native language is not English and understand things in complicated technical English is by far a terrible headache, the documentation is only in technical English as well as books :-(, there are concepts that after several years I realized what it meant.

On the other hand PHP is a language designed for web, where every day they incorporate more and more modules in their official API?, Instead this Perl replace, or we replace, it with CPAN and CPAN is the union of several single individual developers and this is prone to have errors, how many times you wanted to do something fast and you lose 10 hours by a bug in some package that wasn't documented or poorly documented.

Please don't confuse, i don't said that CPAN is bad, not please, i said that PHP has oficial "modules" with more control becouse in general they use an inplementation of popular software with several years in the market

Exists to much to discuss, but I consider important it, because Perl6 follows the same line :-(.

Cheers!.

I'm not bashing and didn't -- you, I just want to say that I had to plumb a couple of PEAR packages in the last year and the code was below the level of robustness and thoughtfulness that most of the mainstream/popular CPAN packages boast. The code was naïve: it was fine as long as everything worked exactly as expected and the environment had no surprises, otherwise it failed with a total lack of diagnostic information. If I weren't an experienced developer I would have spent a couple weeks trying to debug stupid problems with environment or databases with which the code, as published, was no help whatsoever in exploring.

Your comparison also isn't quite right. Perl ships with dozens of core modules, on the CPAN, which would be considered "official." These cover a huge range of purposes and at least a few date back to when PHP still stood for "personal home page."

I'm aware there are hundreds of shoddy modules on the CPAN. It's because it's not several, it's several hundred authors. Amidst the trash you can get a handful of first rate ORMs, XML parsers, HTML handlers, templating engines, servers, etc, etc, etc, etc… Solid, excellent, portable software. Not toys which rely on a set of expectations or a known installation environment. I'm not a PHP dev but from what little I've had to step into it, I'd say the CPAN is vastly superior, both in range -- which no one can argue -- and in quality of what's available if you know how to find it -- which can mean who to ask for help. PerlMonks has been here for 10 years, for example, and is quite international and friendly to ESLers. :)

Just an small comment to don't misunderstand my opinion, i'm not talking about difference between PEAR and CPAN, is really imposible compare one to another, becouse CPAN have a lot years of great contributions and 15228 modules today!! against 528!! of PEAR...

I'm talking about the built-in function/modules that make PHP more easy and functional to use without error, it self, or at least with less error, in fact this made the difference between a web lenguage, worst or better i don't know, and a multi purpouse language like Perl.

But by far the documentation is the great difference just put www.php.net/thecommandtoseethedocumentation and you can see a brief and useful description in your language with several, no good but useful too, comment below, i don't know for me is an advantage

And yes like Your Mother said, Perl is better has many resource of search information, modules and you can find help like Perlmonks, but instead it, PHP grow up much faster, why? becouse is more easy and is focus in certain point, web developement, i guess.