Mostly because the legacy of PHP as a toy project carried forward forever. Here's a great tidbit about why all the original functions have ridiculous, inconsistent naming schemes:
> "Well, there were other factors in play there. htmlspecialchars was a very early function. Back when PHP had less than 100 functions and the function hashing mechanism was strlen(). In order to get a nice hash distribution of function names across the various function name lengths names were picked specifically to make them fit into a specific length bucket. This was circa late 1994 when PHP was a tool just for my own personal use and I wasn't too worried about not being able to remember the few function names."
That's right: Every one of the original function names has a different character length because length was used as a lookup. There are a lot of clowny things like this that have never been stamped out of the language.
Add to that its history of being a beginner language that most of its early adopters sprinkled into HTML and where many people who mayyybe have no business being professional programmers started making a career out of it. This severely undermined PHP's credibility as a language for professionals even though good software can be created in PHP in the right hands.
That all said, I spent about year coding in Hack, and while the parts that still feel like PHP are annoying, it is awesome in so many other ways. Hopefully it either starts to unseat PHP or PHP turns into Hack at some point.
The "Personal Homepage Program" certainly grew organically. Many experienced developers prefer a much more structured approach to defining a language and environment, one with more consistent naming schemes. PHP cannot escape its roots -- it was doomed from the start in this regard.
Inconsistency, very prone to security mistakes, poor type system, and some people just find its syntax "ugly." For example lots of folks hate $strings and $_WTF['bbq'] type syntax. Perl is another language whose syntax draws a lot of haters.
I'd say the second problem is the most objectively bad. It is very easy to write PHP code that exposes you to all kinds of known exploit classes like SQL injection, command injection, cross-site scripting, etc. The language seems to encourage poor practices like building query strings directly from remote input without the use of a true query builder.
PHP also has a problem that it shares with JavaScript and to a lesser extent Java -- the quality of the user base and user-contributed code is often very poor. If you look for PHP code on StackOverflow or Reddit or similar sites, you are likely to get something that is horribly wrong, comically inefficient, or whose use will immediately introduce a dangerous remote security vulnerability. This comes from the simple fact that it's often a beginner language, so you have a lot of inexperienced people participating in forums and contributing sample code.
>The language seems to encourage poor practices like building query strings directly from remote input without the use of a true query builder.
I won't entirely disagree with you on this, because there is still a ton of that code out there, but PHP has had true 'query builders' for a while now, and the mysql_ functions are being deprecated anyway.
It has them, but so many people don't use them. It's partly an issue with the language and partly with the community.
One thing I learned from NodeJS is that the quality of the community around a language can matter more than the language. JavaScript is a crap language, but the NodeJS community and the base of available modules is just so good that it makes up for a lot of the language's faults. When I tried it out I thought "who says you can't polish a turd?" I mean... Joyent and Node's community have buffed that thing down to gleaming crystal.
In counterpoint -- Java's actually a pretty good language, but its community's addiction to criminal overengineering is a big reason it hasn't been "sexy" in some time.
There are a ton of features in modern PHP which address a lot of the common criticisms brought against it. Doing a proper comparison with other languages (framework to framework, not framework to language) I think PHP measures up reasonably well.
But there is so much terrible, legacy code out there. The evolution, if it's happening is happening very slowly.
I think that the fact it has taken this long to even deprecate, let alone remove, utter garbage like these functions is a prime example of why PHP is often reviled.
It almost makes you wonder if the point isn't to keep catering to bad programmers' whims just to keep from losing the 50% of PHP's community that would never be able to write software at all if they weren't working in a language that enabled them to ignore every best practice from the past 20 years.
I'm a web developer too, and I've worked with PHP professionally. It's not a great language in terms of features, but there are worse.
One of the good things about PHP is that it has a very low barrier to entry, making it easy for people to get up and running.
I think, though, that that sometimes leads to one reason why people dislike it: a company gets up and running (which is a good thing) on a hideous pile of crap codebase (not so good) and then decides to hire some more serious developers.
Inconsistency, would be my topmost argument, in general.
Among many other things these include what PHP dodges under
the term "language construct" which when searched produces
a wikipedia stub article with the only examples in PHP.
Failed closures that lack proper scoping, while they have been improved the underlying problem remains.
Continuation on inconsistency is that functions are not first class even though the syntax is the same for closures:
function foo () {
} <--- This is a function
$foo = function () {
} <--- This is a closure
Inconsistency; Cannot access functions (closures) directly from arrays.
$list["something"] = function () {
};
$list["something"]() <- fatal error
What is "truthy" and what is "falsy", not unique to PHP but that doesn't mean PHP should do it.
Assumptions such as how it interprets numbers in octal
Functions do not follow any specific naming standard, i.e. some array functions are prefixed by array_*, some are not.
Include and require scoping is messed up as anything that is not a variable is mashed into the global scope.
Lastly in my post but far from all issues with PHP;
A crap-load of legacy because "we can never break anything"
PHP gets a lot of hate because of internal inconsistencies and sometimes bizarre pass-by-reference semantics, but I mostly get annoyed at how dog slow it can be.
When PHP is fast (and it often is!), it's because the functions you're using are written in hand-tuned C. The kind of "modern PHP" that I write professionally (think Java or C# without types or a compiler) is often disappointing performance-wise.
HHVM is slowly proving to the word that this is not due to PHP itself but to the Zend runtime, but it'll be a while before HHVM takes over.
I don't buy the whole "slow" thing. I work on a very popular SaaS web app, written in PHP, that is running on far fewer frontend web servers than I've seen running other sites with fewer users written in other languages.
With an Opcode cache (available shipped since 5.5) it's perfectly fine performance wise.
I've asked the same question before, and the answers I've received are basically:
A) People like to compare frameworks (e.g. Rails) to the PHP programming language, rather than an apples-to-apples comparison, and therefore PHP always falls short in their eyes.
B) The abundance of poorly written, insecure legacy code has besmirched PHP's reputation beyond repair, even if its actual security isn't bad.
C) The fact that n00bs can pick it up quickly and get a dynamic website out of PHP with minimal effort leads elitists to look down on it from their glass enclaves.
D) Academic reasons that no one outside academia cares about.
Full disclosure: I read and write PHP every day regardless of what people say about it. :D
I am also a developer with experience in PHP(Cake, Codeigniter) Python(Django) Ruby(Rails) according to my experience PHP isn't a bad language and i don't hate PHP its just matter of fact i don't prefer to work in PHP( or any of its framework ) the reason is RAILS offered so much to me in context of Rapid Application Development that neither of PHP's framework offer
Take your pick (probably a combination of the below):
1) it is more popular then what they are using, developing or have skills for
1a) they use language x which does something different that they feel PHP sucks because the lack of it.
2) they got stuck using it and prefer language y instead.
3) They really aren’t all that good programmers and rely on pre-implemented security features to save their butts, and PHP doesn’t meet their dependencies
4) they are invested-in or represent language/platform x and PHP is a compelling contender.
5) they prefer to argue instead of fostering as accessible/usable alternatives for for one reason or another
Just as COBOL, FORTRAN, Visual BASIC, Perl, etc. are reviled by some, they still get jobs done. In some respects it may suck, others it's just fine partly based on intended application and/or coding skill.
If PHP was so bad in all the respects argued, there would be a much more compelling alternative, but it isn't all that bad, and actually quite useful... and popular.
That's mostly because PHP made sense at the time that decision was made - by the time it didn't they had too much legacy to make a complete rewrite worth it. Instead, they chose solutions that wouldn't require a complete rewrite by creating HHVM[1] and Hack[2].
And remember PHP was only used for the user-facing stuff (they probably had more Java and C++ than PHP when they began moving to Hack) - if you look at what they open source[3] only about half a dozen (out of over a hundred!) projects are PHP.
Because people are stupid. And stuck in the 90's. That's the main reason. Other reasons include self-hatred for spending so much time on RoR's/Node's penis. That's definitely the second leading reason. Making less money then "stupid PHP programmers" cause they seriously thought they could develop real applications after learning JavaScript. That's pretty high on the list.
Look the bottom line is PHP has some weird issues (naming inconsistencies, parameter ordering, security issues with deprecated functionality, etc. etc.) but you can find issues on the same level with ANY language. Professional PHP dev's can consistently build large enterprise applications that are readable, scalable, maintainable and performant. Anyone who tells you otherwise is simply not familiar with the transformation that PHP and the community has gone through since version 5.3.
> "Well, there were other factors in play there. htmlspecialchars was a very early function. Back when PHP had less than 100 functions and the function hashing mechanism was strlen(). In order to get a nice hash distribution of function names across the various function name lengths names were picked specifically to make them fit into a specific length bucket. This was circa late 1994 when PHP was a tool just for my own personal use and I wasn't too worried about not being able to remember the few function names."
That's right: Every one of the original function names has a different character length because length was used as a lookup. There are a lot of clowny things like this that have never been stamped out of the language.
Add to that its history of being a beginner language that most of its early adopters sprinkled into HTML and where many people who mayyybe have no business being professional programmers started making a career out of it. This severely undermined PHP's credibility as a language for professionals even though good software can be created in PHP in the right hands.
That all said, I spent about year coding in Hack, and while the parts that still feel like PHP are annoying, it is awesome in so many other ways. Hopefully it either starts to unseat PHP or PHP turns into Hack at some point.