PHP Sadness

phpsadness.com · Personal blog · on HN since 2011

An anonymous list of PHP's design flaws, covering inconsistent function names, odd operator behavior, cruft, and confusing error messages.

What HN saysHN 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.
35HN people shared it
29linked it in comments
6stories submitted
326story points
4 months agolast shared
2011people per year2026

Most-shared posts

  1. 1
    These are things in PHP which make me sad
    17 people · 323 points · first shared 2011 · 212 comments on HN
  2. 2
    Sad 1
    4 people · first shared 2015
  3. 3
    Sad 30
    4 people · first shared 2017
  4. 4
    Sad 47
    4 people · first shared 2012
  5. 5
    PHP Comparison Operators
    2 people · 2 points · first shared 2013 · discussion on HN
  6. 6
    PHP: PHPE9568F34-D428-11d2-A769-00AA001ACF42
    1 people · 1 points · first shared 2012 · discussion on HN
  7. 7
    Sad 17
    1 people · first shared 2011
  8. 8
    Sad 48
    1 people · first shared 2013
  9. 9
    Sad 46
    1 people · first shared 2018
  10. 10
    Sad 2
    1 people · first shared 2018

What HN people wrote when they linked it

johannsg · 2018-01-02
I only scanned it, and it seems like a solid book; however, I found that PHP is an odd choice for CompSci I book. From the book: > PHP is a dirty, ugly language held together by duct tape, cracked asbestos-filled spackle and sadness (http://phpsadness.com/). It is the cockroach of languages: it is invasive and it is a survivor. It is a hydra; rewrite one PHP app and two more pop up. It is much maligned and a source of ridicule. It is the source of hundreds of bad practices, thousands of bad programmers, millions of bugs and an infinite abyss of security holes and vulnerabilities. It is a language that was born in the wild and raised in the darkness by two schizophrenic monkeys. But its got character; and in this world, that’s enough.
combatentropy · 2016-10-14
He likes PHP, but its syntax is not the best. It's not a matter of taste, because its syntax is inconsistent. See http://www.phpsadness.com/, specifically Inconsistency and Cruft. Hey, I like PHP too. And inelegant syntax is not the end of the world.
leeoniya · 2016-10-13
The language is not beautiful, it is full of signature and func naming inconsistencies [1] it inherited from C. The devs are ultra-conservative and stubborn to cause BC even at major version bumps (like the forever-incorrect ternary associativity [2][3]). But PHP7 is both fast and productive with many modern first-class features. You can in fact write excellent code without much effort that will handily outperform Python, Ruby and even Node. The Wordpress codebase [plugin api included], though, is utter garbage. [1] http://www.phpsadness.com/ [2] http://php.net/manual/en/language.expressions.php [3] https://www.mail-archive.com/[email protected]/msg71964.html (yes, i asked for this in 2014)
Joakal · 2011-06-03
I recommend Varnish (HTTP cache) where pages are returned instead of touching PHP. APC, a compiled PHP script cache and going to be used in PHP6 releases. Both should lower some resources required. A lot of bad stuff about PHP in this: http://www.phpsadness.com/ (Relevant HN discussion: http://news.ycombinator.com/item?id=2591845)
rzzzt · 2022-11-27
PHP Sadness #1, "Unexpected T_PAAMAYIM_NEKUDOTAYIM" is still the best error message of all time. http://phpsadness.com/sad/1
WalterGR · 2018-04-24
I am genuinely curious of what specific problems you see in PHP and what are the specific issues with the language. There are so, so many. Here are some good references: http://phpsadness.com/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ Disclaimer: I earn my income from a project largely written in PHP.
CiPHPerCoder · 2017-07-14
No, that is not a thorough overview, that is a rant. http://www.phpsadness.com/ is more helpful.
wyqydsyq · 2016-06-30
A language with some consistency would be a start. Go, TypeScript, Elixir are all superior to PHP in that aspect. PHP lacks consistency in naming conventions, function signatures (is that a string or bitmask I'm supposed to pass?) and tons of other things. I could write a novel about it, but there's already multiple websites/articles dedicated to PHP's inherent design flaws: http://phpsadness.com/ https://whydoesitsuck.com/why-does-php-suck/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ Plus it's limited in capabilities compared to stuff like Node.js (or other libuv bindings), considering we get stuff like Hot Module Reloading, isomorphic/universal applications, simple websockets integration, all of which PHP is either incapable of providing or provides inferior solutions due to limitations of the PHP language or Zend Engine.
Arnt · 2015-02-11
Cleans up a lot of the cruft, you say. Interesting. Would you mind taking a look at http://phpsadness.com/ and guesstimating how many of the first ten points remain relevant to PHP7?
throwawayffffas · 2024-09-03
DonHopkins · 2021-09-03
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…
nickpsecurity · 2015-10-29
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…
mfc5 · 2015-01-19
Here's a whole list of reasons: http://phpsadness.com
ciarand · 2014-02-01
>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/)
vezzy-fnord · 2014-01-26
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…
spider-mario · 2026-06-25
Unless you mess up its associativity, like PHP until 7.4. https://wiki.php.net/rfc/ternary_associativity http://phpsadness.com/sad/30
bdcravens · 2023-12-30
The first item in the list, the T_PAAMAYIM_NEKUDOTAYIM error message, doesn't say anything about why the error is referenced that way. That's Hebrew for "::". The idea of using languages other than English to describe things is a big topic in itself, but to read the entry you'd think it was just nonsense letters. http://phpsadness.com/sad/1
andai · 2023-07-24
Haven't had the pleasure of dealing with this, but I'm told PHP has a uniquely broken idea of ternary: http://phpsadness.com/sad/30
ldjb · 2022-12-02
Funnily enough, PHP actually taught me the Hebrew expression for "double colon", thanks to the infamous T_PAAMAYIM_NEKUDOTAYIM. http://phpsadness.com/sad/1
ragnese · 2020-06-26
I think the parent was referring to this: http://phpsadness.com/sad/47
Beldin · 2020-02-03
My pet peeve: http://phpsadness.com/sad/47 TLDR: checking passwords in php used to rely on using the correct comparison operator. Using the'==' operator would introduce subtle flaws. Using '===', you're fine.
alphadevx · 2018-11-29
Agreed, here is another one to file under "not a big deal": http://phpsadness.com/sad/46
chx · 2018-11-29
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!
krapp · 2015-09-02
In before some smartass says something along the lines of "the most common PHP mistake is using PHP..." Also, because it's hilarious[0], the most baffling error in PHP, "unexpected T_PAAMAYIM_NEKUDOTAYIM" means "double colon" in Hebrew, apparently, and refers to the scope resolution operator[1]. Also, according to Stack Overflow, it's misspelled anyways[2]. On the upside, it is VERY Googleable. [0]http://phpsadness.com/sad/1 [1]http://www.php.net/manual/en/language.oop5.paamayim-nekudotayim.php [2]https://stackoverflow.com/questions/592322/php-expects-t-paamayim-neku…
pixl97 · 2013-03-09
Is it real_ksink2cabinet, or real_ksinktocabinet, or real_ksink_to_cabinet? Why is it so hard to put the dishes up? http://phpsadness.com/sad/48
voidr · 2011-05-29
> Standard libc process control (fork/exec/etc) > The libc fork() and exec() functions are not present in PHP by default. > http://www.phpsadness.com/sad/17 Why would anyone writing a PHP app need those? The page just calls it a missing feature without explaining why this is a bad thing.
mastazi · 2016-10-13
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.

Keyboard shortcuts

/Search
j kNext / previous blog
EnterOpen selected blog
vVisit the blog site
fFollow / unfollow
lSwitch grid / list view
dSwitch dark mode
g hHome
g pTop posts
g tTopics
g fFollowing
g lLiked
g yHistory
g qFAQ
EscBack / close