Into the trash it goes.
Seriously, the avoid-crashing-at-all-costs anti-pattern is what made HTML, JavaScript and PHP the messes that they still are, from which the latter one is only now recovering at a glacial pace. For once, we could learn the lesson.
-- Joel Spolsky[1]
1: https://www.joelonsoftware.com/2003/10/08/the-absolute-minim...
Joel merely states what reality showed about Postel's law over decades.
It's a thing developers know from experience, if Joe Random had said the above quote, it would still be true.
And we shouldn't conflate adoption success with design quality either.
That said, it's not like TCP is a great example of Postel's law, and surely not in the crude way it's understood and practiced by its advocates. The RFC says:
"As a simple example, consider a protocol specification that contains an enumeration of values for a particular header field -- e.g., a type field, a port number, or an error code; this enumeration must be assumed to be incomplete. Thus, if a protocol specification defines four possible error codes, the software must not break when a fifth code shows up. An undefined code might be logged (see below), but it must not cause a failure."
Which is hardly the "anything goes" ticket people imagine it to be. E.g. TCP would still break on a badly formed header and consider it an error.
Besides, the advice is good for a transmission control protocol, especially one involving in-between nodes that will not care for the enumeration values like ports and such like the start/end nodes do, and just need to pass them through.
It's horrible for other types of software. Language parsing would be a great example where it should not be followed. And of course the most famous related shit show is HTML handling in browsers. HTML might be succesful, but it's hardly because of following the Postel principle.
I think if webbrowsers were not lenient with HTML parsing the web would have been adopted much slower in the initial years. Also, HTML5 can be seen as a confirmation that XHTML2 with a strict parsing would not be successful. I followed the WHATWG mailing lists quite closely when that effort began. This is evidence for the applicability of Postel's law at least in the case of HTML.
Some of the most popular instances of doing a best effort to figure out the intent of the sender are also poster children for protocol level security flaws. If we've learned anything from deploying, managing, and developing on top of the core internet protocols it's this:
1. Be very conservative in what you send.
2. Reject anything that isn't what you expected to get.
If you squint you can sort of see that being a valid interpretation of Postel's law but it's not the standard interpretation in practice.
Also arguably the three most popular ways anyone got into programming in the last couple of decades. Something worth pondering on.
JavaScript and HTML for obvious reasons. PHP because if you didn't have your own server, you couldn't run anything else (while there were free hosting providers that would host your PHP scripts).
Nowadays there are tons more options.
Forgiving syntax made HTML and PHP easy, and because it was easy people were quick to learn and use them. Everything is trade-offs.
and then went on to write a shitload of insecure code.
Just because it's simple to use, doesn't mean that just anyone should be using it. The problem with PHP is that it can be used by someone with far below average programming skills to make something functional. But the flip side of how forgiving it is, is that it takes someone of above average skill to make something to use it to make something safe and performant.
Making it easy to use wrongly also makes it harder to use it right. Simply because you lack any feedback when you do something dumb.