高速道路のたとえ

これまで携わっていた仕事上のプロジェクトも、そろそろ終わる。
この仕事では、プログラム設計(詳細仕様)を検討するときに、途中からHaskellでプロトタイプを書くということをやってみた。
最終的にはC++のコード設計を提供する必要があった。とはいえ、実現方式を検討する手段としては、なかなかよかったと思う。

Haskellくらい短く書ければ、見通しもよくなる。
短ければ、物理的にコードを書く負担もそれだけ少ない。
改善や修正のための書き直しにしても、それだけ気楽に大掛かりにできるようになる。
リファクタリング効率は改善される。
そのうえ、Haskellは擬似コードのような単なる仕様記述言語ではなく、それ自体が実行可能なコードでもある。
C++で書き直す前に、Haskell版のコードを動かしてみれば、間違いがないかを確認しながら進められる。
要するに、検証可能なスケッチとしてHaskellを使ったのだ。

C++で始めるにしても、いったんHaskellで考えて、それをC++に戻すというやり方をしたことになる。
これは、全行程を通常道路で行くかわりに、高速道路を使うようなもの。
高速に乗って通常道路の速度制限を取り払い、短時間で目的地に近づいてから、インターチェンジで通常道路に下りる。そんなイメージになぞらえられる。
別なたとえを出すなら、超空間にジャンプすることで通常空間での光速の壁を越えるSFでいうところのワープ航法に相当する。ちょっと大げさか。

Haskellによるプロトタイプを使ってみての、いちばんの問題。それは、Haskellで出来上がったプロトタイプをC++に着地させることだった。
Haskell版が楽な分、C++に書き戻すのは苦痛になってしまう。
書き直しは、単調さが鼻につく感じが否めない。
メモリ管理や型検査、変数宣言をいちいち書いていくわずらわしさ。
ついうっかりコンパイルエラーや実行時エラーを引き起こしてしまいがちだ。
そのたびに、それを見つけて修正しなくてはならない。
テストコードまでがC++版では膨張してしまう。その見苦しさ。

まだしもJavaやC#であればGCを前提にできる分、多少は楽だったろう。JavaやC#ならヘッダファイルと実装ファイルを分けなくても実装が隠蔽できる点も、無視できない。
それでもSTLを使えただけでも、Cよりはましだったはずだが。

なにもHaskellでなければならないわけではない。
Concurrent Cleanでもいいかもしれない。(微妙だが、僅差でHaskellを支持。商用利用に対するライセンスの違いも影響しているかな。)
とりあえず今のところ、いちばん簡潔に違和感の少ないコードが書けるから。
かくして、Haskellへの愛着が強化される。
(もっとも、Haskellを使いこなすには、ほど遠いとはいえ。)

本来なら、こういう機械的な作業はもっと自動化するべきだろう。
Haskellから自動的にC++に変換してくれるようなツールがないかと探してみたが、残念なことに見つけられなかった。

これは今後の課題かな。