Problems with PHP

1. There are thousands of symbols in the PHP namespace. Cleaner languages only have a few dozen. "Everything is built in" just means it has way too many functions in its core, especially since many are minor variations of each other.
2. No consistent naming convention is used. Some functions are verb_noun() and others are noun_verb(). Some are underscore_separated, while others are CamelCase or runtogether. Some are prefixed_byModuleName, and others use a module_suffix_scheme. Some use "to" and others use "2". And if you take a random set of ten library functions, chances are half a dozen different conventions will be included.
3. PHP tends to use a lot of similar functions, instead of just one, powerful one. For example, PHP has sort(), arsort(), asort(), ksort(), natsort(), natcasesort(), rsort(), usort(), array_multisort(), and uksort(). For comparison, Python covers the functionality of all of those with list.sort().
4. PHP includes lots of cruft or bloat. Do we really need a built-in str_rot13() function? Also, a lot of other built-ins are just trivial combinations of each other. Users don't really need case-insensitive variants of every string function, since there is already a strtolower().
5. Many parts of PHP either deviate from standards, or otherwise don't do what users would expect.
   For example, exec() returns the last line of text output from a program. Why not return the program's return value, like every other language does? And further, when would it ever be useful to get only the last line of output?
   Another example: PHP uses non-standard date format characters.

1. Functions cannot be redefined. If I want a set of includes which all use the same interface, I can only use one of them per page load -- there's no way to include a then call a.display() then include b and execute b.display(). I also cannot transparently wrap existing functions by renaming/replacing them.
2. Functions cannot be nested. (actually, they can, but it has the same effect as if they were not. All functions are global, period.)
3. Anonymous functions (lambda) don't exist. create_function() is not the same thing. Given two strings, it compiles them into code, binds the code to a new global function, and returns the new function name as a string.

   $foo = create_function('$x', 'echo "hello $x!";');
$bar = "\0lambda_1";
$bar("bar"); // sometimes prints "hello bar!", sometimes fails

   Note that the number after "\0lambda_" is not predictable. It starts at one and increments each time create_function is called. The number keeps incrementing as long as the web server process is running, and the counter is different in each server process. The memory for these new global functions is not freed, either, so you can easily run out of memory if you try to make lambdas in a loop.
4. Functions are case insensitive.

• ... is often incorrect or incomplete, and finding relevant information tends to require reading pages and pages of disorganized user-contributed notes (which are incorrect even more often) to find the details the documentation left out. Sometimes really important details are left out, such as "this function is deprecated -- use foo() instead".
• ... is (as of PHP 5.1.2) not included with the source, nor typically installed along with the binary packages. Downloadable documentation is available, but does not match the docs on PHP.net. Specifically, it leaves out all the user-contributed notes, which are important because of reasons mentioned above.
• ... is not built in. You can't just point an introspection tool at a PHP module and get usage information from it.

function FUNC() { return 3; }
$VAR = 3;
print func(); // produces "3"
print $var; // produces nothing

by CHR1S (694833) on Wednesday July 19, @07:37AM (#15742484)
(http://www.enragednet.org/)

How can it be that hard for web developers to check data before it is submitted? I wouldn't imagine trusting the data that an anonymous user can enter into my website.. so maybe I'm just trained to check data. Of course, I'm also glad I use MySQL with PHP where a simple mysql_real_escape_string can prevent any popular SQL Injection attempt.

by Goaway (82658) on Wednesday July 19, @07:41AM (#15742507)
(http://wakaba.c3.cx/)

You're glad that you use pretty much the only langauge where this is not done automatically for you, but which instead forces you to use a function with a name like mysql_real_escape_string()? And that actually has a similarly-named function without the "_real_" that doesn't do the job right? Just kidding with that other one, here's the real one!

Two different strings are equal... sometimes.
"1e1" == "10" => True
"1e1.0" == "10" => False
So, they're "equal and of the same type", right?
"1e1" === "10" => False

Unexpected results:
"1 two 3" == 1 => True
1.0 === 1 => False
"11111111111111111117" == "11111111111111111118" => False

Equality is (apparently) not transitive:
$a = "foo"; $b = 0; $c = "bar";
$a == $b => True
$b == $c => True
$a == $c => False

"22 cream puffs" == "22 bullfrogs" => False
"12 zombies" + "10 young ladies" + "bourbon" == "22 cream puffs" => True

"bourbon" - "scotch" => 0
"bourbon" == "scotch" => False

For example, this will fail sporadically: Open a file. Write to it. Close it. Open it. Read from the file. To make this actually work, the programmer must A) know it will fail, B) have some clue why it fails, and C) call the correct function (clearstatcache()) before re-opening the file. Note that the online docs aren't much help -- searching for "cache" takes the viewer to the docs for cosh(), but returns nothing at all related to files or caches.