These are things in PHP which make me sad

What makes ME sad is no keyword arguments. Helper/wrapper functions either get an annoying and difficult-to-grok-at-glance associative-array for it's params (bad), or a huge list of rarely-used parameters (worse), or a huge set of wrapper functions to set their own paramters (even worse), or outright duplicated functions for similar-but-not-quite tasks (worst).<p>This happens to me while producing something like a jqGrid, or other javascript/html hybrid stuff that need a few extra options sometimes.<p>Django/Python? No problem! Just use the keywords you need.<p>(More Info: The difference between a single associative param standing in for keywords arguments, or a huge list of regular arguments is a choice in complexity/readability IN the function vs. calling it.<p>For the single dictionary approach, you lost the built-in parameter defaults nicety, which means you need to handle the case of a missing parameter manually. This kind of sucks, especially if you hate seeing PHP Notices during development (which kill JSON/XML output anyway). This makes your function often twice as big (or more) than it needs to be.<p>For the other approach, you wind up with calling<p><pre><code> foo("","","","real value", true, true, 2, false, false, "option I want");* </code></pre> which just about invites all sorts of hard-to-find bugs, and you have to look at the function definition every time you want to change an option. Also, it's flat-out rude if you aren't the one calling the function.)

There's a lot of valid points there, but "#33 Cannot override private methods with a subclass" is the right behavior. That's exactly what private is for, and it's important to know that such names are non-colliding and you can rely on their implementation.<p>Use protected for overridable methods. You shouldn't mock or directly test private methods in unit tests — they're not part of the interface!

Before everyone goes all "why don't you switch to language X or platform Y or lisp variant Z" I just want to say good job on this.<p>These all seem to be sane critiques of PHP without being all doomsday world-ending inflamatory. Kudos.<p>Also, I think that this is another example of how hard it is to build up a large and widely-used language/framework without having lots of warts. Especially since PHP wasn't originally designed with the intention of powering everything from a simple blog/cms to facebook.

I've definitely run into #1 on the list. "Paamayim Nekudotayim" is a transliterated version of פעמיים נקודתיים‎, which means "double colon" in Hebrew. Zeev and Andi are Israeli, which kind of explains it, but the error message is still pretty useless.

The ridiculously terrible behavior of == is what makes me the saddest.<p><a href="http://www.php.net/manual/en/types.comparisons.php" rel="nofollow">http://www.php.net/manual/en/types.comparisons.php</a><p>We then have === which does what == is really supposed to do, but even that still sometimes does the Wrong Thing.

As usual, when one of these lists comes out about PHP there are some real issues, some non-issues, some have been fixed, and a few things that are just <i>different</i>. I'm surprised these sorts of posts keep getting voted up here; haven't we seen it all before?<p>I do a lot of PHP development but not exclusively and rarely does these sorts of deficiencies in PHP ultimately matter.

My favorite PHP design misfeature: what does the following code do?<p><pre><code> &#60;?php $foo = array("a", "b", "c"); foreach ($foo as &#38;$bar) echo $bar; echo "\n"; foreach ($foo as $bar) echo $bar; echo "\n"; </code></pre> The "&#38;" is a foreach-by-reference, for those not familiar with the language. When you think you've figured it out, you can execute the code at <a href="http://www.contrib.andrew.cmu.edu/~jwatzman/foreach.php" rel="nofollow">http://www.contrib.andrew.cmu.edu/~jwatzman/foreach.php</a>

I hate PHP, but this article isn't very good. It's strange that there is an "implications for the internals" reason. Guess what, you can just read the internals. It's open source.<p>The parser emits weird error messages because it is a very simple yacc grammar. (And because they turn off yacc's "produce better error messages" mode.) If you want good error messages, it's going to cost you -- just read perl's toke.c if you don't believe me. Good error messages cost <i>a lot</i>.

While it doesn't detract from the point of your post, the behavior of private is correct and intended. If you wish to override an internal method of a class in PHP, like Java, you must declare it protected, not private. This is the difference between private (completely internal, not inherited) and protected (internal, but inherited by subclasses).

I'd love to see similar lists for other languages. I've been coding in MATLAB as of late, for instance, and rediscovered my hatred for the fact that you can't index the output of a function without assigning to a temporary variable. For instance, `foo(args)(:)` causes an error. You have to use `X = foo(args); X(:)` instead. That makes me just as sad as some of these PHP sadnesses.

So how do I contact the author with updates?<p>I clicked on a random item - the complaint that explode() doesn't take the empty string and return an array of each letter. But of course you can just use the str_split() function to do that (which is way more logical than passing an empty string).<p>So how do I contact the author and reduce his sadness level?<p>Or is this one of those websites that don't want to remove items, even if they are wrong?

