SASのクソな部分シリーズの第4回目です。
今回はSASの拡張性について考察します。
ユーザーによる機能拡張はほぼ不可
まずSASはサードパーティー製のプラグインやパッケージはほぼ利用できません。
SAS/GRAPHやIMLのように機能追加は可能ですが、当然別ライセンスを取得する必要があります。
Rやpythonのように後から機能追加は気軽にはできません。気軽にできるとしたらはSASマクロくらいでしょう。
実際公式でもSASマクロを公開していますしね。
正確にはユーザー側でもプラグインの作成、導入は一応可能ですが、実務上では結構難しいのかなと感じています。
例を挙げると、LCA(潜在クラス分析)を実行するプロシジャを追加できるProc LCA, Proc LTAがあります。
このプラグインはSASマクロではなくプロシジャを追加することができます。中身はdll形式となっており、SASのシステムフォルダに保存することで利用できるみたいです。
このプラグインはシステムフォルダをいじることになってしまうので、実務で気軽には使えませんね。バリデートされたシステムに新たな機能を追加することになるので、
再バリデーションを実施することになるのかな？潜在クラス分析はRのパッケージがいくつか存在するので、SASシステムをいじるくらいならRを使って解析したほうが早いでしょうね。
現在デフォルトのSAS statシステムでLCAを実行するプロシジャはないらしいので、SAS社がこのプラグインを正式に追加してくれれば超便利なのですが・・・。もう１０年以上も前に開発されたプラグインなのだからそろそろSASがサポートしてあげてもいいじゃない。
このようにSASシステムのアップデートはSAS社の匙加減次第であり、ユーザーが自発的に機能拡張するのは敷居が高すぎるため、他のソフトウェアと比べて最新のトレンドには疎いです。逆にいえば安全性が高いともいえますがね。でも論文だってあるし、SASユーザー総会なるものをやっているのですから、アップデートの参考になる情報はたくさんあるのにもうちょっとなんとかならないんですかね。。。結局Rを使ったほうが良いという話になります。
PDVという独自仕様
さらにPDV（program data vector)というSASの独自仕様も機能拡張にとって障害になっていると思われます。
PDVについては公式のドキュメントが詳しいです。要はデータを一行ずつメモリ上のPDVに展開し、処理を実行後出力する工程を繰り返します。
行ごとにLoop処理を実施しているため、データ行が莫大だと処理に時間がかかります。SASでは並列処理も可能らしいですが、SQLとかCでコンパイルされているため高速に動作するPythonのnumpyのほうが大規模データ処理に向いている気がします。だいたいpythonのほうが導入コストが安いのでその分サーバーにお金かけられます。
一応DS2プロシジャなる次世代データ処理ステップがあるのですが、これ実務で使っている人いますかね？担当者全員にこれを習得させるだけのメリットがあるとはとても思えません。結局のところDS2使わなくても解析自体はできますし、新たに文法を学習するくらいなら利用実績の多い別言語を習得したほうが建設的な気がします。
さらにSASには他のプログラミング言語に存在する配列、ディクショナリー、タプル、といったデータ形式は存在しません。すべてのデータは基本的にデータセットに格納し、その中で演算処理などを行う必要があります。なのでpythonやRで組まれたプログラムをSASに移植するのは大変でしょう。
先輩から「SASのプログラミングスキルを向上させる方法は、他言語を習得することだ」と聞いたことがあります。
SASだとできることが限られるし、一般的なプログラミングのお作法は身につかないので、他言語を習得したほうが応用できる幅が広がりますし、プログラミングの理解が深まるからだとおもいます。実際luaとかsqlを使ったほうが利便性が高い事例は意外と聞きます。
結論としては、SASの勉強はほどほどにして他のプログラミング言語や英語を勉強しましょうということです。
