Five Questions about Language Design｜言語設計に関する五つの問い

言語設計に関する五つの問い 言語設計に関する五つの問い 2001年5月 (これは2001年5月10日にMITで行われたプログラミング言語設計に関するパネルディスカッションのために私が作成したメモです。) 1. プログラミング言語は人間のためのものだ。 プログラミング言語は、人間がコンピュータと対話する手段である。 コンピュータ自体は、曖昧さのない言語であれば、どんなものでも同じように満足する。 高水準言語が存在する理由は、人間が機械語を扱いきれないからだ。 プログラミング言語の意義は、私たちの貧弱で脆弱な人間の脳が大量の詳細情報に圧倒されるのを防ぐことにある。 建築家は、設計課題の中には他のものより個人的な要素が強い種類があることを知っている。 最も純粋で抽象的な設計課題の一つは、橋の設計である。 そこでの仕事は、与えられた距離を最小の材料で架けることが主な課題だ。 反対の極端にあるのは、椅子の設計である。 椅子の設計者は、人間の臀部について考えながら時間を費やさなければならない。 ソフトウェアも同じように多様である。 ネットワークを通じてデータをルーティングするアルゴリズムの設計は、橋の設計のように、素晴らしく抽象的な問題だ。 一方、プログラミング言語の設計は椅子の設計に似ている：それはすべて人間の弱点に対処することに関わっている。 私たちの多くは、このことを認めたがらない。 人間の弱点に迎合するよりも、数学的に優雅なシステムを設計する方が、私たちの多くにははるかに魅力的に聞こえる。 そして数学的優雅さには役割がある：ある種の優雅さは、プログラムを理解しやすくする。 しかし、優雅さそれ自体が目的ではない。 言語は人間の弱点に合わせて設計されなければならないと言うとき、私は言語が悪いプログラマーのために設計されなければならないと言っているわけではない。 実際、私は最高のプログラマーのために設計すべきだと思うが、たとえ最高のプログラマーにも限界はある。 すべての変数が整数の添字付きの文字xであるような言語でプログラミングしたいと思う人はいないだろう。 自分自身と友人のために設計せよ。 プログラミング言語の歴史を見ると、最高の言語の多くは、その作者自身が使うために設計された言語であり、最悪の言語の多くは、他の人々が使うために設計されたものだ。 言語が他の人々のために設計されるとき、それは常に特定のグループの、言語設計者ほど賢くない人々のために設計される。 だから、見下すような態度の言語ができあがる。 Cobolは最も極端な例だが、多くの言語がこの精神に満ちている。 これは、言語がどれだけ抽象的かとは関係ない。 Cはかなり低水準だが、それは作者自身が使うために設計されたものであり、それがハッカーがCを好む理由だ。 悪いプログラマーのために言語を設計すべきという主張は、良いプログラマーよりも悪いプログラマーの方が多いという理由による。 それはそうかもしれない。 しかし、その少数の良いプログラマーが、ソフトウェアの過大な割合を書いている。 私が興味を持っているのは、最高のハッカーが好む言語をどう設計するかという問いだ。 私は、これは「良いプログラミング言語をどう設計するか？」という問いと同一だと考えるが、たとえそうでなくても、少なくとも興味深い問いではある。 プログラマーに可能な限りの制御を与えよ。 多くの言語（特に他の人々のために設計されたもの）は、家庭教師のような態度を持っている：彼らが良くないと思うことをあなたがするのを防ごうとする。 私は逆のアプローチが好きだ：プログラマーにできるだけ多くの制御を与えることだ。 私が初めてLispを学んだとき、最も気に入ったのは、Lispが私を対等なパートナーと見なしてくれたことだ。 それまでに私が学んだ他の言語では、言語そのものと、その言語で書かれた私のプログラムがあり、両者は非常に分離していた。 しかしLispでは、私が書いた関数やマクロは、言語そのものを構成するものと全く同じだった。 必要なら、言語自体を書き換えることもできた。 それはオープンソースソフトウェアと同じ魅力を持っていた。 簡潔さを目指せ。 簡潔さは過小評価され、軽蔑さえされている。 しかし、ハッカーの心の奥底を見れば、彼らがそれを本当に愛していることがわかるだろう。 例えばAPLでは、ほんの数行のコードで驚くべきことができる、とハッカーが嬉しそうに話すのを何度聞いたことか。 本当に賢い人々が本当に愛するものは、注意を払う価値があると私は思う。 プログラムを短くするためにできることは、ほとんど何でも良いことだと思う。 ライブラリ関数は多くあるべきだ；暗黙化できるものは何でもそうすべきだ；構文は過剰なまでに簡潔であるべきだ；ものの名前さえも短くあるべきだ。 そして、短くあるべきなのはプログラムだけではない。 マニュアルも薄くなければならない。 マニュアルの大部分は、説明、留保条件、警告、特殊なケースで占められている。 マニュアルを短くするように自分に強制すれば、最良の場合、多くの説明を必要とした言語の欠点を修正することでそれを実現できる。 ハッキングとは何かを認めよ。 多くの人々は、ハッキングが数学であること、あるいは少なくとも自然科学のようなものであることを望んでいる。 私はハッキングは建築に似ていると思う。 建築は物理学に関連している。建築家は崩壊しない建物を設計しなければならないという意味で。しかし、建築家の実際の目標は、静力学に関する発見をすることではなく、素晴らしい建物を作ることだ。 ハッカーが好きなことは、素晴らしいプログラムを作ることだ。 そして私は、少なくとも私たち自身の心の中では、この仕事が研究論文という従来の知的通貨に容易に変換できない場合でも、素晴らしいプログラムを書くことは称賛に値する行為であることを忘れてはならないと思う。 知的には、プログラマーが愛する言語を設計することは、論文にできる何らかのアイデアを体現したひどい言語を設計することと同じくらい価値がある。 大規模ライブラリをどう整理するか？ ライブラリは、プログラミング言語のますます重要な構成要素になりつつある。 また、ライブラリは大きくなっており、これは危険なことになりうる。 望むことをしてくれるライブラリ関数を見つけるのに、自分でそれを書く時間よりも長くかかるなら、そのすべてのコードはマニュアルを厚くする以外に何の役にも立っていない。 （Symbolicsのマニュアルはその好例だった。）だから、ライブラリを整理する方法を考えなければならないだろう。 理想は、プログラマーがどのライブラリ呼び出しが適切なことをするか推測できるように設計することだ。 人々は本当に前置記法を恐れているのか？ これは、私が何年も疑問に思っており、まだ答えがわからないという意味で未解決問題だ。 数学を除けば、前置記法は私には完全に自然に思える。 しかし、Lispの人気がない理由の多くは、単に馴染みのない構文にあるのかもしれない。 もしそれが本当なら、それについて何かすべきかどうかは別の問題だ。 サーバーベースのソフトウェアに必要なものは何か？ 今後20年間に書かれる最もエキサイティングな新しいアプリケーションの多くは、Webベースのアプリケーション、つまりサーバー上に存在し、Webブラウザを通じてユーザーと対話するプログラムになるだろうと思う。 そして、この種のプログラムを書くためには、いくつかの新しいものが必要になるかもしれない。 必要なものの一つは、サーバーベースアプリの新しいリリース方法への対応だ。 デスクトップソフトウェアのように年に1、2回の大きなリリースを行うのではなく、サーバーベースアプリは一連の小さな変更としてリリースされる。 一日に5回から10回ものリリースがあるかもしれない。 そして原則として、誰もが常に最新版を使うことになる。 プログラムをデバッグ可能に設計する方法を知っているだろうか？ 同様に、サーバーベースソフトウェアは変更可能に設計されなければならない。 簡単に変更できるようにするか、少なくとも何が小さな変更で何が重大な変更かを知る必要がある。 サーバーベースソフトウェアに役立つかもしれないもう一つのものは、意外にも継続（continuations）だ。 Webベースソフトウェアでは、継続渡しスタイルのようなものを使用して、本質的にステートレスなWebセッションの世界でサブルーチンの効果を得ることができる。 コストが高すぎなければ、実際の継続を持つことは価値があるかもしれない。 発見されるべき新しい抽象概念は何か残っているか？ これがどれほど妥当な希望かはわからないが、個人的に私が本当にやりたいことの一つは、新しい抽象概念――プログラミングに大きな影響を与えるような何か――を発見することだ。

言語設計に関する五つの問い

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

関連記事

調べる

選ぶ

サイト