For an illustration how PHP is 'different' from other languages, consider 'implode':<p>implode — Join array elements with a string<p>string implode ( string $glue , array $pieces )<p>Note:<p>implode() can, for historical reasons, accept its parameters in either order.<p>WTF! What other library has a major function which doesn't care about the parameter order? It goes against every notion of good design.<p><a href="http://us.php.net/manual/en/function.implode.php" rel="nofollow">http://us.php.net/manual/en/function.implode.php</a>

PHP's single greatest advantage is ubiquity - would love to see a CoffeeScript compiler for PHP that smooths out these issues.

Missed one:<p><pre><code> foobar() is the same as FOOBAR() $foobar is completely separate from $FOOBAR</code></pre>

This horse has been beaten, mutilated, and buried.

#40 is a major WTF. They are outright removing the ability to create a length 1 buffer, so that someone who wants to create a 4096 unit buffer can save 3 keystrokes?<p>(Also, what if the length argument is dynamically generated, say from the size of a file?)

Programming languages are tools. Some tools are better than others, some are better for certain situations. For all non-contractors, no one is forcing you to write in one language over another (or stay employed at a php shop).<p>It seems like the only point of having threads like this is for the leet programmers to look down on php. What's the point? This isn't constructive, its condescending and back-patting.<p>(the reason this makes me mad is that the sadness list is just a bunch of minor gripes. Every language has minor problems. PHP has fundamental flaws and that causes sadness, not this crap.)

What makes me sad is that even though I feel affronted by PHP's crudeness, inelegance and inconsistencies… I keep using it for a lack of another language that suits me personally.<p>I hate PHP's runtime and core libraries. But I really like the C-inspired syntax. I use Objective-C as my main other language, and something about Ruby and Python's syntaxes seem to rub me the wrong way. I'm giving Node.JS a whirl these days—and while I might be able to get used to closures everywhere, I don't know how to feel about the lack of true object orientation.

This is by far my (least?) favorite:<p><a href="http://ca.php.net/empty" rel="nofollow">http://ca.php.net/empty</a><p>-----<p>The following things are considered to be empty:<p>- "" (an empty string)<p>- [...]<p>--&#62; "0" (0 as a string) &#60;--<p>- [...]<p>- var $var; (a variable declared, but without a value in a class)<p>-----<p>Why the heck is "0" considered empty?

php -r 'array("a","b")[0];' results in a parse error.

Where are the links to his bug reports for these so we can vote on them to be fixed?

Related: <a href="http://www.phpwtf.org/" rel="nofollow">http://www.phpwtf.org/</a>

PHP is Open Source. Compiling a list like this is nice, but contributing something back, and getting involved in making improvements to PHP, would be nicer.

&#62; Standard libc process control (fork/exec/etc) &#62; The libc fork() and exec() functions are not present in PHP by default. &#62; <a href="http://www.phpsadness.com/sad/17" rel="nofollow">http://www.phpsadness.com/sad/17</a><p>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.

Don Hopkins gave a thorough list of things which are wrong with PHP.<p><a href="http://www.jwz.org/blog/2011/05/computational-feces/#comment-90658" rel="nofollow">http://www.jwz.org/blog/2011/05/computational-feces/#comment...</a>

The function chaining issue (#21) has to be the single most idiotic thing I ever encountered in any language (other than maybe t-sql).

I grok none, but of Python they make me glad

By popular demand, I've added a discussion board to phpsadness.com. Join the discussion!

things about php that make me sad:<p>1. it exists<p>2. it's used<p>3. many of its users make more money than me<p>4. it has poisoned the market, clients have learned to expect and even demand php-braindeath

What makes me sad is that people will defend this horrible language to the death, regardless of how many problems there are with it. I don't get it; we <i>know</i> how bad PHP is, so why do people fight so hard?<p>Oh, and to demonstrate: "PHP has no native Unicode type, no native Unicode handling, and cannot treat Unicode strings as strings." This true statement, composed of three observations about deficiencies in the language, gets me flamed every time I mention it. Why?

Mandatory function arguments:<p><pre><code> function foo($arg1,$arg2) { return; } foo('bar'); Warning: Missing argument 2 for foo() </code></pre> Lame. But omitting arg2 is allowed if you give it a default value:<p><pre><code> function foo($arg1,$arg2=FALSE) { return; } </code></pre> Blah. Instead I'd rather make arg2 truly optional just by testing if it's defined.