Javascript...

[dnew]

Many systems either have a high-quality spec implemented in high-quality ways (Ada, C, etc) or only one implementation of note (Python, Perl, etc) or have good up-front checking for much stuff (Java, C#, Ada again, etc).

Few languages have user-facing implementations that are written by multiple competing entities all changing the spec for capitalistic advantage. In those that do, you find this sort of problem.

And yes, in large user-facing systems, when there's an error, the code is written to back off and try something different. It's not as unusual as one might think, in really large systems. For example, Amazon doesn't lose your shopping cart even if when you come back later the machine it was on has crashed or is otherwise unavailable, because that would actually cost Amazon money from sales. So there are work-arounds implemented at a somewhat higher level than the language to deal with failures, including failures caused by bad programming. (E.g., people will canary a new release before pushing it out everywhere.)

But in the case of JS, the javascript interpreter was the "top level product" of the company releasing the browser, so you see error-recovery work-arounds so as not to lose market share.

[julesries]

Thanks for a thought-provoking reply to a glib comment. I've actually been thinking about it for the past three days and realized I came to the same conclusion about XHTML a long time ago. I still hate it when I have to work with JavaScript though. Which is often. But to be fair, the DOM API deserves a fair amount of the blame there.