AIについて考えると自動整形や形式手法が気になってくるでござるの巻

こんにちは、しばらくブログを放置していた@tomoodaです。 今日のお題はAIについてです。

コンピュータ関係でAIと言うと、普通は人工知能のことですね。Artificial Intelligenceの略。で、今回オレオレするのは、Augmenting Intelligenceのほうです。日本語にすると、知性増強ですかね。ようするに、人工知能のAIは人間の知性をコンピュータで再現するものだけれども、知性増強のほうのAIは人間の知性をどうやって増強していくかという話です。

まあ人工知能にしても、知性増強にしても、はっきりいって傲慢な話ですよ。機械のくせに人間様の知性をとやかく言うわけですから。でもね、近視や乱視の人がメガネやコンタクトレンズでモノをよく見えるようになるでしょ？あれと同じようなものです。元々人間ができることを、ちょっと弱点を補う道具を使うことで、もっと力を発揮できるようになろうよ、ということです。

じゃあ人間の知性の弱点って何でしょうね。まず１つ目は、短期記憶の貧弱さを取り上げてみましょう。

短期記憶というのはどういうものかというと、例えばこの文章を読んでいる時、あなたは今読んでいる→この単語←のいくつか前の単語を憶えているから、文章の係り受けや意味的な解釈ができるわけです。すごいですよね。人間の言語能力のかなり根幹に近いような機能です。でも、この短期記憶ってヤツ、実は結構ヘッポコなんですよ。記憶容量が狭い。色々な説がありますが、まあ5個とか9個とか、その程度の話です。この、テラバイトからペタバイトに進もうという時代に。

短期記憶が小さいとどんな不都合があるかというと、例えばLISPコードのような頻繁にネストが発生しているような構文を追いかけるのが難しいのです。LISPerはコツをつかんでまるで息をするようにカッコだらけのS式を読みこなしますが、訓練を積まないと読みこなすのは難しいです。

人間は文章を聞いたり読んだりして理解するとき、木構造ではなく線形に処理をしているのだろうと思います。じっさい、この文の構文構造を単語を葉とする二分木で表現してくださいと言ったら、１０人に頼めば１０通りの答えが返ってくるだろうと思います。つまり、木構造を持つ構文を正確に処理するのは難しいことです。

私は今はプログラミングを職業として生活しています。BNF等で形式的にキッチリ定義された木構造の文法でプログラミングします。使い慣れた言語ならば、単純な構文エラーは滅多に出しません。と思っています。だといいなあ。どうして「だといいなあ」なのかというと、プログラミング環境に助けられた上での話だからです。もし、紙とボールペンを渡されて「さあ１０行ぐらいのメソッドを書け」と言われたら、Fizz Buzzぐらいなら何とかなるかもしれませんが、ちょっと頭を使うようなメソッドはまず間違えると思います。それも、アルゴリズムの構築ではなく、構文の部分で間違えるでしょう。

これがAugmenting Intelligence、知性増強の例です。プログラミング言語の形式的な定義に従って木構造を記述することに関する弱点を、コンピュータが構文を使った自動整形や色分け等で補っているわけです。

人間の弱点の２つ目として、表現の記憶が苦手である点も挙げておきます。これは、文章の意味を理解して憶えておくことは容易ですが、文面をそのまま字面通り記憶するのは難しいということです。電話で伝言を頼まれた時、その文面通りに伝えることは難しいですよね。

この欠点はシステム開発ではとても重大な問題をはらんでいます。つまり、表現を厳密に扱うことが出来ず、一旦自分なりに解釈したものを通して、他の関係者とやりとりをしているわけです。ようするに伝言ゲームなのですよ。仕様を伝言ゲームで決めたら、恐ろしいでしょう？でも、現状では多くの開発プロジェクトが実質的には伝言ゲームで開発しています。

