PHP 26 Apr 2012 17:00:00
While there is no doubt PHP is broken beyond repair, it does have a few virtues that keeps it as one of my first choices when writing certain kind of web frontends and minor tools.
There is a huge laundry list of how PHP is broken at “PHP a fractal of bad design“, which I almost entirely agree with. What I will do here is point out the few things on that list that I do not agree with, and why.
Global variables need a global declaration before they can be used.
I’m 50/50 on this. What I do instead is use the explicit $GLOBALS array when accessing any variable I intend to be global. This provides a clear visual distinction of whether a variable is local or global. But yes, the scoping is surprising when learning PHP.
include() and friends are basically C’s #include: they dump another source file into yours.
I love this feature, and I wish Perl had an equivalent. This makes designing some things much simpler.
Including a file dumps its variables into the current function’s scope (and gives the file access to your variables), but dumps functions and classes into global scope.
See above. This behavior looks crazy when coming from any other language, but it simplifies some tasks.
Appending to an array is done with $foo = $bar.
I’m ok with that. It’s shorthand that doesn’t hurt any other feature.
There is no finally construct, making wrapper code tedious and difficult to write.
PHP is one of the few languages that does RAII correctly, so it doesn’t need finally.
Static variables inside instance methods are global; they share the same value across all instances of the class.
This is expected behavior. That’s also how C++ and Java does it.
Using multiple MySQL connections apparently requires passing a connection handle on every function call.
Obviously? This is benign shorthand again. In 99% of cases I only have 1 connection to the RDBM, so why should I have to manually keep track of this and pass it to every function? However, newer MySQLi fixes this in the correct way by making the connection and functions tied to it an object.
mbstring; No Unicode support.
I disagree with everything here. PHP’s way of handling UTF-8 is awesome. A string is binary-safe sequence of bytes, which you can pass to various functions and tell them to interpret the raw bytes as UTF-8 or any other encoding. But you can always just dump the raw bytes to a file or stream and not worry about silent conversions. This is so much cleaner than the notion that a string is a sequence of characters that Perl and friends have, where you can’t ever be 100% sure if the string variable you’re working with is compatible with any other string variable. Yes it requires using mb_* functions and preg modifier /u and a few other things to be mindful of, but it bloody works as expected all the time.
This one datatype acts as a list, ordered hash, ordered set, sparse list, and occasionally some strange combination of those.
While the complexity of operations on the data type is hard to guess, I think this is PHP’s strongest point. I would love to have a similar data type in all other languages. Being able to rely on associative lookups and insertion order makes getting what is in my head out in a functional algorithm trivial, and in a third of the lines it would take in other languages. I would never use it for heavy processing, but for quick fixes it is divine.
A list of ordered things and some mapping of keys to values sounds kind of like a great way to handle function arguments, but no.
Learn from Perl, pass a hash…it’s not pretty, but it works.
…and the rest of the list I agree with.
I thoroughly enjoy writing PHP myself, but I would never suggest anyone learn it as their first, second, or probably even third language. You need a solid understanding of how to write good code before you can safely use PHP, and even then PHP does things to undermine that understanding.