What Larry stated is a commonsense and correct rule. A given program will be most effective in communicating if it is generous in what it accepts and strict in what it emits. You may prefer Netscape's breaking on certain constructs. But no matter what you prefer, it is a fact that Internet Explorer is better at communicating than Netscape is. Because it is more generous in what it accepts, and goes out of its way in what it emits to do things like work around broken browser version checks.

What you and Joel are saying is that communicating well is not always wanted! If I have barely learned another language, when I try to communicate I darned well want to deal with someone who will hear through my accent, mangled grammar, and know to point me to the bathroom now. If I am trying to learn how to be understood, I want that person to point out my mistakes, correct me, and be very strict in what they call acceptable.

So Larry is right. Browsers are great communicators. They bend over backwards to communicate. And that fact helped millions of novices, who are scared of their computers, to reach out and successfully communicate with each other. Had HTML been strict by default, I strongly doubt that that would have happened.

In so far as Joel is talking about something different than what Larry is, he is also right. Having all of these great communicating programs around has spoiled people. They succeed in communicating with the most popular browsers even though they are communicating really badly, and so have learned to be bad communicators. A world full of bad communicators is hard to understand.

But as long as Joel is talking about what Larry is, he is just plain and simply wrong. A program that refuses to implement simple workarounds for mistakes that you know are out there is worse at communicating. Period. There are cases where it fails to communicate, even though communication is demonstrably possible. Whether or not improving your program's ability to communicate leads to better communication is a different issue. There are tradeoffs both ways. And certainly if you are developing software, it is best to find out errors as quickly as possible. (Which is why I explicitly tell Perl with strict.pm to not try to be generous in figuring out what I meant to say...)

And IMO criticizing Larry Wall for a point he didn't make is just plain unfair.