Is there actually something non-deterministic about PHP? If not it seems like a better programmer would simply be aware of the language's less elegant features and work around them.
Builtin features you can't override have data-dependent bugs. Most values work, but some values fail (deterministically) and most users don't know that. You can't even fix the interpreter unless you're running a non-shared copy and are not running any third-party code which happens to rely on the odd misbehavior.
Imagine a language runtime in which arithmetic on exact multiples of 1536 always returned -1. You could work around that if you had to, but it would be awful. You'd have to scrutinize most every line carefully to rule out this ever happening, or wrap every numeric subexpression in some kind of conversion to/from safe values, which nobody would be consistent about doing. The maintenance difference between clear, expressive code and code that actually works would be dramatic. People would tend to realize it started happening again a while ago and rush to fix one spot in production that seems prone to it. The web would be littered with tutorials that punt on handling it in the name of encouraging beginners.
Then there's idiocy like "break 2" which is worse than goto in every possible way yet more widely supported.
Who said PHP was a good tool? I'm responding to the parent comment asserting that being a better programmer won't help you, which is clearly not true. All our tools are deficient to a greater or lesser extent, and part of what defines the skill of a programmer is working with the tools you have, working around their deficiencies, and resisting the urge to engage in architecture astronautism.
If you have a choice, sure, don't use PHP. But if you don't have a choice, PHP won't stop you shipping a quality product.
Imagine a language runtime in which arithmetic on exact multiples of 1536 always returned -1. You could work around that if you had to, but it would be awful. You'd have to scrutinize most every line carefully to rule out this ever happening, or wrap every numeric subexpression in some kind of conversion to/from safe values, which nobody would be consistent about doing. The maintenance difference between clear, expressive code and code that actually works would be dramatic. People would tend to realize it started happening again a while ago and rush to fix one spot in production that seems prone to it. The web would be littered with tutorials that punt on handling it in the name of encouraging beginners.
Then there's idiocy like "break 2" which is worse than goto in every possible way yet more widely supported.