Re: OT: Re: Less is more

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=20
> implementations that
> the implementors failed to appreciate that RFC822 was actually meant=20
> 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=20
> 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=20
mistakes (bugs) and simple laziness. I know someone who programs really=20
well but he NEVER EVER implements the code to handle wraparounds. So in=20
2104 all his programs that use timestamps are going to fail miserably.=20
(He is a bit of a sign nazi, so 2038 should be ok.) But some time=20
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=20
> can, so to
> speak. This design approach runs contrary to the typical designer=20
> mentality.
> A designer thinks of his design as a great work of art and=20
> engineering, with
> each subtle nuance of grammar thoughtfully crafted into place to form=20
> an
> aesthetically pleasing whole.

I think it's a mistake to assume that a standard will be implemented=20
fully. My approach is always: design a bit more than you think you=20
need, implement only that which you absolutely, positively can't live=20
without. The thing is that requirements always change so if you don't=20
anticipate this you'll have to track back on your earlier designs even=20
more than what's already unavoidable. As to implementing, if you can=20
live without something, then you've saved yourself some work, and if=20
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=20
> simple
> as possible, but no simpler, and it seems just as good a maxim for=20
> design.

Indeed. However, this quote is far more wide spread:

> "A designer knows he has achieved perfection not when there is nothing=20
> left to
> add, but when there is nothing left to take away."
> -- Antoine de Saint-Exup=E9ry (1900-44)

but it lacks the "no simpler" sentiment. Maybe if De Saint-Exup=E9ry had=20
heeded that part too his plane wouldn't have gone missing with him in=20
it.

The designs and implementations I really like are the ones that are=20
simple, but still do (almost) the right thing (almost) all the time=20
anyway. The road to hell is paved with if-thens for special case=20
situations. If I ever write a non-trivial program that doesn't have a=20
single if-then then I'm going to retire my programming career (to the=20
degree it exists) on the spot as things can't get better than that.

Iljitsch