[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 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