Ethical programmers don't want to deliver programs to users that are riddled with unknown, undetectable bugs, that silently corrupt data and make mistakes, without being caught by testers or warning the user.
That's why it's better to be bold and crash spectacularly, instead of trying to cover up unexpected problem by guessing. If you have an unexpected null pointer, there is a reason, and your expectations were wrong, so there's something bad going on that you don't know about. By silently hiding the problem, your program may be doing the just wrong thing, and you never know about it.
That's the problem with PHP, which has it even worse than Objective C. Ignoring errors and guessing what to do is PHP's way of life, and it's been the cause of countless security holes, data corruptions, and hard to diagnose bugs.
Use lots and lots of pedantic asserts, and test thoroughly, so the production code does not have to be riddled with labyrinths of error handling and mitigation guessing code. Assume the APIs obey their contracts, and write APIs with strong contracts that do what they promise. If something might return a NULL, then test for it and handle it properly, so whoever is reading and maintaining your code knows that you considered the possibility and thought through the solution, and the computer doesn't have guess what to do.
Computers are notoriously bad at guessing the programmer's intentions, so programming languages should not encourage programmers to let the computer guess what they meant.
I don't purposefully release software with bugs. Bugs are inevitable no matter how good of a programmer you are. Like I said, would you rather your browser crash on every javascript bug? Because that's how a lot of client side software operates.
You're not getting it through your head, or comprehending what I am saying, so you obviously have no experience as a professional software developer. Your software will have a lot more bugs in it, and is a lot more likely to corrupt your users' data, if the language you use conceals the problems from you during development and testing, and guesses at what you want. Go back and read what I wrote, and address those points instead of ignoring them. You are incorrect that it's better for a programming language to hide errors, guess what you meant, and silently corrupt data. You may think that it's convenient for you not to have to type the extra keystrokes to check for unexpected null pointers, but that is because you are a lazy programmer who would rather save time and cut corners than write reliable code.
