ADPの1周年記念特集のPart3です。『プログラミング言語の制御構造のいろいろ』ということで数回にわたって記事をアップします。ちなみに本日でちょうどADPの初回リリースから１年になります。
「なぜ、制御構造？」と思われるかもしれませんが、それはADP（Prolog）が持っている制御構造（バックトラック）が独特のものということと、JavaScriptやRubyにありますクロージャが本格的に普及してきて私自身が持っている制御構造に対する考え方（というか感覚）を変える必要があるので記事にしてみます。
制御構造とは
制御構造とはプログラムの流れ、広くはその命令（for文とかif文）を指します。制御構造を有名なものにしたのは、かのダイクストラ氏が提唱した構造化プログラミングがあります。今となっては『構造化プログラミング』という言葉を始めて聞いた人もいらっしゃるかと思いますが、『構造化プログラミング』が提唱された後に、今ではおなじみの制御構造文
・選択(if)
・反復（for,while等のループ）
が明確になりました。それまでの言語ではif文やfor文もありましたが充分でなく、本格的なプログラムの記述にはgoto文を使う必要がありました。そのれに加えてgoto文では様々なプログラムの流れを作ることが出来、流れの追いにくいいわゆるスパゲティプログラムというものもありました。私が駆け出しの頃（20年程前）にはよく可読性の悪いプログラムに対して『このスパゲティプログラムが～』という表現を聞いていました。
機械語ではどうしているのか？
なぜ、「機械語の話が出てくるのか？」と思われるかもしれませんが、制御構造の発展の歴史のルーツを探ることと、コンパイラ言語では制御構造が機械語に変換されるのでその仕組みを探るという意味で、続いて機械語の話をします。
機械語では初期のプログラミング言語のように比較文（if文）とgoto文のみで制御を行います。今となっては逆に難しいかもしれませんが、for文やwhile文がなくてもif文とgoto文の組み合わせでループを記述することが出来ます。
意外に思われるかもしれませんが、もう一つの制御構造文である関数呼び出し（サブルーチン呼び出し）も機械語にCALL命令という形で存在します。初期のCPUにはCALL命令がないものもあったらしいですが、今われわれが主に使っているパソコンのx86と呼ばれるCPUにもCALL命令があります。さらにx86の先祖をたどりますと、8080というパソコン用の8ビットCPUがありますが、そのCPUにもCALL命令があります（それから先は8008、4004とたどれますがこれらにCALL命令があるかどうかは不明です・・・）。
もちろんCALL命令が関数呼び出しとイコールではありません。CALL命令と関数呼び出しの違いは引数の受け渡しになります。CALL命令には引数の概念がありません。引数の受け渡しはレジスタまたはスタックまたはグローバル変数ということになります。C言語の関数呼び出しが機械語に翻訳されるるとCALL命令に翻訳されますが、その引数はスタックで渡されます。
続いては、公開1周年記念特集記事として『プログラミング言語の制御構造のいろいろ（２）』を書いてみます。
以前にも、震災関連で何かお役に立てないかと思いとりあえず
電力量表示アプリとかを作ってみたのですが、さらになにかないか思っていましたら、
Hack For Japanでイベントをやっていると言うことで、5/22のハッカソンに行ってまいりました。
もともと、5/21にアイデアソンがあり、そこでプロジェクトの内容を詰めて、5/22に開発を行うのですが、どこかのプロジェクトのお手伝いをしようと思っていましたとこで、朝にプロジェクトの割り振りがあり、ちょうど２人しかいないとのことで、『だじゃれくらうど』に参加させて頂きました。
軽いノリで参加したのですが、『だじゃれと言えば私でしょう！』ということで参加してよかったかと思います。
で、このプロジェクトですが、後で知ったのですが、ニッポン放送さんの
app10という番組との共同開発企画ということで、その後ニッポン放送さんにおじゃまして打ち合わせしたり、２７日のapp10に出演（予定）だったりと思わぬところでプロジェクトが進んでいます。
たまにこういう企画に参加しますと、いろんなエンジニアの方と交流し色々な技術的な刺激を受けます。
Twitterからデータを拾うのですが、TwitteｒのAPIって『何にそれ？』ってなノリだったので、勉強にはなり、それはそれで楽しかったりします。
まぁ、今は時間的に余裕があるだけなのですが・・・。どこまでお手伝いが出来るかですが出来る範囲でがんばります。
もっとも、ということでモックアップをADPで開発してたりします。
5/22のハッカソンの写真です。
以前からSourceForge.JPさんで、ドキュメント執筆者とテスト担当者を募集しているのですが、残念ながら良い人が来なくて、自己顕示欲の強いというか思い込みの激しい人が来て手間ばかりかかって結局ご遠慮頂きましたということでそのレポートを。
こんなことはわざわざ書かなくてもよいかとも思いますが、こちらもドキュメントを書いて欲しいため、チャットまでして説明した手間もありせっかくなのでネタにしたいというのもありますし、また変な人がこられても困るのでその予防線と、一応開発日誌と銘打っているブログなのでこういうマイナスなことも隠さずに書くのも面白いかと思ったので書いてみます。
その方（以下Aさんとします）は、某大手のIT企業に勤めているらしいのですが（わざわざご自身で大手IT企業と言ってしまうところはどうかと思ったのですが）、ご自身でもプログラミング言語を作成しているとのことで互いに勉強にもなるかとも思いました。
何回かメールでのやり取りで、簡単な自己紹介、技術概要、開発方針、ドキュメント作成のポイント等を説明し、チャットでさらに補足説明をしました。
で、ドキュメント作成を行わなければならないのですが、Aさんは片手間にしか参加できないとのことで、レビューをやってもらおうとその旨をお伝えしたところ、Aさんから
『後、気になっているのは(もしもですが)参加者がたくさん増えたときに大藤さんの心構えが実はできているか？です。』
とのコメントを頂きました。私はオープンソースに対する心構ができていないとのことなのですが、そもそも『心構え』ということが理解できなくて、真意を確かめることも含めてまずは今回はご遠慮いただく旨のメールを送りました。そうすると、
『確かにメール受け取りました。想定通りの回答です。』
で始まり、
『僕はオープンソースに上げてみようと思ったときに果たして他の人に触らせたり、色々言わせたりできるだろうかと言う質問を自分にしました。』
と来て、
『話をしていて、大藤さんはまだノーの様な気はしていたんです。』
『色々な人の意見を採り入れたいと言っていたが、まだその時期ではないのではと。』
と結論付けておられました。どう突っ込んだらよいのか困ったのですが、まぁ今回はご遠慮いただいてよかったかと思いました。
Aさんの勘違いを指摘しますと、私はADPをGPLで配布していますが、これは利用者が好き勝手にできることを私が認めたことになります。つまり、
『他の人に触らせること』
については私もライセンス上認めております。AさんはGPLをご存知ないのでしょうか。
また、『色々言われること』についてですが、実際にSkypeでAさんとチャットしているときも『Prologが解らない人向けのドキュメント作りを』と指摘されそりゃもっともだと思ったでのでSourceForgeのチケットにも登録しました。
もちろんですが、人の意見を聞きたいといっても、必然的に他の方の意見を取り入れる面と取り入れない面があります。その取捨選択はアーキテクトである私の仕事だと思っています。
もっともADPはプログラミングの初心者を対象としています。ので初心者の方の意見というは極力尊重したいです。ちなみにですが、PHPのようなお手軽な言語を目指しています。のでご意見どしどし受け付けています。
自分自身の若かりしころの反省も含めてITエンジニアの方にコメントしますと、他人とのコミュニケーションをとる上で相手の内面についての不用意な否定はやめた方がよろしいかと思います。Aさんは私に心構えという単語を使いましたが、根本的にオープンソースのプロジェクトをやろう！、という人間が心構えができていないことは、ほぼないです。
本当に心構えができていなくかつ教育が必要な新人を除いて、このような単語を使うことは相手を怒らせるくらいしかできません。もしくは相手から『こいつはコミュニケーション能力がない』と思われるでしょう。
これは仕事の面でもいえるかと思います。大手のIT企業に勤めていたら、出来の悪い協力会社の担当者に向かって思わず『やる気があるのか？』等、同様のことを言ってしまうこともあるかもしれませんが、そう思ったときはじっとこらえて『なぜ、私はこの人がやる気がないと感じたのか？』とじっくり自問自答しましょう。そのときに根拠となる理由が1つでは足りないですし、またその理由が思い込みではないと、確認する必要があります。
『僕はオープンソースに上げてみようと思ったときに果たして他の人に触らせたり、色々言わせたりできるだろうかと言う質問を自分にしました。』
『話をしていて、大藤さんはまだノーの様な気はしていたんです。』
私の話のどこにそう思ったのか不明ですが、私がソースをオープンにし、GPLでリリースした時点で、ノーということはありえません。このように多角的な検証が必要です。
相手を批判する場合（相手の内面の場合は特に）、思い込みで論理を展開しないで自分の考えを吟味する必要があります。さらに、相手の置かれている立場や考え方も考慮に入れましょう。
私も若かりしころ上司から、『口のきき方が悪い』と怒られたりしたことがありましたが、そのときは何で怒られたかよく解っていませんでしたが、おそらくAさんのように思い込みが激しかったのかもしれません。
最近では、あまりこういう面で他人から指摘を受けることもなくなっていましたが、今度は自分が指摘をする番になったようです。
OpenBlocks600の記事で紹介しましたブログビューアーですが、その後、バグ修正やRSS関係の対応をしてから1週間経ち、apacheのエラーログにもエラーが出ていないので、そろそろリリースしようかなと思いソースを眺めていたのですが、あまり教示的なソースでなく『公開すべきか、せざるべきか・・・』と悩んでおったのですが、こういうときは他人はどうしているのかと、最近のWEBアプリの動向でも探ろうかとネットを検索しましたところ、面白い記事を見つけました。
http://satoshi.blogs.com/life/2009/10/rails_mvc.html Ruby on Railsの「えせMVC」の弊害
http://satoshi.blogs.com/life/2009/10/ormappingmvc.html O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
ブログ主（Satoshi Nakajimaさん）の主張ですが、要するにモデルとコントローラの役割はきちんと分けようねということで、『ビジネスロジックをコントローラに書くのはNG』とのことのようです。
ちなみに私ですが、ちょい書きのアプリだとまぁコントローラでビジネスロジックどころか、SQLを書いたりします。またブログビューアーの構造も思いっきりMVCモデルから逸脱しているので・・・という訳でブログビューアーを書き直そうかなとか思ったのですが、もう少し調べてみようということで、以下、Rubyの作者のまつもとさんの記事を見つけました。
http://itpro.nikkeibp.co.jp/article/COLUMN/20080610/307218/ まつもと直伝 プログラミングのオキテ 第20回 MVCとRuby on Rails
この記事の
7ページ目の表2にRailsのMVCということで従来のMVCとの比較がありますが、その表から2パラグラフ目の説明を引用しますと
一方，HTTPの性質によってUI部分の複雑さはWebブラウザに任せてしまっているWebアプリケーションでは，相対的にUI層が薄くなります。コントローラ相当はほぼ汎用品で十分ですし，モデルとビューのインタラクションも不要です。ですから，モデルをデータベース層とビジネス・ロジック層に分割して，下層をモデル，上層をコントローラと呼ぶようにしたのでしょう。
ということで、まつもとさんの説によるとビジネス・ロジック層はコントローラに記述することになるようです。
かの有名なRubyの作者のまつもとさんが、このように言っておられるのでこの勝負は『Railsでは、ビジネス・ロジック層はコントローラに記述する』で軍配が上がりそうですが、実は先のブログ主さん（Satoshi Nakajimaさん）も知る日とぞ知る方で、過去にマイクロソフト社に勤務されておりWindows95の開発では、Windows3.1との互換性を保つために尽力されたらしく、そのあたりの話は
こちらで参照できます。また先の主張は、実際に
Ruby on Railsを使ったプロジェクト通して行き着いたようでしてそれなりに説得力があります。
このように著名なエンジニアの見解が異なる場合、どのように解釈すればよいのか悩ましいところですが、実行速度についてとか明確に白黒つく場合のように客観的に測定できる事実が無い場合、
『どちらでも良い』
というのが私の経験から来る見解になります。
この手の議論はエンジニアを引き付けるものがあり、熱くなったりするのですが、議論してもみのりは少なかったりします。
私も過去にこの手の議論に巻き込まれたことがあるのですが、特に個々のエンジニアが持つバックグランドが異なる場合、あまり前向きな議論にならなかったです。
今はインターネットがあるので様々なエンジニアの見解を比較することができるので、このように『他の人はどう考えているか？』というのをわざわざ議論しなくても解るので改めていい時代になったと思います。
というわけで、まぁブログビューアーは作り直さずに公開したいと思います。
チョット野暮用が入りADPの開発（というかブログの更新が）滞ってます。自慢にもなっていない記事をそのままにしておくのも何なので、ちょっとしたネタをアップします。
他人が作ったソフトウェアにバグがあったり仕様変更で改修したりする場合、新規で作り直すか、改修するかが議論になったりすることがあります。
良く聞く意見に
『バグバグでソースも汚いので新規で作り直しましょう』
というのがありますが、この『ソースが汚い』という意見ですが、往々にして主観が入っていることがあります。つまり、
その人のコーディングスタイルに合っていない→ソースが汚い
ということを言っている場合があり、この意見を鵜呑みにして新規開発の道に行くのは危険だったりします。
良くあるミスが、既存のコードに入っていたノウハウ（エラー処理や例外的な処理など）が新規開発で消えてしまい、却ってバグバグになったり、実際にはそう見栄えも良くなっておらず結局、工数だけかけたということになったりします。
新規なのか改修なのかというのはケースバイケースの面があり、あまり一般論では語りにくいのですが、私の場合、以下のルールで新規開発を行います。
- 既存のコードがある場合、基本は改修で行います。
バグがあるからとかソースが汚いという理由で新規開発を行いたくなりますが、その程度では新規開発はしません。
- 改修に工数が掛る場合、仕様を完全に把握できかつコーディングテクニック上ではなくパラダイムだったりアルゴリズムが元のコードよりも有効なものが使える場合、先ずは関数レベルから置き換える。
オブジェクト指向を使っていないコードにオブジェクト指向を行ってみるとか、サーチアルゴリズムを別のものに入れ替えるとか、if文の条件が複雑だか良く見ると簡単にできる場合に簡単にするとか、コピーペーストしているコードで共通部分を関数にするとかです。
- 出来ることならテストプログラムを書き、デグレードを防ぐ。
- 徐々に改修するコードを広げてゆく。
とまぁこんな感じでやってます。
ちなみに、自分が過去に作ったコードは結構大胆に書き換えたりします。自分が作成したものの場合、1回目より2回目の方がソースが綺麗に書けるということと、『仕様を完全に把握している』という条件をクリアしやすい為です。