An anonymous list of PHP's design flaws, covering inconsistent function names, odd operator behavior, cruft, and confusing error messages.
HN commenters cite it as the standard catalog of PHP's inconsistencies and cruft, and joke that its T_PAAMAYIM_NEKUDOTAYIM entry is the best error message.
For Turing's sake, if you insist on chaining ternary operators, then you should always use parens instead of showboating that you cleverly-by-half memorized a particular language's obscure precedence and associativity rules.
PHP in all its glory and splendor actually originally used left-to-right instead of right-to-left associativity for the ternary ?: operator, so that expression you wrote works differently in PHP and (JavaScript or C or any other language). (Side note: notice how I used parens instead of depending on you guessing about the relative precedence of "and" and "or" in English.)
It's easy (and perfectly valid) to blame the designers of PHP for not knowing or caring or paying much attention to the syntax of the programming languages they were imitating, and doing something that stunningly stupid, but it just goes to prove that many people (especially PHP designers like Rasmus "I don't care about this crap at all" Lerdorf and typical PHP programmers) don't even have the faintest idea what the precedence and associativity of many of their favorite programming language's operators are, or what those terms even mean, and they just willy nilly cargo cult copy and paste and translate between PHP and JavaScript code examples from Stackoverflow, introducing terrible hard-to-spot bugs.
https://en.wikiquote.org/wiki/Rasmus_Lerdorf
>"We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you…
That's a troll comment if I've ever seen one with even less information than what was in the linked article. Your comment actually has no information: a mere dismissal.
On opposite end, my link was at least clear on attributes of a good language. These were specifically mentioned: predictable, consistent, concise, reliable, debuggable. The author gave specific examples showing PHP lacks these traits. An analysis of Python or Ruby show them to embody these traits much more while also possessing the supposed advantages PHP fans tell me including easy learning, many libraries, huge community, tools, etc. So, the evidence indicates PHP is a poorly designed language (or not designed at all) while some competitors are well-designed languages with most of same benefits.
Other authors say about the same about both philosophy and specific details showing why PHP is a pain to work with if you want robust software along with building skills a good developer should have.
https://www.quora.com/Why-is-PHP-hated-by-so-many-developers
http://phpsadness.com/
https://blog.codinghorror.com/php-sucks-but-it-doesnt-matter/
Truth be told, though, the burden of proof is on you PHP supporters to show why PHP is a good language and people should use it. I claim it was a mere pre-processor that had all kinds of programming language features bolted onto it over time to let it handle certain situations. That's not design at all. Python and Ruby are designed languages with consistency, core…
Several reasons, I think.
For one, it's no secret that PHP was an amateur undertaking that inadvertently ended up powering >80% of the web.
It started off as a bunch of helper functions that were meant for Rasmus Lerdorf's personal use. He has frequently acknowledged that he was never particularly skilled and that PHP was never meant to be used on such a large scale. Among the countless WTF moments you would expect from a personal project, PHP once used strlen() as a hashing function. [1]
Thus, PHP ended up having a very inconsistent design and an awful typing system. It ended up becoming quite baroque, it has never had a formal specification and it has no coherent idea of what it wants to be. This is exemplified by PHP's relatively recent appropriation of Java idioms in an attempt to bring vague Nygaard OOP.
Third, it's fundamentally a templating language and it doesn't encourage any cohesive design patterns or practice. Most PHP sites don't even use frameworks, but rather go with the Mozart (or rather, spaghetti) style of copy-paste programming. There is no clear separation of concerns.
Fourth, the PHP community has always been dominated by amateurs. I can't really direct you to any objective statistics, but in general PHP has a disproportionately high amount of leechers and newbies, largely because it has been so deeply ingrained into the public consciousness as the de facto language of the web, without knowing of the better designed general-purpose…
Of the four disadvantages of PHP mentioned in the article, in my opinion, the worst by far is the first, i.e. confusing comparison rules. The article however fails to explain that clearly: the worst thing is not that comparison rules are just confusing (heck, many things are confusing at first, but eventually you work them out); the worst thing is that those rules are intransitive (!!!), as explained very well here: http://phpsadness.com/sad/52
The second disadvantage, passing by reference vs. by value, honestly can or cannot be confusing, depending on which other languages you are accustomed to. So I would say it is a debatable point.
The third point, the language being failure-adverse, is a choice made by design, this is also a debatable point, but it's in line with the fact that PHP was created as a utilitarian language as Lerdorf explained numerous times, e.g. here https://www.youtube.com/watch?v=anr7DQnMMs0
The last point, inconsistencies in the standard library, is obviously true but I would say it is very common in languages that have been around long enough to have subsequent approaches layered in the standard library. Some languages resolve this by making breaking changes and keeping consistency (think Python 2 vs Python 3), some others just show their age by having libraries that were developed at different point in time (Perl, R and Java come to mind), this is also explained by Lerdorf in the video linked above.
>PHP plays a bit too loose with those rules
I don't think you or I disagree on this. The language does not handle strings gracefully.[1][2] The more magic casting and conversions I can remove from my codebase, the happier I'll be.
I'm sure there are some individuals that would misuse strong typing, but it would help a whole lot of people avoid some really, really dumb bugs. This isn't so much about knowing what's going on internally (binary representations), this is about being able to catch bugs early and often. It also helps in refactoring and improves the quality of linters.
But yeah, if SWTH casts if a parameter matches the definition of a type (e.g. 1.5 is not an int but 1.0 is) then SWTH is fine. There'd probably be a little bit of a performance penalty, but as long as the devs implement strict casting rules (according to Nikita's favorite proposal) then it solves my problems. As a sidenote, Nikita actually agreed to the casting change after posting that article[3].
[1]: http://phpsadness.com/sad/47
[2]: http://stackoverflow.com/a/1995196
[3]: http://www.jejik.com/articles/2012/03/a_php_type_hinting_alternative/)
Yeah, yeah, more PHP bashing. But PHP has very nicely cleaned up since oh 5.3 or so and with every release it's getting better. For example, to bemoan "Declaring a function called __lambda_func() completely breaks create_function()" completely ignores the fact noone should (or does) use create_function() since the introduction of proper closures. http://phpsadness.com/sad/2 is made up too, just use a constructor. There truly is no problem with PHP any more if properly used. Yeah we can rehash the arguments from the last twenty years but instead -- have you seen the language where the community and culture is so fractured someone could sneak in a bitcoin wallet stealer without anyone detecting it? The language which insists that the completely different concerns of backend and frontend development should be done in the same language? Now, that's what ridiculous!