memo/20120307

自分の理想のプログラミングスタイル

以下の概念をあわせると、自分の理想のプログラミングスタイルになる。

• 好き勝手に new/delete しない、GCしない
• コルーチン
• node.js のようなイベントドリブン発展系
• Linda

下記のような「クラスっぽい何か」をグラフ構造でつないで計算処理を行う。
グラフ構造上の各ノードは、フィルタ的に「入ってきたら何か出す」方式で動く。まぁ全員常駐だな。

名前空間の宣言

クラスっぽい何かのくくり:
{
  インスタンス変数の宣言とか定義とか。

  コンストラクタ的なこと:
  {
  }

  デストラクタ的なこと:
  {
  }

  何らかのタスク的なことその1:    //パブリック
  {
    このタスクと、生存期間が同じオブジェクトの生成宣言

    イベント処理その1: 起動タイミング指定と入力データの指定を書く  //プライベート
    {
      ローカル変数、
      順列、繰り返し、選択分岐 によるいわゆるノイマン型計算機プログラムと、
      タイマ、もしくは入出力に対する イベントハンドラ登録 処理。
    }

    イベント処理その2: 起動タイミング指定と入力データの指定を書く  //プライベート
    {
      同様
    }
  }

  何らかのタスク的なことその2:    //パブリック
  {
    同様
  }
}

つまり、メソッド内にコルーチンがいっぱいある。
外からイベント処理ルーチンとして登録できるのは、メソッド単位。つまりメソッドはpublic。
コルーチンは、内側からならイベント処理ルーチンとして登録できるが、外からは登録できない。つまりコルーチンはprivate。


好き勝手に new/delete はできない。
けど、「配下に子データ構造を持てて、増やしたり減らしたりできるもの」(コンテナ)は、書ける。
例えば、そいういう、コンテナクラスの宣言には「言語レベルのキーワードをつける」とかして、普通のクラスと、コンテナクラスは明確に分ける。

この案の背景

初期にオブジェクト指向を考案した人たちの頭の中には、

構造化プログラミングだと、
関数の"スコープ" が、実行の単位、かつ オブジェクトのライフタイム になっちゃってるじゃん。
それはイヤ。
オブジェクトのライフタイムと実行の単位は違うものなのだよ

という考えがあったと思う。

言いたいことは、痛いほどわかる。んだけど、

最近、特に Java、Android界隈で流行っている、λ関数の出来損ないみたいな、「new HogeHoge を処理の途中に書くスタイル」は、

ソフトウェア工学の発展（＝大規模ソフト開発を設定コスト内・期限内に完了し、誰がプログラムをいじっても"手がつけられる品質"を保てるよう、ソフト開発技術を工夫し高めること）に、寄与しないと思う。

はっきり言うと、上記のスタイルは「手がつけられなくなる危険なにおいがぷんぷんする」ってこと。

node.js もそういうスタイルに寄っているのは知ってる。そっちへ行っちゃダメだよ。


だけど、「オブジェクトのライフスコープと処理の流れが同じ」だったら、それって構造化プログラミングと同じ。
構造化プログラミングの闇を避けるため、今のプログラミングスタイルは new や delete 、そして GC なんだ、となってるけど、

そうじゃねぇだろ、と。


年寄りの俺らが上記の「λ関数の出来損ないスタイル」で仕事してたら、若くて新しくこの業界に入ってくる、迷える子羊たちが、

new しまくりで、GC に頼りきりで、言語系がいつ delete すべきなのかを明確に決定できないような、「速度要件を満たさない」バグの対策、つまり「逃れるはずだったオブジェクト解放にまつわる困難」に追われて、泥沼にはまって、徹夜する羽目になって、女房子供を泣かせてしまうような、

そんなプログラムを書くようになっちゃう。


オブジェクトのライフサイクルも、プログラムソース上ですっきり見えなきゃだめ。
だけど、その途中で処理が抜けられる仕組みがないと、マルチスレッド地獄になる。それもダメ。

だから、タスクの括りの内側に コルーチンを書けばいい。

それは、"Linda" で、「タプルスプールに欲しい情報が入ってくるのを待つ」のと同じ。

と。

リンク	備考
インターフェイスの街角 – 並列プログラミング	増井俊之 先生のUnixMagazine記事アーカイブ。Linda が分かりやすく解説されてます