Date: Fri, 14 Jan 2011 22:32:46 -0500
Reply-To: Ian Whitlock <iw1sas@GMAIL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Ian Whitlock <iw1sas@GMAIL.COM>
Subject: Re: Can someone with 9.1 or earlier test this code?
Content-Type: text/plain; charset=ISO-8859-1
Summary: Is the coder responsible when making a mistake in code that
executes or is the implementer of the language responsible? What is the cost
in terms of the language when one blames the language implementer
rather than the programmer?
Arthur Tabachneck <art297@ROGERS.COM> wrote in part:
While I agree that error checking is important, I thought that SAS always
ensured that previous code would continue to work. This is the second such
discrepancy with that rule I've seen this week. Proc import using Excel as
the DBMS on 64 bit systems was the other.
in reference to a line of macro code
%else %then %do;
It is my understanding that in going from one version to another the
implementer has some moral responsibility to try preserve the way LEGAL
code works. (However all bets are off when the implementer is a private
company and the language is proprietary.)
On the other hand, when code is illegal, the user is responsible for
whatever happens, not the implementer; although error messages are
appreciated.
Consequently the SAS Institute has preserved the nature of the code in
this case. It was illegal code before 9.2 and it is illegal in 9.2.
The only difference is that the language is more reliable in 9.2 because
it tells the user about his error.
Personally, I would question the wisdom of wanting to preserve
%else %then %do;
It should have been replaced when written or as soon as it was noted
that the code was not in compliance with the language.
In another message on the same subject Art writes in part:
SAS accepts all kinds of errors, such as numerous misspellings of
proc names and the previous example of code that doesn't conform to
the documentation.
If all of those incorrect examples all of the sudden produced errors,
many of us might end up with incorrect results on existing production
code, and never even know about it.
It is hard for me to understand how error messages should be overlooked
in production code when versions change. But then I have difficulty
with one putting code in production under previous versions particularly
when there are messages in the log indicating that an a procedure was
misspelled.
In the second message, Art also raised the issue of cost:
I have to disagree! Not with your explanation, but with respect to
the ultimate cost of such fixes.
When making a change in language behavior there is a cost two ways -
breaking old code that is still in use versus failure to improve the
language. Of course, the question of which cost is higher should be
decided on a case by case basis, but in general I would want very
good reasons for not improving the language. I don't think there
is a reason good enough when the code is not legal in the first place
and the "feature" involved has no use other than that someone took
advantage of it.
Ian Whitlock
