I've been documenting POSIX-style regular expressions for The PHP Book, and they're starting to grow on me. Perl has some nice stuff ($ matching before trailing newline) but the sheer readability (and extensibility) of the POSIX named character classes (e.g., [[:cntrl:]]) is very nice. I know Perl now supports POSIX classes, but I get the feeling they're thought-of as second-class citizens.
My current "oh my GOD" reaction to PHP is the great inconsistency in the function names. String functions start with str_, string_, and sometimes something else. This is important, of course, because PHP doesn't have namespaces. The POSIX regular expression function names are only somewhat similar to the Perl regular expression function names. And so on.
This really shows up the dangers of unplanned growth. I'm not suggesting design by committee, but simply articulating a few module design principles could have solved these messes.
Which principles? I'm thinking things like:
--Nat
My current "oh my GOD" reaction to PHP is the great inconsistency in the function names.
You're not kidding. It's great that we can remember that Perl builtins never have underscores. With PHP, the use of underscores is totally random (sort of like CGI.pm used to be). is_array(), is_numeric(), etc., have underscores, but isset() doesn't. strlen(), strtr(), and a bunch of other str* function have no underscore, but str_pad(), str_repeat(), and str_replace() do. And you've got stuff like frenchtojd() taking up the namespace -- for handling the French revolutionary calendar (which of course comes up all the time in my Web work).