Art,

Please see embedded comments.

Ian Whitlock =====================

Date: Sat, 2 Sep 2006 18:25:40 -0400 Reply-To: Arthur Tabachneck <art297@NETSCAPE.NET> Sender: "SAS(r) Discussion" From: Arthur Tabachneck <art297@NETSCAPE.NET> Subject: Re: Macro vs user Comments: To: Ian Whitlock <iw1junk@COMCAST.NET> Ian,

First, thanks for the link to Marriot reservations. The following is a link to my previous post which I think contains all three of the original posts: http://xrl.us/rjfv

***Thanks for the correction, I have no idea what went wrong with the address.

I'm not going to defend the right of "users" to make use of SAS macros as, on this one occasion, I don't believe you've made a sufficient argument.

***You appear to contradict yourself below.

You also misrepresented Toby's example which was actually:

%Macro PrintIt( DataIn = ) ; Proc Print Data =&DataIn ; Run ; %Mend PrintIt ;

The fact that it required 34 extra keystrokes to code isn't the significant part but, rather, that it also requires the file name to be entered correctly every time it is run.

If, as a user I often print the file I've just worked on, it is much easier, quicker and less prone to errors for me to enter %print than it is to enter an alternative (other than an abbreviation for the above like the letter "P"). It also not prone to having the user enter an incorrect but valid filename and incorrectly think they are reviewing the correct data.

*** Toby's example did start with the code I quoted. I agree with Toby about the need for a parameter and didn't see any need to mention his improvement, since I thought it too simple to show his point.

When I mentioned key strokes I was taking that from your message (see your corrected address) with the comment after your macro stating that the macro saved valuable key strokes. The macro was

>AT> %macro Print; >AT> Proc Print; >AT> Run ; >AT> %mend;

In letters it cost the length of %PRINT and what was saved was

proc print ; run ;

If I am working in a mode where I need to see each data set and that is enough of a check, I use the View Table with a click, saving still more keystrokes and the ability, for example, to reach the 70th variable on observation 15,000 without waging though many pages of a print. So I am completely missing the value of your macro. However, if you find it valuable, you should consider making the code a keyboard macro to save even more keystrokes.

But then I think of asking for a print without qualifying the data set as working in play mode. In 25 years of working in SAS I do not remember a single mistake where there was confusion because of a wrongly written data set name, although I have misspelled the names on some occasions. On the other hand I do remember helping students and colleagues who came to me after getting into trouble by failing to qualify the data set name. Consequently it has been my experience that leaving out data set names is the bigger danger. In fact, one of the very first habits I developed when I started using SAS was to always use the DATA= parameter. ***

I don't at all question your comments regarding the uselessness of programs that don't correctly accomplish that for which they were intended, but I have seen many programs written by supposedly qualified "programmers" that don't meet that criterion.

*** Unfortunately you are correct that programmers also make mistakes. One of the biggest is the ubiquitous belief among programmers, "I cannot make a mistake." ***

Whenever I've had a "big" programming project, yes, I've contracted qualified SAS professional programmers. However, since they typically are not experts in the particular subject matter involved, I've found it most useful to provide them with a working, tested set of code that does what I need and asked them to restructure the code to ensure that it always provides valid results, in the shortest time, using the least possible resources and, hopefully, eliminating as much of the potential user error as possible.

However, that said, does one have to pass a particular test or attain a particular distinction before they will be "allowed" to use SAS macros? I don't believe that the SAS license contains any such requirement.

***No they do not. In fact, SI often provides the means to do unwise things.

From a business perspective, of course, valid results without overusing the company's or organization's resources is critical. But that is up to the individual (user or programmer), company or organization to ensure, not SAS and definitely not SAS-L.

*** I have never viewed SAS-L as controlling any company or organization in any way including the use of SAS. I do think of SAS-L as a place where individuals do and should express there opinions on best methods of coding SAS. So I would never attack your right to express the value of

proc print ; run ;

and a macro to save some of these keystrokes, however, I do not think that opinion should be left unquestioned. ***

My point? If one can "use" or "program" SAS to correctly and defensibly accomplish what they need, within the time and resources they are allotted, then it is simply wrong to tell them that they are unqualified or that they can't take advantage of all of the SAS capabilities unless they make their code more complex to meet particular "programming principles" is simply not justified.

*** I am not saying that you are unqualified in any way. But I am saying that some of your practices can be dangerous to others. In particular, I am saying that *in general* macros written by people with little SAS programming experience tend to waste time and breed mistakes both in the intended project and the programming development of the macro's author. *In general* means that I think each person should think carefully about any proclaimed advantage to writing macros before they have sufficient programming experience and consider all arguments against. That does not mean that you or anyone else has to follow any idea that I have expressed. In fact, you are at the end of a long line of people who do not take my advice. Some were happy, some were not, and most were not awake enough to know that they had made a choice. ***

