On 3-mei-04, at 17:24, Brett Watson wrote:
But if you look at the kinds of malformed dates that are out there,
most are not malformed because the programmer tried to use some legal
variant of the date syntax and failed to get it right - they're
malformed because the programmer failed to even try to get it right.
True. But IMO, if the syntax were simple, strict and understandable to
the average programmer, this probably wouldn't happen.
I'm not so sure, Arnt. I get the feeling with many mail
implementations that
the implementors failed to appreciate that RFC822 was actually meant
to be a
strict grammar at all. Perhaps the human-readability of it lends the
impression that it's *only* meant to be human readable. Or maybe
something
closer to your explanation is also true in some cases: the grammar is
sufficiently daunting that implementors just aim for an approximation,
coupled with some basic compatibility tests.
I'm sure this is part of the explanation, but don't underestimate
mistakes (bugs) and simple laziness. I know someone who programs really
well but he NEVER EVER implements the code to handle wraparounds. So in
2104 all his programs that use timestamps are going to fail miserably.
(He is a bit of a sign nazi, so 2038 should be ok.) But some time
before that we'll all be using 64 bit math, right? Right...
My best current guess as to how to deal with the problem is
to assume that implementors are lazy, and make a point of giving them
something easy to implement. Assume that they'll take short-cuts to
implementation, and thus take as many short-cuts in advance as you
can, so to
speak. This design approach runs contrary to the typical designer
mentality.
A designer thinks of his design as a great work of art and
engineering, with
each subtle nuance of grammar thoughtfully crafted into place to form
an
aesthetically pleasing whole.
I think it's a mistake to assume that a standard will be implemented
fully. My approach is always: design a bit more than you think you
need, implement only that which you absolutely, positively can't live
without. The thing is that requirements always change so if you don't
anticipate this you'll have to track back on your earlier designs even
more than what's already unavoidable. As to implementing, if you can
live without something, then you've saved yourself some work, and if
not, you just go back and implement it, no harm, no foul.
In this area, I do believe that "less is more" is
the right sort of attitude. Einstein said we should make theories as
simple
as possible, but no simpler, and it seems just as good a maxim for
design.
Indeed. However, this quote is far more wide spread:
"A designer knows he has achieved perfection not when there is nothing
left to
add, but when there is nothing left to take away."
-- Antoine de Saint-Exupéry (1900-44)
but it lacks the "no simpler" sentiment. Maybe if De Saint-Exupéry had
heeded that part too his plane wouldn't have gone missing with him in
it.
The designs and implementations I really like are the ones that are
simple, but still do (almost) the right thing (almost) all the time
anyway. The road to hell is paved with if-thens for special case
situations. If I ever write a non-trivial program that doesn't have a
single if-then then I'm going to retire my programming career (to the
degree it exists) on the spot as things can't get better than that.
Iljitsch