Programmability and scripting involve skills that lots of SPSS users don’t have. While some users might drop everything and plunge into this new world, others have a day job. What does programmability and scripting do for them?
There will always be a core group of users who can write programs and scripts for their […]
Programmability and scripting involve skills that lots of SPSS users don’t have. While some users might drop everything and plunge into this new world, others have a day job. What does programmability and scripting do for them?
There will always be a core group of users who can write programs and scripts for their own use. There will be a bigger group who could run programs and scripts written by others. Still bigger is the group who know only SPSS traditional syntax, and biggest of all is the group of point and click users. Being a point and click user should not exclude anyone from the benefits of these new technologies. I don’t subscribe to the school that believes that mastering syntax and programming languages should be the price of admission to statistical work.
Starting with SPSS 16 and continuing with SPSS Statistics 17, we have added solutions to let everyone benefit from the new technology. In version 16, we implemented extension commands. They let anyone create SPSS-style syntax that is implemented using programmability and scripting. Well, it’s entirely open, but you do have to write a little XML to define the syntax. That’s scary to many, but if you look at a few of the extension command examples on Developer Central (www.spss.com/devcentral), you’ll see that it isn’t that tough. Extension-command syntax written by the user gets checked by the SPSS Universal Parser and, if it conforms, it is passed to a Run function implemented in Python or R. More about the details of that another time.
With Version 17, we added a dead-easy dialog box tool, the Custom Dialog Builder, so an author can create SPSS-style dialog boxes to generate the requisite syntax. The syntax could be an extension command, or it could be built-in SPSS syntax, or a Python program, or an R program. Using this an author could make his or her own version of SPSS commands, perhaps with different defaults or different options, or he or she could extend SPSS using programs and scripts. These dialogs go on the standard SPSS menus, and they can have help that is accessed from the dialog Helpbutton.
The further an author goes in using these features, the bigger the audience that can use the author’s functionality.
My favorite example of this is the extension command SPSSINC MODIFY TABLES, aka
Utilties>Modify Table Appearance. This makes it easy to do complex formatting of pivot table output without writing any scripts. Until now, you had to write a script to automate fancy formatting beyond the static tableLooks. That’s not in the skill set of many SPSS users, and even for those who know how, there’s a lot of tedious coding involved. This new command and dialog can eliminate all that. Those scary programmability and scripting technologies make it easier to do your work – and that makes you more productive.
We give all this functionality away with the Base product. Are we crazy?