今日はチャールズ・シモニーの誕生日(1946)。
…横井軍平さんの誕生日でもあるけど、それは去年の日記を見てね。
チャールズ・シモニーは Alto の上で、世界初の WYSIWYG ワープロ「Bravo」を実現します(1974)。
僕は Bravoは Smalltalk 上で作られたのかと思っていたのだけど、これは勘違いの模様。
その後、メタプログラミングの概念を提唱(1977)。
ただ、ここでいうメタプログラミングってどのレベルを言うのか、僕の調査不足で不明。
メタプログラムと言うのは「プログラムを生成するプログラム」のことです。
ちょっとした曲芸のように思われてしまうこともあるのだけど、非常に厳密さが要求されるのに、非常に長大になってしまうことがわかっているようなプログラムを、別のプログラムによって自動生成したりするのに使われます。
たとえば、yacc というソフトでは、コンパイラの文法を定義すると、その文法を解析できるC言語のソースを生成します。
実は、文法解析プログラムって、作るのすごく大変なのね。大変と言うのは、難しいというのではなくて、厳密で長大なのでひたすら面倒くさい。
それを自動生成してくれるのです。
これは、ある意味「プログラムを生成するプログラム」です。
ただ、それをメタプログラミングと呼ぶかというと…微妙。
C言語のソースは、Cコンパイラにより、アセンブラのソースを生成します。
(今では直接機械語を生成するのが普通ですが、昔はそうでした)
でも、これをメタプログラミングとは言わない。これは単にコンパイラ。
yacc もメタプログラムとは呼ばれず、Yet Another Compiler Compiler (別のコンパイラを作るコンパイラ)の略です。
メタプログラミングとは、通常は「同じ言語で」作られることに意味があります。
Lisp で Lisp のプログラムを生成し、そのまま実行するとか、Javascript で Javascript のプログラムを生成して、そのまま eval するとか。
…Javascript を圧縮してくれる Packer とか、メタプログラミングになるのかしら?
まぁ、最近ではここら辺は曲芸みたいなものになっているのですが、境界は非常に曖昧なものです。
大切なのは、プログラムでプログラムを生成することによりメリットを得られるのであれば、何も躊躇することは無い、ということ。
プログラムを作るのは人間の知的活動のなせる業だ、と言われていたときにこれを提唱したのは評価に値するでしょう。
ちなみに、曲芸的には僕も「メールアドレスを SPAM ボットに発見されないように Javascript で暗号化したプログラムを生成する Javascript」を作って公開していますので、興味ある人は見てやってください。
で、チャールズシモニーの一番の功績だと僕が思っているのは、ハンガリアン記法です。
彼はマイクロソフトに入社し、Excel や Word の開発に関与しています。
多人数でプログラムを行う際の問題を解決する方法として彼が考案した変数表記方法が、今では「ハンガリアン記法」と呼ばれています。
もちろん、彼がハンガリー人であったためこの名前が付けられたのです。
ただ、彼の考案した記法はどうも正しく理解されず「システムハンガリアン」と「アプリケーションンハンガリアン」に分断してしまいました。
彼が考えたのはアプリケーションハンガリアンなのだけど、現在普及しているのはシステムハンガリアンの方。
そして、システムハンガリアンは「全く無意味」です。
アプリケーションハンガリアンのメリットを誤解してシステムハンガリアンが広まり、この記法が全く無意味だと多くの人が感じた時点で、アプリケーションハンガリアンの存在には気づかず誤解されたままこの表記法は消えゆこうとしています。
システムハンガリアンと言うのは、変数名に、その変数の「型」を一緒に入れておこう、と言うもの。
Integer (整数)型であれば、i から始まる名前に、Float (浮動小数点)型であれば、f から始まる名前に…など、名前の付け方を統一します。
これ、全く無意味なだけでなく、弊害の方が大きいです。
後で必要があって変数の型を変えることになったら、変数を使っているところを全部探し出して書き変えないといけない。
それで何かメリットが得られるかと言えば、何も得られない。
変数の型はコンパイラが把握しているから、Integer 型の変数に Float の値を入れようとしたら、警告を出してくれます。
間違えてもコンパイラが警告してくれるのに、わざわざ変数名を工夫して「人間が注意できるように」する必要が無い。
正しい使われ方であるアプリケーションハンガリアンは、「コンパイラが警告を出さない」変数の意味について、名前の付け方を統一します。
たとえば、ドルと円の両方のお金を扱わないといけないプログラムがあった時、ドル関連の変数はすべて d を頭につけ、円関係の変数は全て頭に y を付けることにします。
これで、d と y を混ぜて使おうとしていたら、何かおかしいとプログラマ自身が気づくことになる。
ゲーム作っていて、敵に関する変数は en で、自分に関する変数は my ではじめるとか、そういうのも「アプリケーションハンガリアン」に当たります。
…ハンガリアン記法、と言われなくても、なんとなく心がけているプログラマは多そうですけどね。
ただ、大人数で開発するときはあらかじめルールを決めよう、と言うのは必要なことで、これを明言した功績は大きいです。
彼はこの手法をさらに推し進め、「インテンショナルプログラミング」と言う言語環境も考案したそうです。
僕、よく理解していません。間違っていたら申し訳ないのですが、プログラムを作成するエディタに、アウトラインプロセッサ的なレベル概念を導入しつつ、ユーザーインターフェイスと内部処理を分離しながら緩く結合する、というもののよう。
…はい、何言っているのかわかりませんね。
ちゃんと解説しましょう。
まず、プログラムと言うのは、当然のことですが「全体としてやりたいこと」があるから作るのです。
でも、コンピューターは馬鹿だから、1から10まですべて教えないといけない。10が目的だとすれば、1を大量に積み上げて「10」を表現する必要があります。
でも、この作業が膨大なのですね。プログラム中のいたるところで、ちまちまとして意味の解らない作業が、膨大に発生している。
じゃぁ、そのちまちました作業に「入力がある間全部処理する」とか、「1~10まで足す」とか、「ユーザーの指示を待つ」とか、わかりやすい名前を付けて、見えなくしちゃおうよ…というのがアイディアの一つ目。
これで、細かすぎる部分が見えなくなると、全体の処理の流れが見えやすくなります。
アウトラインプロセッサと言うのはワープロの一種なのですが、章の見出しだけを表示して全体の流れを見やすくしたりしながら推敲をするためのツールです。
そういう機能をプログラム環境にも取り入れよう、というのが、アイディアの一つ目。
もう一つ、インターフェイスビルダーと言うのは、NeXT が備えていたプログラム環境ですね。
画面表示と、プログラムの内部処理を完全に分離しておき、後から画面表示だけを組み替えたりできるようになっています。
Windows では、基本的に画面表示はプログラムの一部として実装されていました。
これでは、作った後に「使いにくかった」と思っても、プログラムを作り直さないと画面表示を変えられません。
(もちろん、画面部品をデータとして持っておき、組み替えられるようにプログラムしておくことはできます。
ただ、そういうプログラムを作るのは手間がかかります。その手間を最初から肩代わりしてくれるのが、インターフェイスビルダーでした)
これにより、プログラマーは「やりたいこと」だけに集中してプログラムが組める、と言う環境が作られます。
ただ、これは「大いなる野望」ではありましたが、いろいろとややこしいことになり、開発は頓挫したようです。
まぁ、それも判ります。
実のところ、細かな部分にわかりやすい名前を付けて見えなくする…というのは、関数化などで普通のプログラマーなら当たり前にやっていることです。
これをもっと使いやすいように支援しようとしても、煩雑な処理が増えるだけのように見えます。
恐らくは、彼の本当の目的は「意味を名前付ける」ことを繰り返させることで、全体の動作を「知らず知らずにドキュメント化」して、「保守を容易にする」ことだったのだと思います。
先に書いたハンガリアン表記も、保守を容易にする目的でした。
そして、おそらくはメタプログラミングも。
(小さなプログラムによって全体を自動構成すれば、変更が生じた際も小さなプログラムを修正するだけで済みます)
彼の興味は、プログラムを保守しやすくする環境作りにあるのでしょう。
しかし…残念ながら、多くのプログラマーはプログラムが「動く」と満足してしまい、その後の保守のために余計な労力を使おうとはしないのです。
これが、彼の考案したものが、勘違いされたり頓挫したりしながら普及しない原因かと思います。
でも、保守が大切である、と、あるレベル以上のプログラマであれば痛感しているはず。
彼の研究が多くのプログラマーに理解される日があらんことを。
同じテーマの日記(最近の一覧)
関連ページ
HARLIE あらすじと解説(1/2)【日記 14/09/21】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |