> Since PHP wasn't written with you personally in mind

I believe that I know enough languages to be able to adapt easily to any language. I also think that I can recognize bad design decisions, thanks to the fact that I saw many of them in the making and then - sometimes many years later - these decisions' impact on day to day programming.

To the point: there are arrays in PHP. You can iterate over them with 'foreach'. And you have iterable objects and you can use them with 'foreach' too. Good.

Now, what makes iterator objects iterable is that they implement a certain interface. This interface is public. This means you can rely on it to make your own version of 'foreach'.

Except that you can't, because arrays, most frequent iterables in the language, do not expose iterator interface.

You can say it's irrelevant - but this is inconsistency. And a bad design decision. JavaScript is the same in this regard, except it doesn't even have "official" iterator interface. Both Ruby and Python, however, get this right - everything that is iterable in them implements and exposes the same interface, no matter if it's a built-in or custom object.

You either don't agree that PHP implementation is inconsistent or are unaware of what you could use "custom foreach that works with evereything in the language" for. In both cases you're not a person I want to seriously talk with.

You also arbitrarily assign making and not making sense to things. It's not a good thing that you were conditioned by your language to agree with the decisions its design follows - in the example with destructuring you argue that destructuring hashes isn't commonly needed, while all the arrays in PHP are hashes and you have no way of knowing if the feature would be convenient or often used. You basically believe that generic pattern matching is unnecessary because PHP doesn't have it. You also omitted the part about how - aside from hashes - it would be nice to support destructuring in definitions of functions formals. These two things make the pattern matching support in PHP inconsistent.

You said nothing about error handling strategies in PHP. That means you agree that there being many of them for many different kinds of errors is a bad and inconsistent thing. Functions which fail "silently" in the code but print a warning on a rendered page? "Silencing" them even more with '@'? Seriously? And completely unrelated to exceptions, which are in the language too?

Well, these are not my "strongest arguments" - these are just first things I thought of, without trying very hard and based on a bit dated experience with PHP. I think the most convincing argument is just using another language - or better a few languages - for some time. Of course they all have weak and strong points as well as warts and inconsistencies. But saying that this makes all languages somehow equal and all inconsistencies equally troublesome is just wishful thinking. After some time with Clojure, Python, F#, Erlang, and Go you'll be able to see PHP for what it is.

And it's not a bad language, and you should continue making money working with it of course! Just stop accepting everything it comes with as a "true way". See it's features for what they are: sometimes smart, sometimes stupid decisions made by ordinary guys who sometimes had some insight, but most often just did whatever they thought will be ok and waited to see if it worked. This way you'll be able to push your favorite language forward, which is a theme of this article, isn't it.