Frank Morgan, in the play The Band Wagon says, if you are lost in the Arctic and haven’t seen a soul for days, take out a pack of cards and start playing Solitaire, and soon you’ll be surrounded by kibitzers.
Another method might be to start writing a book on learning SAS. Pretty soon, you’ll be surrounded by other SAS training experts who will coach you on what to write about.
Ron Cody isn’t lost in the Arctic, however, and really doesn’t need any help finding his way around and out in Learning SAS by Example: A Programmer's Guide, Second Edition. All that I, as a reviewer, can possibly do is to make some minor adjustments to his snowshoes.
First, the clearly positive aspects of Ron Cody’s book. The name “Cody” gives the whole game away. Nomen est omen. He knows SAS code inside out and top to bottom. I’m a SAS trainer with many years of programming experience and nevertheless learned several new coding features from the book. For example, the AUTONAME statement in PROC MEANS was new to me.
True to its billing, Ron Cody’s book contains details that experienced SAS users may find helpful. Base SAS is a work in progress, and we all need to keep up with its detailed changes and enhancements. The book does a good job in highlighting some of them. The discussions of MEANS and FREQ are excellent in that regard.
Last, but not least, congratulations to Ron Cody for including PROC REPORT. Why hasn’t it been covered in SAS training materials?
What about the book’s utility for beginners and people with only a little experience? Here is where I think the book could benefit from a small amount of additional material and insights to orient new SAS users in broader contexts.
As written, “Learning SAS by Example” follows the traditional structure of SAS training content, starting with reading raw data and using the INFILE statement. Is this good or bad? This has become a controversial topic, and many people believe it’s an outdated topic and shouldn’t be part of SAS training.
The book could defend its inclusion by pointing out that this data access technique is contemporary, not ancient history. Why? Look at how it can be used to read Hadoop data! What could be hipper and more up to date than that? I’ll mention context again below in connection with the chapters on additional languages.
Many other short, supplementary comments could help new users. Here are only a few random suggestions:
1) SAS dates are based on a “thermometer” that uses a “freezing” date of January 1, 1960. All dates are above or below freezing.
2) The WHERE statement is efficient – reads in only selected records.
3) The SET statement reads data one record at a time and the code that follows it is applied to each one.
4) How SAS as a 4GL makes programming less of a chore. For example, no OUTPUT or RETURN statements needed. The DATA step is an automatic loop.
5) CNTLIN building a format is great for automation of a process and keeping it up to date.
6) Mention that it’s possible to read only those rows and columns of an Excel sheet that contain data.
These are all snowshoe adjustments.
Separate short chapters on MACRO and SQL follow the conventional SAS training structure. These topics require much more than a sip. They could be mentioned in another context, however, as they are examples of the polyglot nature of SAS. SAS speaks many languages and interoperates with more and more software. Most recently, SAS has been demonstrating its compatibility with open-source languages. The book ought to mention this evolution.
In conclusion, Ron Cody has used excellent judgment to balance depth of the presented material with accessible insights and useful techniques. Some chapters may be a little too compact, but overall the book keeps the information overload polar bear caged up.
Jim Sattler, President
Satmari Software Systems, Inc