The $ , @ , % confuses people. I learned perl to maintain a script which contained " $$$foo ". Now it makes perfect sense (well maybe not the "foo" part which was the actual variable name) but at the time it was downright scary, that looks like it shouldn't even run. I still do PHP at work because they have a large code base but I plan to avoid it in the future. The following is a bit of a rant / ramble on why I've been turned away from PHP.

Issues I've had with PHP in the past have cost time because of re-writing already production code after a minor PHP version upgrade. As far as I know the PHP answer to a security bug is to upgrade to the newest release and all of it's changed functions. My employer has re-used PHP code across dozens of sites. The upgrade cycle is a pain. Right now I only recall a couple examples.

1. The mysql_connect() return value/type was changed so regexes on the result had to be modified. This was a small fix but a waste of time in my mind.
2. File uploads: $_FILES[...]['name'] changed in php 4.3.7 to not include the full path to the file on the browser side, even though some browsers pass it in. I couldn't find reference to this in the Changelog, our customer phoned when he noticed a problem. I replaced the PHP file with a perl CGI script.

Then there is the lack of namespace. I had created a form variable named 'file'. I accessed it via $_GET['file'] but that broke the site. The GET value overwrote the $GLOBALS['file'] array which held some paths used by the application. They look like they are different hash tables but there is shared data!

In fact if you change the variable $file you've just changed the $GLOBALS['file'] as well. PHP fans will tell you to turn off the "register globals" setting but that will break existing code which was written before register globals existed. Note that inside a function $file will not touch $GLOBALS['file']. It's only in the main body of your script this conflicts. While on functions the "function" keyword is like "sub" in perl but note it's not case sensitive. Oh and hand-in-hand with that the names of functions you write are not case sensitve either. That's important when grepping code trying to find a function.

PHP doesn't seem to have been build with modules in mind! You want zlib support? Recompile PHP. MySQL? Recompile. mcrypt? Recompile. GD graphics functions? Recompile. EXIF and PNG? Those are extra compiles too. TrueTypeFonts? Recompile. See the pattern here? Want to talk IMAP? Recompile.

I just checked one server and PHP's ./configure line is 1478 characters long. Yes PHP supports loading .so files but come on 'use foo;' is so nice. On that note if your admin doesn't have a Perl module installed you can just put the source in your cgi-bin directory and "use" it like normal.

On to error reporting. PHP has nothing like 'use strict;'. End of discussion. It's a pain. Also PHP has no way to declare a variable before using it. If you mistype a variable name it will be created for you. (The keyword 'var' is only used inside of classes AFAIK.) Oh that's not entirely true. Arrays can be defined with $foo = array(); which you should do because othewise foreach loops break in case you didn't have any data to push onto the array when you expected to. Please do note that error messages have improved very much since PHP 4.0.

Function names seem all over the place like these array functions. Some have a prefex, some don't: array_push, array_pop, array_keys, sort, count, key.

Compare this simple regex replace:

$foo =~ s/^abc//;
[download]

with the PHP version:

$foo = preg_replace('/^abc/', '', $foo, 1);
[download]

Don't forget the slashes are needed in that first function argument but not the second. I still don't know why. Good luck if you need to put backslashes in there because sometimes you need 2, 3 or 4 to escape it. I have backticked sed commands just to make regexes work in PHP.

I never do recall how to pass or return things by reference. You need & in a few places and I think maybe a \ somewhere. PHP5 has supposedly changed this anyway.