LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (December 2010, week 5)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Wed, 29 Dec 2010 18:35:54 -0500
Reply-To:     Arthur Tabachneck <art297@ROGERS.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Arthur Tabachneck <art297@ROGERS.COM>
Subject:      Re: Fun With SAS - My Vote for Oddest SAS Programming Language
              "Feature"
Comments: To: Paul Dorfman <sashole@BELLSOUTH.NET>

Paul,

I totally agree, but also wish that SAS would actually create some extra functions, based on the ones you mention, but with with each being limited to accomplish basic functions.

E.g., A lot of confusion would have been avoided over the years if a REORDER function existed that was really just an extremely limited version of RETAIN.

Art ------ On Wed, 29 Dec 2010 18:12:19 -0500, Paul Dorfman <sashole@BELLSOUTH.NET> wrote:

>Mike, > >I would vote for RETAIN and LAG/DIF, as in my opinion, both are misnamed, >which alone has fostered endless heap of confusion in generations of SAS >programmers. > >Since RETAIN is a negative compile time imperative, I would rather have the >instruction name start with a negative prefix, say, NOSETMISS, NOAUTONULL, >etc., even if such neologisms roll off the tongue much more awkwardly than >RETAIN. An oddly shaped keyword is a lesser evil than countless neophytes >scratching their heads asking what the heck the statement tells SAS to >retain. > >Likewise, if LAG had been called QUEUE, a great body of SAS confusion could >have been avoided - both primary (based on not reading the documentation and >instead trying to ascertain the workings of LAG by code cannibalization), >and secondary (based, for example, on misguided recommendations to avoid >using LAG in conditional clauses and such). Perhaps it would be even better >if the functions were called something like QUEUEVAL and QUEUEDIF (or maybe >just QVAL and QDIF) - at least then no nonsensical impression would be >imparted that the functions have anything to do with the "current" and >"preceding" observations. > >And, on the seasonal note: Happy New Year, everyone! > >Kind regards >------------ >Paul Dorfman >Jax, FL >------------ > >On Wed, 29 Dec 2010 08:39:58 -0500, Michael Raithel ><michaelraithel@WESTAT.COM> wrote: > >>Dear SAS-L-ers, >> >>Each and every one of us who eats, drinks, breathes, sleeps, and dreams SAS >programming has one. It's that one feature of SAS that we think is kind >of... is very... is somewhat... well, odd. It could be an option, a format, >an informat, a function, a call routine, a statement, a PROC, etc. but it >exists and we scratch our heads and wonder why. >> >>If you can relate to this, let the list know your own vote for the oddest >SAS programming language feature. >> >>Here is one of mine: >> >>The EXCHANGE statement on PROC DATASETS swaps the names of two SAS data >sets. So, if it were executed against NEWFILE and OLDFILE, the name of >NEWFILE would be changed to OLDFILE and the name of OLDFILE would be changed >to NEWFILE. Consequently, the names of the two files would be exchanged. >And, it would happen in the flashing blur of a nanosecond! >> >>Here is an example: >> >>proc datasets library=work nolist; >>exchange newfile = oldfile; >>run; >>quit; >> >>In this example, we exchange the names of the NEWFILE and OLDFILE data >sets. The contents of each data set remains the same; it is just that they >got a name change. >> >>The EXCHANGE statement always reminds me of the Metamorphosis Illusion >(http://en.wikipedia.org/wiki/Metamorphosis_(illusion) ). I think that in >the unlikely event that I ever use it in one of my programs, I will watch it >very, very closely to see if I can discern exactly how the trick is done:) >> >>Happy New Year to one and all! >> >>I hope that this suggestion proves helpful now, and in the future! >> >>Of course, all of these opinions and insights are my own, and do not >reflect those of my organization or my associates. All SAS code and/or >methodologies specified in this posting are for illustrative purposes only >and no warranty is stated or implied as to their accuracy or applicability. >People deciding to use information in this posting do so at their own risk. >> >>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>Michael A. Raithel >>"The man who wrote the book on performance" >>E-mail: MichaelRaithel@westat.com >> >>Author: Tuning SAS Applications in the MVS Environment >> >>Author: Tuning SAS Applications in the OS/390 and z/OS Environments, Second >Edition >>http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=58172 >> >>Author: The Complete Guide to SAS Indexes >>http://www.sas.com/apps/pubscat/bookdetails.jsp?catid=1&pc=60409 >> >>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>One man's "magic" is another man's engineering. "Supernatural" is a null >word. - Robert A. Heinlein >>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Back to: Top of message | Previous page | Main SAS-L page