Re: [Bulk] Re: quoted identifier behaviour

----- Original Message -----
From: "Randall Smith" <randall(at)tnr(dot)cc>
>
> I'll give the pghackers forum a visit and since I'm already on the subject
> here, I'll make a direct comparison of the situation. Microsoft's Internet
> Explorer web browser is known to have poor support for the CSS standard,
> but refuses to fix it saying that it's too difficult and would break
> existing websites. Many developers, myself included, prefer to code to
> the standard and have the html/css render correctly in all browsers. In
> the long run, it's better to do it right even if that means breaking
> things today. If the standard is good (there are poor standards), there's
> no reason to not use the standard.
>
In principle, I don't disagree with you. However, I tend to be much more
pragmatic. Often we have little choice in the tools we use. I have seen
occasions where developers were constrained to use MS Visual Studio. It is
an outstanding product now (I have, and use the professional edition of MS
VS 2005). However, MS VS v6 was mediocre at best. And a majority of WIN32
developers had to use it. It was popular despite its problems. It had very
poor compliance to the ANSI C++ standards at the turn of the century,
although that isn't too surprising given its age. But many people thought
they were writing standards compliant code, and that code broke big time
once they tried to use it with later, better, compilers. That is just one
example. Yours is another, and there examples relating to FORTRAN (is
there anyone other than me old enough to remember that? - I recently
encountered IT professionals who didn't know what punch cards where or how
they were used). Yet much FORTRAN code that is four or five decades old is
still valuable a) because it was written to a standard and b) there are
tools to automate converting it into C, allowing it to be used while an old
C++ programmer like myself adapts it to take advantage of key C++
programming idioms and language features (templates, template
metaprogramming). This is because in many cases the core algorithms
developed at the time have not been supplanted by better ones, and they are
still essential for intensive number crunching. I have seen technologies
and standards come and go (or better, be upgraded), and while we ought to
write our code to be as compliant as possible to the relevant standards, if
there is one (there isn't one, last I checked, for VB, Java or Perl), in the
end our tools are the final arbiters of what is legal and what isn't.
Therefore, when the investment in the code in question is significant, and
only then, the most viable approach to trying to preserve the value of the
code is to use the highest common factor between the standard and what the
tools say the standard is (it isn't unusual for tool developers to disagree
about what the standard really means, especially when dealing with some of
the harder issues, and nothing is as simple as it appears at first glance).

It is important to remember that standards change. Just compare the
different versions of the ANSI standard for SQL that have existed over the
years. Or do the same for some of the other languages such as FORTRAN, C
and C++. Since it is certain that even the best standards will change, and
that some of those changes will break existing code, I do not believe it is
worth getting paranoid or worried or upset just because one or another of
our favourite tools lacks perfect compliance with the standard. I do not
define what is right by what a standard has to say. Rather, I define it
according to whether or not the correct answers are obtained and whether or
not the application does for the user what the user needs it to do. In this
view, then, there are multiple right options, and this takes us back to our
tools being the final arbiter of whether or not our code is correct.

So, I say that good standards are valuable tools that can be used to
preserve the value of code that carries significant investment. At the same
time, they are only tools and the value they provide may well pale relative
to other considerations. I disagree with you when you say there's no reason
not to use the (good) standard. Often tool developers put considerable
effort into providing features in addition to what the standard specifies,
often without compromising compliance to the standard since often details
are specified to be implementation dependant. Regardless of their motives
for doing so, there are good, economic and practical reasons to use such
features. The trick, if one must worry about using the code fifty years
from now, is to ensure that implementation specific code is well separated
from standard compliant code and that it is well documented. That way, when
the technology evolves in a way that will likely break your code (as the
coming demise of MFC will certainly do to countless WIN32 applications), it
becomes easier to replace what is broken and preserve what is not broken.

HTH

Ted