From "Javascript: the good parts":

It is rarely possible for standards comittees to remove imperfections from a language because doing so would cause the breakdage of all of the bad programs that depend on those bad parts. They are usually powerless to do anything except heap more features on top of the existing pile of imperfections.

Douglas Crockford's terse yet lucid javascript primer makes some excellent points on writing in a language with more than its fair of share of shortcomings. The advice is manyfold: constituting functionality or design decisions to avoid (the "bad" and "awful" parts) as well as patterns and practices making use of the strongest parts of the language. Essentially, one is guided to programming within a subset of the language, avoiding the poor quality and outright dangerous components. This chimes in well with the notation of "programming into a language" rather than within in it - stressed by the seminal "Code Complete" by Steve McConnell.

Don't limit your programming thinking only to the concepts that are supported automatically by your language. The best programmers think of what they want to do, and then they assess how to accomplish their objectives with the programming tools at their disposal.

Both these concepts are relevant to programmers of PHP - a language carrying just as much baggage as javascript. In my experience, developers who have only known PHP are prone to employing of a variety of bad practices and anti-patterns. Such things are fostered by several influences, including the forgiving nature of the language, the veritable wealth of bad advice within the comments on the PHP manual, and a general lack of understanding of the art of object-oriented programming. Indeed, I think it's essential that PHP developers learn to program (and hence think) in other languages: python and java in particular. Reading the work of Martin Fowler is a good place to start but that's a topic for another time.