Re: [Bulk] Re: quoted identifier behaviour

["Ted Byers" <r.ted.byers@xxxxxxxxxx>]

----- Original Message ----- 
From: "Randall Smith" <randall@xxxxxx>
> 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