感化

最近cとか(よりCPUに近い表現をできるという意味で)低位な言語を触っているとc#やpythonなどの(より抽象的で人間の思考に近いという意味で)高位な言語で随分と楽をしているなあと感じる。
pythonのジェネリックなlistやc#のenumerableなLINQ( to object)はちょっと触りだすともはやいかにループを書かずに処理を進めるかに注力してしまう麻薬のような存在のように思う。　c.f. https://qiita.com/memakura/items/6b3e6e06eae51725fd5d
c#のバージョンが上がって3.0になった2008年ごろにLINQが言語仕様に含まれるようになって馴染むのにそこそこの時間を有したが今はいかにLINQに向いたリストを用意するかとかデータベースのORMを用意するかがシステムの保守性に大きく影響を与えるようになったとも感じる。

そもそも自分がよく書く小さな組織向けのシステムでは基本となるデータ構造こそ決まれど実際の処理はしばしば顧客のビジネスの都合で変更される。
その変更を受けれるのにaccessのVBAは実に便利な存在でベースとなるデータ定義、各画面や帳票で共通に使われる処理部品、そしてその画面内だけで有効な処理を封じ込めるのにそれぞれの要素が程よいバランスで存在していたと思う。
（Excelもかつてはシート毎のVBAが今よりも記述しやすくて小さな仕組みを書くのがたやすく感じたが最近はVBAの記述を汎用モジュールの側に書かせようと誘導されているようで窮屈さをかんじる、特にマクロの入ったワークブックの拡張子すら分けるようになり心理的なハードルも上がった）
そのaccessのVBAも前バージョンの機能を他の客用に残したままで特定の顧客用にシステムをカスタマイズするときなどに不便さを感じるのだが・・・

最近はExcelのブックを特定のフォルダ内を渡り歩いては条件に合うものを探して処理するような記述をする案件をいくつか扱ったがサンプルデータでは遅く感じなかったものも実現場では耐えられない速度なのかもしれないと薄氷を踏む思いなのだ。
記述性を考えるとCOMを経由してExcelのブックを実際に開くような処理を記述するよりもpythonなどでopenpyxlを使って書くほうが直接ファイルとしてのexcelワークブックを取り扱うという点で処理速度の面でもメモリーの占有の面でも有利かなって感じている。
同じことはc#にも言えてclosedmxlライブラリーをつかえばexcelワークブックをCOMを経由せずに自由に扱える。(ただし上記のそれぞれのライブラリーは対象がxlsxなので古い拡張子xlsのファイルについては保存しなおしが必要になる。)

せっかくこれらのライブラリーを自由に選択して使える立場にあるのだからこれまでのaccess(もしくはexcel)のvbaを用いてCOMで裏でexcelを使う方式と速度や書きやすさの点を比較してみるのも面白いと感じる