Art ---------- On Sat, 2 Sep 2006 20:04:52 +0000, Ian Whitlock <iw1junk@COMCAST.NET> wrote:

>Subject: Macro vs user >Originally: Re: OT: RE: Select column names based on the column values >Summary: The case against user written macros >Respondent: Ian Whitlock > >An interesting question arose from the original topic because Toby Dunn >emphasized a non-macro solution. For a message containing what is >sumarized here, see http://tinyurl.com/gxp5 > >Jack Clark asked, what was wrong with macros without parameters, >latter saying that he used them all the time because they let him >use macro instructions. > >Toby replied mentioning design flaws in macro design, probably >because he liked the sound of the words and has recently written a >NESUG paper on the subject. He then offered a macro having >little to do with anything except for the fact that it had no >parameters. > >TD> %Macro PrintIt ; >TD> Proc Print >TD> Data = XYZ ; >TD> Run ; >TD> %Mend PrintIt ; > >Arthur Tabachneck responded with a simplification claiming it to be more >useful saving (11) key strokes > >AT> %macro Print; >AT> Proc Print; >AT> Run ; >AT> %mend; > >and justified this work on the basis that **users** need to save time >and thus programming principles should not apply. That is the >question and one he has raised before in less stark terms. > >In this case, I think the saving in time is very questionable. How much >time is spent remembering to use the macro? How much time is spent when >without titles one get's confused at what data set is reported? How much >time is spent when applied to real sizable data sets? How much time is >spent when someone else has to run the program and it fails for lack of the >autocall library? Moreover, I suspect that all these prints may lead one >to think the work is adequately checked. Then how much time is lost when >the program contains a mistake? > >In a big project somebody thinking about saving a few key strokes is down >right dangerous. I already question the validity of any sizable project >developed by **users**, but to add that they should write and use macro >code makes the validity of the result so much more questionable. > >Now let's look at Jack's question in terms of the macro solution he >presented to the original question. "In this I want to select all the >column names having minimum value of -100. can I use sashelp.vcolumn." > >JC> data test; >JC> input col1 col2 col3; >JC> cards; >JC> 23 40 30 >JC> -100 30 40 >JC> 25 -100 35 >JC> ; >JC> run; >JC> >JC> proc sql noprint; >JC> select count(*),name >JC> into :vcnt, :vnames separated by ' ' >JC> from dictionary.columns >JC> where libname='WORK' and memname='TEST' >JC> ; >JC> quit; >JC> >JC> %put &vcnt; >JC> %put &vnames; >JC> >JC> >JC> %macro chkmin; >JC> >JC> %do i = 1 %to &vcnt; >JC> >JC> proc sql; >JC> %if &i = 1 %then %do; >JC> create table keepcols >JC> (col_name char(20)); >JC> %end; >JC> insert into keepcols >JC> select "%scan(&vnames,&i)" as col_name >JC> from test >JC> where %scan(&vnames,&i) <= -100 >JC> ; >JC> quit; >JC> >JC> %end; >JC> >JC> proc print data = keepcols; >JC> run; >JC> >JC> %mend chkmin; >JC> >JC> %chkmin; > >First of all, it tests for columns with values less than or equal to -100 >rather than for columns with a minimum of -100. Of course, this may have >been what was wanted or it may not matter. Then it sends the column name >to the table KEEPCOLS each time the condition is met. Consequently there >can be many unwanted duplicates. It is rather inefficient because it loads >SQL and does a separate SQL statement (data pass) for each column. Say >there are 100,000 observation and 100 columns, that is ten million >observations to process. Since Art has placed the emphasis for using macros >on time, this may be the most important reason for not using macros unless >developed by programmers worthy of the distinction between user and >programmer. > >There is no reason why, the SQL step before the macro, should not be inside >the macro. In a complex system it would be important to make the macro a >complete package without polluting the global name space. > >I think there are several reasons why it is questionable whether **users**, >as opposed to programmers, should be writing macros to save time: > > 1) Concentration on simple SAS helps produce reliability > 2) Concentration on macro means missing the opportunity for many better > solutions - stunting growth > 3) Concentration on macro writing without adequate testing techniques > reduces reliability > >The only saving grace is that users tend to write small simple programs >where the costs may not matter to anyone but the user, unless other people >depend on the results and their being efficiently obtained. I suspect that >users never recognize the costs in terms of time and reliability of writing >one use code in throw away macros. > >Ian Whitlock