PHP is a weakly-typed language by design, not because they haven't gotten around to implementing type checking yet. If you're feeling insecure about your code, you can always explicitly typecast [php.net] your variables or use the settype [php.net] function to calm your nerves.

I've been using PHP extensively for years now and I can't say I've ever run into a problem with its handling of data types. Let's not forget that PHP is, after all, a scripting language.

A test run of our PHP setup on PHP5 RC1 seems to be more responsive and crisp than it was on PHP4.

Riiight. "Crisp". Yeah, that sounds like a very analytical test run you did. Did you also notice PHP5's woody undertones and how it satisfies the spirit without weighing down the heart?

Although you might be kidding (since /. has an established base of well-tweaked high quality/high performance Perl code), not only is PHP and in particular PHP5 is an excellent choice for prototyping because of the integration between display and function, but it's probably the right choice most of the time for people who are seeking to integrate databases with web functionality without delving into high-priced solutions.

/. is in a special situation due to the amount of traffic it receives, and the amount of effort that has gone into making Slash the powerhouse that it is has no doubt driven projects like perl_mod to increase the efficiency on the webserver side. While PHP would only improve on the appearance and capability to add user functionality, there would be issues with stability.

PHP is very fast and easy to use. The php.net website has great documentation. With the PEAR extension database abstraction is possible making all your data functions totally portable. As for quick hacks php can be run on the command line which is very quick and very hackey. I have been using it for years in tandem with MySQL and find that it meets all my needs (except for the fact that MySQL doesn't have nested queries but that is coming in the next release and I will be a happy man!) I also know JSP and Oracle but prefer PHP/MySQL by far.

Speed: they're all "fast enough." All of these scale well enough that for most sites you won't care, and none of them really scale well enough to support something like cnn.com. [Read through the archives to get a feel for the pain /. has to go through to serve its audience, for instance. And /. isn't even THAT big.] No flame; just that all these options are low/middle end.

Ease of use:

Classic ASP is pretty close to Perl. ASP.NET is a rather different paradigm, with a slightly steeper learning curve but more than enough added power to make it worthwhile. Unfortunately ASP.NET is a classic "leaky abstraction;" it tries to make things simple that sometimes aren't, and this will bite you.

Perl: it's nearly impossible to maintain a substantial site in perl with multiple developers working on the code. The language works against you here. Again, /. is a case in point. There's a reason /. doesn't upgrade to the latest & greatest very often.

JSP: takes a PHP-ish approach but Java is a statically typed language which makes using it for web apps _extremely_ verbose in comparison to the other languages here.

Javascript: poor fit for server-side use. Nobody does anything serious with it that way.

Verdict: They all suck to one degree or another. It's heresy on /. I know, but of these, ASP.NET is probably the best choice. If you want a toolkit/language that won't make site maintenance hell, OpenACS (tcl) or Zope (python) is probably a better bet. If you want something that will scale to absolutely huge levels (like the aforementioned CNN), J2EE is about the only game in town. (But a living hell to code for -- not recommended for smaller projects!)

If you put a site together with a little planning and a properly setup cache [sourceforge.net] and then use a template engine [php.net] that supports output caching you can rival static pages depending on how often the page "needs" to hit the DB.

This really all depends on the sites content, an average ecommerce site probably only needs to hit the database once a day, slash on the other hand could cache the front page for non-logged in users for 5 minutes, which I believe they are doing now with perl.

As usual YMMV.

the semantics regarding object assignment have changed from copy to reference

Sounds to me like the migration to PHP 5 will be a long and painful one. The project I've been working on in PHP for the last couple of years sure could use some of the new features, and if what another poster said about responsiveness translates to higher speed, that's another reason to switch. Then again, looking through megs of PHP code for things that are suddenly ever so slightly broken because of subtle language changes is not exactly fun.

For new projects, OTOH, I don't see much reason to stick with PHP 4, except the horrors of having to instruct users that they need to upgrade their PHP interpreter(s) again.

All of the XML stuff has changed as well, I found that out while going through the Core PHP, which has been *cough* updated *cough* to cover PHP5. They forgot to mention that they were talking August 2003 PHP5, AKA PHP5 before libxml2.

The nice thing is that it nearly completely models the functions listed in the w3c recomendation for the DOM Level 3 Core [w3.org], which are also nearly identical to the XML::LibXML module in Perl.

So, IHMO PHP5 = Good, Core PHP 3ed = Bad!

You have to use the pre-fork MPM, which is the same condition you'll have when using various modules with mod_perl. Basically, PHP core is thread-safe, but you're likely to use some extensions in your own configuration, and these aren't necessarily thread-safe.

I'm not aware of a list of "who's safe", but such a thing would be nice.

Yes, I've run php5 and php4 on the same box for almost a year. There are a handful of howto's for running two modules under apache, for examplea quickl Google gives me: www.schlitt.info/applications/blog/archives/83_How _to_run_PHP4_and_PHP_5_parallel.html [schlitt.info]

PHP has a smaller syntactical (is that a word?) footprint. As you said that you manage a development team, this is important. The Perl motto of "There's more than one way to do it" becomes an issue when you've got multiple developers working on the same codebase. You can write and (attempt to) enforce code style rules in your organization, which mitigates this a little bit, but it takes time to write those guidelines, get buy-in, and enforce.

I use perl often, but I consider it a "fire and forget" language. I use it for sysAdmin type work often, when I'm doing something once, and want to write a quick script that nobody (including me) will ever lay eyes on again. For real development, where I'm trying to create a maintainable piece of software, with input from other developers, I stick to PHP.

Well, if you rose from the ranks, then you should be able to perform a simple test:

1. Think of a task that will take about 20 minutes to program
2. Program it in both Perl (use perldoc as another poster suggested) and PHP (use php.net/manual/en [php.net])
3. Wait 2 weeks
4. Attempt to add a simple feature to each script. Time yourself and compare
5. ???
6. Profit!

When I go back and look at my Perl scripts I wrote a couple weeks ago, it takes me a while to get my head back into the script. With PHP, the code is always straight forward. It may be more verbose, but I understand it much more quickly than my Perl.

Besides this, I've found PHP's documentation to be far superior to any other languages'. When I do web programming, give me PHP anyday.

The only thing Perl has over PHP in my mind is that CPAN [cpan.org] is currently far superior to PEAR [php.net]. If you need many special libraries, you may want to consider Perl.

</ramble>

http://php.net/mbstring [php.net]