【GNU Visceral C Compiler(GVCC)】の提案……というか、ハンドコーディングによるプログラミングの「無理・無駄・ムラ」ってなんだろうか?ということについて思考してみるテスト。

 今日のscim_anthy_nicola.cpp……に関連して。
 ええと……cvsから拾ってきたscim_anthy_nicola.cppの1.34にて、なぜか「同じ関数」が2つあるような……。


 それと、これは泣き言のほうなのだけれど……「#include」って「そのファイルに対してincludeする」ということで親ファイルには定義されているけど、定義「される側」にはこういう情報が書いてないんですね……当たり前なのだけれど。
 【このファイルからincludeされています】というコメント、(プロジェクト内のファイルに限る必要はあると思うけど)プリプロセッサなどで付加できると良いような気も(人力で付けると整合性が取れないので、それはするべきではない気がする)。
 ソースをgrep/explorer検索などすれば"scim_anthy_nicola.h"がincludeされているところはすぐ見つかる(→scim_anthy_reading.h)のだけれど、何かもっといい方法があるような……。


 うーん、「プログラムを組むとき」に毎回思うのだけれど、「3日前のプログラムは他人のプログラム」という状態が、どうして発生するのか……というところは重要なことなのかもしれない。
 プログラムを毎日触っているときには「どのステートが何をしていて、どういう風に関数なり処理なりが絡み合っているのか」をすぐに思い出すことができる、と。
 そして、数日触っていないと(忘却曲線に沿う形で)それが思い出せなくなってきて、最終的には「全く読み取れない状態になってしまう」と。


 一度概念が吹き飛んでしまったプログラムを読み直すのは、他者が書いたプログラムと同じで「全文読む→構造を理解する→挙動を理解する」というステップを踏まないと再理解はできないのだけれど、個人的にはこの「再理解」というプロセスが【ハンドコーディングによるプログラミング作業における「無理・無駄・ムラ」を3つとも含んでいる】様に思うのです。


 プログラムをズバッと読解出来る方から見れば【は?馬鹿じゃねーの、それをすぐに読み取れてこそプログラマだろ。ソースは唯一の仕様書で、かつ唯一のコトバだ。】と笑われるだろうけれども……。
 生産業務*1に関わってきた私から見ると、このソースの読解という作業は【プログラムを改変しようとする際に、必ず先立って行うプリプロセス】である様に見えるわけで、何らかの工夫を積み重ねていくことにより「そのプリプロセスはほぼ除去することが出来る」のではないかな……と、そう希望を持っていたりします。


 とはいえ、私はプログラミングに関する知識など「ないに等しい」ワケで。
 MS-DOS時代にはバッチファイルを書いたり、N88-BASICをちょっと触ってみたり、JGAWKで一行野郎コードを書いたりした事はあるのだけれど、言語構造の根本的な仕掛けは理解していないんですよね……。


 【読解力のあるなしに関わらず、誰が見ても同じ時間でプログラムの内容(関数類の相関関係とか、動作の仕様とか)が理解できるようなシステムを構築する】ことが、今後のプログラミング環境における生産性を一気に引き上げるために重要なのかも?と。
 こういうシステムは「コンパイラ」「プリプロセッサ」「システム関数」などと密接に関わっているので、基本的には「コンパイラを設計できる人でなければ構築できない」のかもしれないですけど……。


 ……ええと、誤解を承知で書くならば、「現状」と「理想」のプログラミング環境というのは、これぐらい乖離しているのかもしれない。

  • 【現状】
    • (BASICで言うところの)Line命令を使って線を引き、配線図を設計する。
  • 【理想】
    • 回路シミュレータのLTSpiceを使って線を引き配線図を設計する。
      • デバッグは「シミュレーション」モードで回路を動作させ、マウスカーソルをあてれば「実際の回路にプローブをあてているかのように」動作状況が把握できる。

 スクリプト規模のプログラミング環境や、エミュレータといった分野では出来ていそうなこと……それを、「一般的な大規模開発で使われている言語系で実現すること」ができれば、「(ソースをアイボールサーチすることと同じ精度で、かつ)すぐに動作を理解できる」ような気がしていたり。


 それこそ、たとえば【GNU C Compiler(GCC)】に対する【GNU Visual C Compiler(GVCC)】……じゃなかった、【GNU Visceral C Compiler(GVCC)*2が、今後必要になるのかもしれない。
 #【Visceral ○○】の「○○」には、今あるどの言語/コンパイラでも当てはまるような気はする。
 極端な話、こういう方式を取ってしまえば「多言語(無言語?)表示型プログラミング」とかいう事も出来そうな気はするわけで。


 うーん……単なる放言しか出来ない自分の現状(理解力のなさ)に意気消沈していたりorz。
 #あっ、ばかげた話だということは重々承知していますので……「さそり座の女(@美川憲一)」ばりに【気が済むまで笑って良いですよ】という感じです。

*1:というか、インダストリアル・エンジニアリングごっご。

*2:直訳すれば「直感的なシープラスプラス」だろうか?