I'm not going to argue that PHP is a great language, but the article is a complete disservice to anyone who has bothered to read it. I'm disappointed, but not surprised, that Jeff Atwood linked to it.
Just a few errrors in that article:
> Operators are very fragile in the parser; foo()[0] and foo()->method() are both syntax errors. The former is allegedly fixed in PHP 5.4, but I can’t find mention of a fix for the latter.*
The latter doesn't need a fix because it always worked. Honestly, how hard is it to test that foo()->method() works?
> Objects compare as greater than anything else… except other objects, which they are neither less than nor greater than.
Strict-equals on objects compares the references; but regular equals compares the contents of the objects. Two objects compare equal if the contain exactly the same fields and values. Seems pretty reasonable to me.
> + is always addition, and . is always concatenation.
This is a good thing; JavaScript gets this wrong.
> There is no way to declare a variable. Variables that don’t exist are created with a null value when first used.
Variables that don't exist issue a notice. You can deal with that just like any other error.
> Global variables need a global declaration before they can be used.
Actually there is also the $GLOBALS array for this. I'll agree that's not much a solution. Globals should just not be used; if you want to use static class variables, it's a much better choice with a sane syntax.
> there’s no pass-by-object identity like in Python.
I'm not sure if I understand this but all objects are passed-by-reference in PHP (since 5) and PHP references act appropriately when used as function parameters, etc.
> A reference can be taken to a key that doesn’t exist within an undefined variable (which becomes an array). Using a non-existent array normally issues a notice, but this does not.
An attempt to use the reference will result in a notice but isset() and empty() operate it on it correctly.
> Constants are defined by a function call taking a string; before that, they don’t exist.
You can declare constants in classes and namespaces with the const keyword.
> There’s an (array) operator for casting to array. Given that PHP has no other structure type, I don’t know why this exists.
You can cast scalars to single element arrays and objects to arrays with the same structure. Both are actually very useful.
> include() and friends are basically C’s #include: they dump another source file into yours. There is no module system, even for PHP code.
PHP is interpreted -- namespaces and autoloaders are PHP's module system.
> Appending to an array is done with $foo[] = $bar
This is a good thing.
> empty($var) is so extremely not-a-function that anything but a variable,
Empty is equivalent to the not operator but will also work on undefined variables -- that's why it requires a variable.
> There’s redundant syntax for blocks: if (...): ... endif;, etc.
Useful inside of templates where matching { } is much more difficult.
> PHP’s one unique operator is @ (actually borrowed from DOS), which silences errors.
Sometimes you don't care if a function succeeds; like with the unlink() function which will raise an error if the file you're trying to delete doesn't exist.
> PHP errors don’t provide stack traces.
Not true. Debug_backtrace() will give you a stack trace in an error handler.
> Most error handling is in the form of printing a line to a server log nobody reads and carrying on.
Assuming, of course, the programmer doesn't do anything to handle errors.
> E_STRICT is a thing, but it doesn’t seem to actually prevent much and there’s no documentation on what it actually does.
E_STRICT (or lack of it) is for compatibility with PHP4. When enabled it will "warn you about code usage which is deprecated or which may not be future-proof." -- quote from the manual.
> E_ALL includes all error categories—except E_STRICT.
Unfortunate naming here -- E_ALL is from PHP4 and prior and E_STRICT is all about PHP5. Including it in E_ALL would break PHP4 scripts running on PHP5.
> Weirdly inconsistent about what’s allowed and what isn’t.
This author is confused why syntax errors would be parse errors but logic errors are not.
> PHP errors and PHP exceptions are completely different beasts. They don’t seem to interact at all.
This is sort of true; PHP errors and exceptions exist in different universes but it's easy to unify them and PHP even provides a built-in exception ErrorException to do so. You can turn every PHP error into an exception with 4 lines of code complete with stack traces. You could even turn exceptions into errors but I wouldn't recommend that. PHP supports both procedural and OO programming styles -- this is not a bad thing.
> There is no finally construct
C++ also doesn't have a finally construct. But C++ and PHP support RAII -- class destructors run when the stack is unwound so you can do your cleanup. Finally would be a welcome addition to both languages.
> function foo() { return new __stdClass(); } leaks memory. The garbage collector can only collect garbage that has a name.
PHP is reference counted with a cycle-detecting GC. That would not leak memory.
> Function arguments can have “type hints”, which are basically just static typing. But you can’t require that an argument be an int or string or object or other “core” type
This is true, but it's an ongoing discussion on how to correctly handle scalar type hints. For all the discussion about how PHP isn't designed the author takes issue with the thing they're taking their time on.
> Closures require explicitly naming every variable to be closed-over. Why can’t the interpreter figure this out?
Because of the dynamic abilities of PHP, there is simply no way for the interpreter to ever figure out the variable to close over. The solution is actually a rather simple.
> clone is an operator?!
Of course!
> Object attributes are $obj->foo, but class attributes are $obj::foo. I’m not aware of another language that does this or how it’s useful.
C++ does it. $obj::foo doesn't make any sense, if you're accessing class attributes then you use the class name Class::foo.
> Also, an instance method can still be called statically (Class::method()). If done so from another method, this is treated like a regular method call on the current $this. I think.
Only static methods can be called statically. The other calling methods statically is similar to C++ ... you can call parent class methods explicitly by name by-passing any overriding.
> new, private, public, protected, static, etc. Trying to win over Java developers? I’m aware this is more personal taste, but I don’t know why this stuff is necessary in a dynamic language
This is personal taste not a valid critique.
> Subclasses cannot override private methods.
That is the definition of private methods!
> There is no method you can call on a class to allocate memory and create an object.
You can use reflection to create an object without calling the constructor.
> Static variables inside instance methods are global; they share the same value across all instances of the class
This is the definition of a static property!
> Yet a massive portion of the standard library is still very thin wrappers around C APIs
That is, in fact, the point. PHP is supposed to be a thin scripting language layer over C. It's expanded beyond that. Many of the poor naming conventions are not because of PHP but rather are the exact API of the underlying C library.
> Warts like mysql_real_escape_string, even though it has the same arguments as the broken mysql_escape_string, just because it’s part of the MySQL C API.
Both the C API and PHP have both these functions for backwards compatibility reasons. This entire API is pretty much depreciated with both the mysqli library and PDO replacing it.
> Using multiple MySQL connections apparently requires passing a connection handle on every function call.
Yes, exactly. That's the only way multiple connections could possibly work.
> PHP basically runs as CGI. Every time a page is hit, PHP recompiles the whole thing before executing it.
Unless you use a free code cache like APC. It will eventually be built in. Most people don't need it.
> For quite a long time, PHP errors went to the client by default
If you don't handle your errors, they go somewhere.
> Missing features
Most of these are provided by frameworks just as they are in Python, Ruby, C#, etc.
> Insecure-by-default
Most of these things are now removed from the language after being depreciated for years.