I do a lot of work with SAS macro. I use it daily, but I must admit, I find the resulting code kludgy and ugly. Being able to write code that writes code is indeed powerful, but it comes with a cumbersome price: all those % signs, ampersands, the semi-colon that will sometimes get gobbled up by the compiler, local and global symbol tables, %sysfunc() to get to base functions, all those wacky quoting functions %NRBSTR( aaaarrrrrgggh! ), limited debugging, etc etc etc.
Plus, I have met many, many otherwise competent programmers that just can't seem to quite _get_ full scale macro programming. Like pointers to pointers in C, at some point the thread just unravels.
Now don't get my wrong. I think macro is a valuable skillset, and has a valuable place in your programming toolbox, but for large, complex applications I am always thinking there's got to be a better way.
SCL comes to mind. You can use it to write base sas code to the program stack just like macro, with the added benefit that you can manipulate and recall the stack. Imagine getting to recall all the base sas code that your big complicated macro produced instead of having to parse your log. There's other benefits too: built in data types arrays and lists; SCL debugging and compiling; much cleaner syntax, and clearly defined submit blocks; variable locality using declare, just to name a few.
So does anybody use SCL this way? I've been thinking about it for a while, but I haven't yet. Using SAS catalogs instead of text source files would be a drawback for me. Are there any other drawbacks?
Maybe those programmers that don't get large scale macro programming just have more attuned programming sensibilites than me. They see all those %'s and &'s and their refined programming brain wanders away in disgust. Maybe I will code my next large application in SCL from the beginning instead of turning to macro out of habit. But old habits are hard to break.
Google SAS Search
Monday, March 07, 2005
Kicking The Macro Habit
Subscribe to:
Post Comments (Atom)
I have to disagree with the suggestion to use SCL in place of macros. To me, SCL is more difficult to figure out and get to work properly than macros are. Although I agree that SCL code is more "aesthetic" than macro code, I think the functionality of macros is extremely valuable to me, and once you climb up the learning curve, nothing else will suffice. I doubt that SCL can provide the flexibility and capability of macros. Maybe someone can show me how to use SCL as effectively as macros, but I am skeptical. Until then, macros rule!
ReplyDeleteYou made your points against using macros very clearly. You did it very humorously, too -- especially the %NRBSTR() function part.
ReplyDeleteHas anybody else got the jokes, though? Here is my take on it:
Joke 1: there are no such macro function in sas.
Joke 2: the name of the macro "argument" is a pun: "aaarrrrrggh!"
Uh oh, it looks like I made a little mistake. I was thinking %NRBQUOTE() instead of %NRBSTR(), which doesn't exist. I hate making mistakes, but I'll always take credit if there's humor. Now I feel bad that I didn't intend the joke. So here's a joke to make it up. It's not a particularly good one, but it is a classic:
ReplyDeleteThere are 10 types of people in this world. Those who undertand binary numbers and those who don't.
Har har har har!
And just for the record, I don't really want to insinuate that macros shouldn't be used. Paige brings up a good point. If a tool is extremely valuable to your work, why change it? For some things though, I believe macro is over-used and other tools can do the job; maybe better.
Which brings us to C#. I think this is very interesting, if and only because it likely drives any future maintanence SAS programmer crazy to inherit it! But programming is learning and it never stops. I use Visual Studio for C++ and I imagine it must give you a powerful programming environment to develop C# to gen SAS. I haven't looked into it yet, but I just might now!