From: "Arnt Gulbrandsen" <arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no>
Sent: Wednesday, October 02, 2002 10:36 AM
Well, assume for the sake of argument that it's relevant. Is it also
valuable enough to justify changing email after 25 years of production
use, with a user base presumably in the hundreds of millions, using god
knows how many thousands of different programs?
I don't buy that argument either. People upgrade routinely. Supporting
obscure and
old programs, while not entirely a non-issue, nevertheless should have a
limited and
controlled ability to hamper progress.
Each extra syntax check involves writing at least one more test in the
code, at least two more test cases to verify the code's correctness, some
documentation and some (UI and documentation) translations. And then
there's the (slightly) increased cost of learning the code for the
subsequent maintainers, and the UI for the users.
The main problem with this analysis is that it ignores the comparison with
semantic side catching of the problem. Also, the issue at hand is a
boundary
condition, and hence the test cases need to be there, regardless of how it's
defined. Finally, whether or not it actually causes that extra effort and
cost
of learning depends on how it's implemented in the first place. It could,
for
example, be done with (a descendant of) lex, or a homegrown table driven
lexical analyzer, or with a Perl pattern, or any number of other
well-structured
lexical or syntactic analysis techniques. Granted, many implementations
won't
be so eloquent, but again, the extent to which that should be allowed to
hamper progress should be limited.
I apologize for the depth of this digression. I realize that it's far more
an
issue of philosophy than the relatively minor issue of this point of syntax.
Gary