それを何とかしようというのが、いわゆる形式的仕様記述ってヤツです。仕様を数学的な表現で書こうという話なんですが、多くの人はこれを「正しさを証明するってこと？」と認識しています。でも、形式的仕様記述のメリットは、証明だけではありません。伝言ゲームをストップする力があるのです。

形式的仕様記述言語は、構文も意味も形式的にキッチリ定義されています。だから、伝言ゲームによる「解釈の揺れ」が出にくくなっています。日本語のコトバを字面通りに正しくコピーするのは難しいですが、数式を字面通りに正しくコピーするのはそれほど難しくありません。なぜかというと、日本語に比べ、数式は表現式と意味が非常に近い関係にあるからじゃないかな、と思います。

もちろん、何でもかんでもシステム開発は形式的仕様記述しなきゃダメ、ってことじゃないです。何をつくるのか、つくりながら模索していくような開発の場合には、まだ決めるべきでない部分は決めないでおく、曖昧な部分を残す、ということも必要です。しかし、キッチリ書くべき部分を曖昧なままにしたがための不幸な結末なんてものもよく聞く話です。形式的仕様記述はそんな時に使うAI、知性増強の道具だと思っているのです。

というわけで、なんだかいつもにも増してダラダラと長い文章になってしまいました。このブログ自体、ツイッターの文の短さの反動から始めたものだし、すんませんが勘弁してやってください。ツ

プログラミングと名前

こんにちは、今回はプログラミングにおける名前の役割について、いつもの調子でクッチャベります。ツ

プログラミングでは、どんな場面で名前が使われるでしょうか？ 変数名、関数名、クラス名などなど、色々な識別子という名前をつけます。 また、1や"abc"等のリテラルも名前と言えます。 もちろんリテラルにはラムダ式等のクロージャリテラルも含まれます。

さらに、表現式もその評価結果の値に対する名前ですね。例えば、1+2という表現式は、3という値の名前です。 特に、値への直接的な参照を使わずに、手続きを介した表現式で名前付けることを手続き抽象と呼んだりします。

さらに、プログラミングではプログラムの構成物だけでなく、外部リソースを使うことがよくあります。 外部リソースもファイル名、ファイルデスクリプタ、ホスト名、IPアドレス、ポート番号、プロセスID、ユーザID、等々、実に色々な名前が使われます。

こうして見ると、プログラミングは本当に色々な名前を付け、いろいろな名前を呼びますね。 オレ的には、プログラミングというのは結局のところ、いろいろなものに命名するということで、 プログラムを実行するというのは、そのいろいろなものの名前解決をするということじゃないか、と思うわけです。 以前オブジェクト指向って何？で書いたことも、実はユーザが認識している対象に名前を付けること、その名前解決をすること、と言うこともできちゃいます。

プログラミングで使われるこんなに色々な名前の中でも、識別子はその基礎になるものなので、識別子として適切な名前を付けることはとても重要だと考えられています。 そんなわけで、色々な場面で「名前付けのルール」が決められているわけです。

昔、計算機のパワーがまだまだ貧弱だった頃、プログラミング言語の識別子名は言語仕様で強い制約が課せられていました。 あなたも見たことがあるでしょうか、G000123みたいな識別子名。 これ、噂によると、123番目に承認されたグローバル変数、ということらしいです。 すごいですね。ツ ありがたいことに、ここまで極端な管理はもう少なくなりました。

それでも、今も色々な制約が残っています。 「ASCII文字しかダメー！」とかいう処理系もまだまだ残っているでしょう？ アメリカ帝国主義には、ほんと溜息が出ます。ツ 識別子名の長さも、以前の「8文字まで」ほどクソじゃないですが、制限が残っている処理系もあったりします。

それでも最近は昔に比べればずいぶんと自由に名前付けができるようになり、そのためフリーダムすぎる状況を避けるために、コーディング規約としていわゆる命名規約なるものを導入することが多くなりました。 曰く、「fooとかhogeとか、意味のない名前を使うな！」とか。 ちなみにオレの友人は全ての変数名をblah, blee, ...という名前にしていました。ツ また、変数名は3文字以下にするな、とかも、よくある規約ですね。 オレも昔は、そうしたほうがいいと盲目的に信じてましたよ。 ホント、「変数名はちゃんと意味のある英語名にすること（キリッ！」と言ってたのですよ。

