What part of “pick the tool that fits the job” do some people tend not to understand?

And it’s not all about the technology itself. You need to take into issues such as knowledge gaps, skills gaps, time, money, extensibility, and more …

But you seem to be missing the point: For what it does (which is getting a website out of the door with a minimum of fuss and muss) PHP is pretty well suited for it’s task.

A problem that a LOT of developers have is not realizing when their projects have reached the limits of PHP (at least with no framework attached). They keep on plugging away and then complain about PHP’s limitations.

@Eevee: Clearly, from your vast list of problems, you have come to a point where PHP no longer suits what you’re trying to do. And that’s fine, but ot say that it isn’t suited for “anything more complicated than a page counter” is exactly the type of whining and complaining I’m talking about.

Man used to hunt with a rock. Just because we now have guns, doesn’t mean a rock still can’t bash someone’s head in.

I’ve never heard ORM used as an argument about PHP before I read this post, and I’m not using it as one myself. I’m just pointing out that ORM use seems to be unusually uncommon within the PHP world, which may explain the complaints *you* have heard. Personally, I would blame this on what I perceive to be a disproportionately large number of amateurs within the PHP community.

It has PLENTY of issues, and there is nothing about it that makes it significantly better than other languages. I can name plenty of issues I have with Perl or Python, too, but they are mostly design disagreements or backwards compatibility. PHP’s are more fundamental problems with consistency, unexpected side effects (often in the name of being “easy”), disorganization, missing/broken features, and all manner of other such roadblocks that make PHP take far more effort to work with than should ever be necessary.

Lack of closures alone is almost a deal-breaker; they are an odd feature but have left me with much simpler and cleaner code on numerous occasions. Functions aren’t first-class objects at all, so there are no function pointers. The cavalier attitude with errors or warnings (essentially “never ever break no matter how absurd the alternative”) makes it harder to find problems and doesn’t yield results much better than an error page. The function library is useless unless I look through the thousand-function manual every time I want to do something — and make sure I pick the right one out of two dozen alternatives. Substitution with eval is completely broken. Database access is STILL a mess; SQL injection is rife in PHP code as the manual still doesn’t even advise using prepared statements, so a lot of wild code is full of mysql_real_escape_string and magic_quotes and whatever other manner of layers of hacks to work around a problem that was solved a decade ago in every other language. The object system is a joke; there are no friends, static methods don’t know what class they’re being called on, constructors can’t be variadic, equality can’t be overloaded.. There’s no module handling or versioning. There’s nothing to hold a torch to CPAN; there’s PEAR, but it seems oft-neglected, so the common case is to just use the myriad of builtin functions and roll your own if you need anything else. Since everything is built in, if you need a module your host hasn’t compiled support for, you’re screwed — whereas installing any version of any module locally in Perl or Python or Ruby is easy. Unicode is a joke. Arrays and hashes are intermingled, giving a very ambiguous sense of when I’m using which (what if I want a hash with numeric keys? I’ve done this half a dozen times, but needed an ordered hash only once in my life) and leading to yet more cognitive overhead; array functions also become far more complicated than they should be, as they have to account for any sort of combination of the two. References aren’t really references, and there are no weak references, which makes avoiding circular references a lot more convoluted in some cases. Embedding code within HTML is, again, a terrible idea. Strings and numbers are the same sort of variable, but there is neither real typing nor different operators for comparing each, so there’s more for me to worry about even when comparing values. Array access syntax is broken; I can’t write something_that_returns_an_array()[$i]. Reflection is a pain and inconsistent with the rest of the language anyway (suddenly OO?), but the lack of first-class functions doesn’t help. The sigils ($) don’t even have any reason to exist, unlike in Perl where they denote variable dimensions, but they permeate the language anyway.

High-level languages are supposed to be a tool, to do work for me that I shouldn’t have to worry about. PHP might as well be the assembly language of Web programming: a large mass of functions but little functionality outside of that. Little things like comparing numbers to strings might seem trivial, but when you have some quirk or side effect to worry about on every other line, it becomes a monumental distraction from just writing code and makes avoiding bugs that much harder.

The other languages are richly-featured and well-designed. Even Perl 5, suffering from more or less backwards-compatibility with Perl 4, manages to remain powerful, flexible, and mostly consistent. They all have built-in and simple reflection, functional programming constructs for when they make sense, fully-featured CGI libraries and rich sets of other third-party libraries (all in their own central packaging systems and loaded by real module support), rich OO support, and very simple standard libraries that do a small set of operations well.

I have never heard a compelling reason to use PHP for anything more complicated than a page counter. Even the Web-targeted features in PHP are ones that tend to be avoided in larger projects, where more organization is needed and frameworks should be taking over. It works, sure, but that is a trivial milestone to pass, and there is nothing about it that makes it work better than another scripting language.

But you cannot deny that PHP just works!

The function library is not problematic because of size, but because of organization. When you have THOUSANDS of builtin functions and neither a real package system nor namespaces, organization is kinda important. But instead of builtins being object-oriented — which would then make the LANGUAGE, in actual practical use, also be so — there’s just a myriad of functions that each take some object or handle as a first parameter. Of course most PHP code isn’t going to be OO: nothing in PHP’s core is! Worse, they’re inconsistently named at best, a lot are duplicated with very similar functionality (there are some 23 functions for finding one string in another), there are messes like mysql_real_escape_string (instead of mysql_fake_escape_string!), etc.

Presumably the SQL complaints are about PHP’s lack of an ORM library with a lot of mindshare? Ruby has ActiveRecord, Perl has DBIx::Class, Python has SQLAlchemy. I’ve never seen one used with PHP at all.

Most of PHP is a patched-together mess, yes, and I don’t know of a single advantage it has over the other open-source scripting languages.