in reply to Re: Larry vs. Joel vs. Ovid
in thread Larry vs. Joel vs. Ovid
-
The web browser is an excellent example; the problem
started, however, before NS was even NS -- the initial
versions of Mosiac offered no clues to the user that the
web page was malformed, and that trend has continued since.
Is this necessarily a good idea? It's a big if, of course,
but I would suspect that if my browser told me every time I
encounted a page that didn't meet W3C standards, I'd be
very very tired of getting that warning nearly all the
time. From a UI stand-point, some would argue that not
informing the user of a bad layout in a web page is a good
thing (You should only tell the user that there's a serious
error if they are supposed to take action to do something
about it). But here, the problem was that there was no way
of using the browser alone to determine bad makeup.
I wouldn't want the browser to pop up with a big freaky modal dialog every time I loaded a page with somewhat suspect HTML, but I would like to see some indication that the page isn't well-formed -- perhaps a message in the ubiquitous status bar to the effect of "This page is not valid HTML, and may not be displayed properly". As a user, I'd like to be told if the page I'm looking at is garbled (often one can tell immediately if a page hasn't rendered the way the designer would have liked, but I think it's reasonable to believe that some pages would be mis-rendered with subtle, important errors), and as a developer I'd sure like to know. (Of course, as a developer, I have plenty of HTML validators at my fingertips.)
And bringing this back on topic... this point generalizes fairly well to programming in general. That's why compilers have warnings as well as error messages. I see no reason why all programs, especially those that talk to people, should insist on conservatively correct input. If you get suspicious input, emit a warning and do the best you can. That way, if you're relying on vaguely bogus input from someone else's software (for instance), you can still get work done. The difference between this model and the web browser problem is that Our Favourite Web Browsers(tm) don't give any (easily accessible) warnings about malformed HTML, so Joe Luser has no idea that they've just written awful markup.
That said, within your own code strict adherance to contracts (for instance) is an excellent idea. If you're generating bogus data, you're going to want to know about it, not fudge it and hope for the best, and it's much more difficult to ignore a confess than a carp.
--:wq