#1: No one who claims to be a web programmer of any sort should be allowed near the system if he does not understand the intrinsic differences between web server error messages and user generated error message, framework messages, and all the other things that you need to track. That's the 1st thing I do when starting in a new environment, and the preference to NEVER show errors to the web interface.

STDOUT is NOT STDERR, confuse the 2 at your own peril. Each level of abstraction has its own viewpoint of what these mean, and the programmer needs to understand all the levels. All abstractions still resolve to machine code and system calls. Don't want to test for that file open failure? Oh well.

Also, web servers are a shared programming and execution environment. Those core settings need to be set somewhere, and then the individual programmer needs to override them for his own program. Too bad if you don't like it, it needs to be there in several places.

#2: Since C was my baby chick language, the wrappers don't hurt my head. And I understand NJ programming VS perfection, and the tradeoffs that design entailed. Testing the return value was the core difference in programming philosophy that allowed programmers control and allowed the system to be small and fast enough, which allowed unix design to flourish everywhere. This was not a mistake, this was a decision.

#3: The original unix "test" program (aliased to '[') is a command line program used in shell scripting. No concepts of assigning value types on the command line, so programmer had to do something to tell the program which type for logic to use. There are MANY MORE operators to tell it to test things like file size, date, and all kinds of other stuff. I loved that command, and Perl's implementation of it. It became the core '==' vs EQ and all the other test variations, PHP stole it from there. Perl was able to be treated as a replacement for sed and tr and awk by also implementing those test and translation operators, add well the the built in command line desktop calculators. Each of these programs had the possibility for reading hex or octal or decimal or binary STRINGS (you get the point). So perl had to simply read these values and determine if they were just string or a number, on the fly, and "do the right thing". Which is impossible, so the the operators helped it.

You ever to bit twiddling in a "scripting" language fast enough to actually use it a network device driver? And then automate all the production scripts with the same language? hehe. PHP will never be Perl.

#4: When PHP grows up, it wants to be Perl. But Perl was/is an organic language, whipped up by 1 guy as an aggregation of his favorite tools, and it grew from there. And then PHP stole a bunch of stuff from Perl, and hacked it on to its already half-assed implementation, and kept going.

#5: Variables popping into existence when not declared if typed via typo. I FUCKING HATE THAT. THE PERSON WHO MADE THE DECISION TO ALLOW THAT SHOULD BE SHOT (not fatally), DRAWN AND QUARTERED, THEN FED HIS OWN INTESTINES.

Most of his rant is very good, accurate, and one of the reasons I've managed to avoid any serious PHP programming in my career, always offloading to others.

Not worth the stress.