でも、今は違います。(キリリッ！ ここ5年ぐらいで気付いたのですよ。「ちゃんと意味のある英語名」の弊害に。

意味を確定させた名前を付けないほうがよい場合の1つ目は、まだ意味を確定できない時です。 まだアイデアをスケッチしている段階で、どう呼んだらいいか、まだ確信を持てない場合。 とりあえず仮の名前を付ける時、下手に意味のある名前を仮に付けてしまうと、その名前に縛られます。

ジブリ映画に千と千尋の神隠しという作品がありますね。 皆さんはもう観ましたか？ 劇中に、千尋の名前から「尋」を取り払って「セン」と呼ぶことで魂を支配しようとする描写がありました。 あれは実は逆に見ると、清浄な油屋の世界の皆さんがセンのことを、穢れた世界の千尋ではなく、清浄な世界のセンだと信じさせるための名前でもあると思うのです。 つまり、魂を縛る相手はセンだけでなく、油屋の皆さん。 名前は、その名前で呼ばれる側だけでなく、呼ぶ側の心も縛るのです。

だから、まだ意味を確定できない時には、意味のない名前で呼んだらいいと思います。 オノマトペ(擬声語)なんかがいいでしょう。 オノマトペは自然言語処理の分野でも盛んに研究されていますが、プログラミングに取り入れていくのも面白いんじゃないかと思います。 プログラムも結局のところ、人間のコトバなのだから、どんどん色々な種類のコトバを取り入れましょうよ。ツ

意味を確定させた名前を付けないほうがよい場合の2つ目は、認知負荷をかけたくない時です。 例えば、数学ではf(x)をaFunction(theFirstArgument)なんて書いたりしませんね。ツ 数学の世界では、fと言えばまあ関数だし、aFunction(theFirstArgument)なんて書かれても、読むのが大変なだけ。 見通しの点から言っても、f(x)のほうがスンナリ理解できます。

同様に、プログラミングの世界でも、i, j, kだとか、f, g, hとか、x, xsとか、1文字で書いたほうが読み易く、かつ、高い抽象度を確保できる「英語として意味を持たない短い変数名」は色々あります。 長くて意味あり気な名前を付けて、読むための負荷を高くし、ひどい時には抽象度を誤ってしまうような失敗は避けたいものです。

というわけで、プログラミングでは本質的に名前が担う役割は非常に大きいものです。 適切な名前を付けることは、楽しいプログラミング、愉快痛快なプログラミングに必要な作業です。 だから、名前を付ける時には、しっかり考えましょう。 意味を持たせる時には、しっかり意味を持たせましょう。 意味を持たせないほうがよい時には、しっかり意味を取り除きましょう。 さもないと、千尋が本名を思い出して、油屋が大変なことになりますよ。ツ

破壊的代入と名前束縛は混ぜるな危険

みなさんこんにちは、@tomoodaです。 おかげさまでこのブログも前3記事へのページビューが1/2Kを越えました。 思った以上に読んでもらえて、嬉しいかぎりです。

さて、今回のテーマは、手続き型ベースのプログラミング言語での「代入」についてクッチャベります。ツ

変数という概念を数学で学んだ時には、「代入」とは、書き換えでした。 例えば、f(x) = a * x + bという式があった時、a=2, b = 3を「代入」すると、それぞれ前記の式の中の全てのaを2、bを3に「書き換え」て、f(x) = 2 * x + 3、としていましたね。

しかし、プログラミング言語、特に手続き型ベースのプログラミング言語では、代入は2種類あります。 それが破壊的代入と名前束縛です。

破壊的代入とは、ありていに言えば、代入文です。 f(x) = a * x + bについてaに2, bに3を代入して計算を進めていきながら、ある所でaやbに別の値を代入したりします。 同じ式f(0)を計算しても、aに2, bに3が代入された時の値と、aもbも0が代入された時とでは、f(0)の値が違ってしまいます。 そんなこともあって、いわゆる関数型言語など、破壊的代入は悪だとするプログラミングの流儀もあります。

数学でも同じ変数に何度も代入することがあります。1つは、関数適用です。 f(4)を計算した後でf(5)を計算することは、よくありますね。 xに代入する値を変えているわけです。 では、これは破壊的代入でしょうか？そんなことはありませんね。 xに4を代入した結果を計算している途中で更にxに5を代入し直すわけではありません。 xに4を代入するのとは別に、元の式に対して、xに5を代入しているわけです。 1つのコンテキストの中で書き換えるのではなく、別々のコンテキストの中で書き換えています。 これは名前束縛で、xという変数を4に束縛する、5に束縛する、と言います。

では、破壊的代入は悪なのでしょうか？撲滅すべき存在でしょうか？ 薬の副作用と同じ意味で、破壊的代入を副作用の1つと見做して撲滅すべきだという主張もあります。 そう思う人達の言い分はもっともだし、撲滅したらしたでメリットはあるでしょう。 実際、オレも関数型言語は大好きです。 それでも、オレ的には撲滅すべきだと断ずるつもりは毛頭ありません。ツ

完全に副作用のない世界を追求するのも大事ですが、それ以上に、副作用の「実害を減らす」ことが大事だと思っているのですよ。

では、実害を減らすにはどうしましょうか？ それにはまず、「対象を認識する」ことです。 そう、オブジェクト指向って何？で挙げた、一番大事なことです。 この場合、「対象を認識する」とは、破壊的代入と名前束縛をきちんと区別することです。 もう少し言えば、手続きの中で本質的に破壊的代入としてきちんと表現したい「代入」と、一時的に名前をつけておくために「代入」している本来「名前束縛」であるものを、表現としてきちんと書き分け、読み分ける、ということです。

そこで、手続き型ベースのオブジェクト指向言語のSmalltalkでやってみましょう。ツ 処理系としてはPharoを使います。 やることは簡単、2つのメソッドを追加するだけです。

まずは、Objectクラスに以下のメソッドを定義します。

=>> aBlock
    ^ aBlock value: self

さらに、Arrayクラスに

=>=> aBlock
    ^ aBlock valueWithArguments: self

も定義してみましょう。 たったこれだけで、破壊的代入と名前束縛を分離して、コードの見通しがスッキリします。

例えば、ネットワークプロトコルの単体テストのsetUpを書いてみます。 単体テストの対象はMyProtocolクラスで、単体テストをMyProtocolTestクラスに記述します。 MyProtocolTestクラスにはインスタンス変数としてpeer1, peer2が宣言されているとします。 また、テスト用にTCPコネクションの両端をシミュレートするクラスMyTestTCPConnectionがあるとします。

まずは、使用前。

setUp
    | connection stream |
    connection := MyTestTCPConnection new
    stream := connection stream1.
    peer1 := MyProtocol on: stream.
    stream := connection stream2.
    peer2 := MyProtocol on: stream.

では、使用後。

setUp
    MyTestTCPConnection new
        =>> [ :connection | 
            connection stream1
                =>> [ :stream1 |
                    peer1 := MyProtocol on: stream1 ].
            connection stream2
                =>> [ :stream2 |
                    peer2 := MyProtocol on: stream2 ] ]

さらに、こんな書き方も。

setUp
    MyTestTCPConnection new
        =>> [ :connection | 
            {(connection stream1).
            (connection stream2)}
                =>=> [ :stream1 :stream2 |
                    peer1 := MyProtocol on: stream1.
                    peer2 := MyProtocol on: stream2 ] ]

どうでしょう？ 名前束縛のシンボル「=>>」と「=>=>」と、代入のシンボル「 :=」を区別すると、こんなにプログラムの構造が整理されます。

元々Pharoには=>>と全く同じ働きをするin:メッセージがありましたが、ビジュアルな効果を期待して、あえてシンボルで定義してみました。 プログラムの構造、名前束縛という「対象を認識する」ということを大事にする、それがオブジェクト指向プログラミングなのです。ツ

たった4行のプログラミングであたかも言語仕様が拡張されたかのような、視覚/意味/スタイルへの影響を誘導できる。 Smalltalkって本当に面白いですね！ ツ

オブジェクト指向って何？

オブジェクト指向という言葉が陳腐化して、もうずいぶん時間が経ちましたね。 もうオブジェクト指向は終わった、とか、色々な事が言われています。 オブジェクト指向は本当に終わったんでしょうか？

残念でした。オレにとっては、オブジェクト指向ってのは、これから愉快痛快な展開で面白くなってくるコンセプト。ツ 皆が「終わった」と言っているのは、オブジェクト指向を実現するために使えそうな数多くの技術のうち、 とりあえずということで仮採用したプログラム構成技術の1つにすぎないと思うのです。

さて、では本題。オブジェクト指向って何？

オブジェクト指向とは、計算メディアを使っている人が認識したモノに対してプログラミングをすること、だと思っています。 例えば、このブログに表示されている著者近影のイラスト。眼鏡をかけているのに気付いたでしょうか？ 今、あなたは、イラスト中の眼鏡を認識しました。この眼鏡に対して、「レンズの色はヴィヴィッドピンクがいいな。」というメッセージを送って、眼鏡がそのメッセージを受け取って、レンズの色をヴィヴィッドピンクにするのがオブジェクト指向です。

「おいおい、それはオブジェクト指向じゃなくてフォトショだろ！」と思う人が多いことは重々承知しています。ツ その上で、あえて、「そうだね、フォトショはオブジェクト指向から多大な影響を受けたし、グラフィカルなUIでオブジェクト指向を実現するには、画像処理とか画像認識は非常に強力な武器だと思うよ。」と答えます。

つまり、オブジェクト指向というのは、

1. 人間が何かを認識する。
2. その「何か」を掴む。
3. 掴んだ「何か」にメッセージを送る。
4. 「何か」がメッセージを受け取る。
5. メッセージに応じて、「何か」が何かをする。

という一連のプロセスから成っています。

一方、巷で「終わった」と言われているオブジェクト指向とは何でしょうか？ 情報工学系の技術書ではよく、オブジェクト指向＝継承＋カプセル化＋多態、とか言われたりしますね。 で、クラスベースオブジェクト指向ではクラス階層を使って、プロトタイプベースオブジェクト指向では委譲連鎖を使います。 でも、これって、上に挙げたオブジェクト指向のプロセスの後半だけの話です。

オブジェクト指向の技術書ではまず必ず、メソッドについて言及がありますが、これすらオブジェクト指向そのものにとっては本質ではありません。 受け取ったメッセージに対応するメソッドを探索することは、とりあえず採用している仮の仕組みに過ぎません。 現にSmalltalkやRubyでは対応するメソッドが無くても、対応する処理を記述することができます。

これからオブジェクト指向を本格的に実現していくためには、むしろ前半の仕組みが必要です。 ボタンを押したらダイアログが開く、とか、変数で掴まえた「オブジェクト」にメッセージを投げる、で満足するのは20世紀で卒業しなくっちゃ。ツ 21世紀のオブジェクト指向は、もっと人間の認知に迫ることが必要なんです。 人間が注目している対象を「掴む」ための、入力デバイスや画像認識や自然言語処理や音響認識が必要です。 そして、「掴んだ」対象にメッセージを送るための、インターフェイス上の「言語デザイン」が必要です。 そろそろAltoを越えましょうよ。

オブジェクト指向の研究開発の軸足は、ソフトウェア工学から認知科学、言語学、機械学習、インタラクションデザインに移っていきます。 どうです？オレはワクワクドキドキが止まりませんよ？ ツ