> "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.
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.
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.
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.
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 kid, I kid. Mostly.
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.
I've been in that position, and it is not fun.
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"
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.
With an Opcode cache (available shipped since 5.5) it's perfectly fine performance wise.
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
> An array in PHP is actually an ordered map.
This is what i thought
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.
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.
[1] https://en.wikipedia.org/wiki/HipHop_Virtual_Machine
[2] https://en.wikipedia.org/wiki/Hack_(programming_language)
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.
