Date: Mon, 24 Nov 2008 13:17:28 -0600
Reply-To: Mary <mlhoward@avalon.net>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Mary <mlhoward@AVALON.NET>
Subject: Re: (optionally) ending a process after sql
Content-Type: text/plain; charset="Windows-1252"
A GoTo! As author of a book in 1987 on IBM PC Basic, I demonstrated that
GoTo's could be used to imitate the structures of a DO or IF statement, but that
does not necessily mean that I would recommend them to someone whose language
contains a better structure!
I think the problem in computer programming lies in the fact that many programmers
do not receive formal training, or mentoring after training, that teach such programmers
how to program correctly. I was fortunate that my first job out of college was to
teach computer programming at a community college for 5 years, and thus I did get
a foundation on how to program correctly, but I think many programmers jump into
the field without any foundation whatsoever, and it is this lack of foundation, rather than
the existence of tools, that causes problems like out-of-control macro use, not the tool
itself.
However, I spent many years programming in SAS without using macros at all (basically,
if I wanted to do a problem like this I would comment out the code, and then uncomment it
and run it only if it was appropriate :-) ). This is a good foundation, but really doesn't
work as well in today's environment, where the automation of data entry has led to an explosion
in the number of variables, and thus to a need to automate various runs.
Perhaps as a statistical programmer dealing with thousands of genetics variables, I'm more
aware of this than other types of programmers. Indeed, as tanwan specifies below, I'm aware
that in statistical programming, multiple lengthy code may follow, not just one statement, and
that led me to the solution that I offered. Also, I really do find "call executes" to be horribly
confusing, much more confusing in my mind than macros are!
****
A macro is a tool, and like any other tool, the skill in using it is the key. I think of my garage.
The first owner, in 1964, apparently got a power drill for Christmas. He went crazy on shelving
in the garage, putting up shelving all over. But he used cheap plywood, didn't paint, and so 35 years later,
all the shelving looked terrible. Since I bought the house 10 years ago I've been trying to
take it all down, but have had to deal with screws everywhere, so it's a tedious process.
So should we ban purchases on power drills unless you've got a carpenter's license? Advertising?
Clearly the answer is no. But figuring out how people can gain common sense to not use tools
beyond their skill level would be helpful, or even that gaining skill level is as important as getting
more tools.
-Mary
----- Original Message -----
From: tanwan
To: SAS-L@LISTSERV.UGA.EDU
Sent: Friday, November 21, 2008 8:52 PM
Subject: Re: (optionally) ending a process after sql
Interesting discourse this is.
Let's recall that the original poster wanted to do EITHER proc means
OR “any other code thereafter” although I am not his spokesman. So in
my opinion, the solution proffered should be as generic as possible.
It should be able to do a proc means, or run some other lengthy code
(e.g. do another statistical analysis). Not necessarily do a one-liner
piece of SAS code.
Nonetheless, using a Macro or SQL or whatever is as personal as it can
get. It all depends on personal proficiency, knowledge level and
skill. Besides, computer programmers in all languages are known to
show off with sexy code than use pedestrian syntax. I guess this is as
old as the profession itself.
It is just like eating fast food simply defined as a soda, a burger
and fries. Do you eat the fries first? Or do you match and mix: eat
them as the same time as the burger? Would you like your burger with
cheese? What about the soda: what flavor do you prefer? Do you eat
first then drink the soda after or do you eat and sip at the same
time?
Having said that I am even surprised no one has suggest the %GOTO in
the macro as used in http://www2.sas.com/proceedings/sugi29/126-29.pdf
