プログラミング言語設計に関する XNUMX つの質問

指導理念

1. 人のためのプログラミング言語

プログラミング言語は、人々がコンピューターと会話する方法です。コンピュータは曖昧でない言語であれば喜んで話します。高級言語があるのは、人間が機械語を扱えないからです。プログラミング言語の目的は、貧しく壊れやすい人間の脳があまりにも多くの詳細に圧倒されないようにすることです。

建築家は、設計上の問題の中には、他の問題よりも日常的なものがあることを知っています。最も明確で最も抽象的な設計問題のいくつかは橋の設計です。この場合、あなたの仕事は、できるだけ少ない材料で必要な距離をカバーすることです。スペクトルの対極にあるのは椅子のデザインです。椅子のデザイナーは、時間をかけて人々のお尻について考える必要があります。

ソフトウェア開発にも同様の違いがあります。ネットワークを介してデータをルーティングするアルゴリズムの設計は、橋の設計と同様、優れた抽象的な問題です。一方、プログラミング言語の設計は椅子の設計に似ており、人間の弱点に対処する必要があります。

これは私たちのほとんどにとって認識するのが難しいことです。私たちのほとんどにとって、エレガントな数学システムを設計することは、人間の弱点に迎合するよりもはるかに魅力的に聞こえます。数学的優雅さの役割は、ある程度の優雅さがプログラムを理解しやすくすることです。しかし、エレガンスだけがすべてではありません。

そして、私が言語は人間の弱点に適応するように設計されるべきだと言うとき、私は言語が下手なプログラマのために設計されるべきだと言っているのではありません。実際には、最高のプログラマー向けにソフトウェアを設計する必要がありますが、最高のプログラマーにも限界があります。すべての変数が整数の添え字が付いた文字「x」で表される言語でプログラミングを楽しめる人はいないと思います。

2. 自分や友達のためにデザインする

プログラミング言語の歴史を見ると、最高の言語のほとんどはその作者自身が使用するように設計されており、最悪の言語のほとんどは他の人が使用するように設計されています。

言語が他の人のために設計されるとき、それは常に特定の人々のグループです。人々は言語の作成者ほど賢明ではありません。こうやって、自分に語りかける舌を手に入れることができるのです。 Cobol が最も顕著な例ですが、ほとんどの言語にはこの精神が染み込んでいます。

言語のレベルの高さとは関係ありません。 C は非常に低レベルですが、作成者が使用するために作成されたため、ハッカーは C を愛用します。

悪いプログラマ向けに言語を設計することについての議論は、優れたプログラマよりも悪いプログラマの方が多いということです。おそらくそうなのでしょう。しかし、この少数の優秀なプログラマは、不釣り合いに多くのソフトウェアを作成します。

私の質問は、優秀なハッカーにアピールする言語をどのように作成するかということです。この質問は、「良いプログラミング言語を作成するにはどうすればよいですか?」という質問と同じであるように私には思えますが、そうでないとしても、少なくとも興味深い質問です。

3. プログラマに可能な限り多くの制御を与える

多くの言語 (特に他の人向けに設計された言語) は乳母のように機能します。つまり、自分にとって利益にならないと思われる事柄から遠ざけるように警告しようとします。私は反対の見方をしています。プログラマにできる限り多くの制御を与えます。

私が初めて Lisp を学んだとき、私が最も気に入ったのは、私たちが対等に話し合えるということでした。その時点までに私が学んだ他の言語には、言語があり、その言語でのプログラムがあり、それらはまったく別々に存在していました。しかし、Lisp では、私が書いた関数とマクロは、言語自体が書かれたものと同じでした。必要に応じて言語自体を書き直すこともできます。オープンソース ソフトウェアと同じ魅力がありました。

4. 簡潔さは才能の姉妹である

簡潔さは過小評価されており、軽蔑さえされています。しかし、ハッカーの心を調べてみると、彼らは簡潔さを非常に好むことがわかります。ハッカーが、たとえば APL では、たった数行のコードで驚くべきことがどのようにして実現できるのかについて、懐かしそうに語るのを何度聞いたことがあるでしょうか?本当に賢い人は実際にこれに注意を払うのが好きなのだと思います。

私は、プログラムを短くするものはほとんどすべて良いことだと信じています。多くのライブラリ関数が存在する必要があり、暗黙的に指定できるものはすべて暗黙的に指定する必要があります。構文はもっと簡潔にする必要があります。エンティティ名であっても短くする必要があります。

プログラムが短くなければならないわけではありません。マニュアルも短くすべきです。マニュアルの大部分には、説明、免責事項、警告、特殊なケースが記載されています。マニュアルを短くする必要がある場合、最善の選択肢は、多くの説明が必要な文言を修正することです。

5. ハッキングとは何かを理解する

多くの人は、ハッキングが数学、または少なくとも科学に似たものであることを望んでいます。ハッキングはむしろ建築に似ていると思います。建築家は倒れない建物を設計する必要があるという点で、建築は物理学に関するものですが、建築家の本当の目標は素晴らしい建物を作ることであり、静力学の分野で発見をすることではありません。

ハッカーが好むのは、優れたプログラムを作成することです。そして、少なくとも私たち自身の考えにおいては、たとえその仕事が科学論文という通常の知的通貨に簡単に変換されないとしても、素晴らしいプログラムを書くことは素晴らしいことであるということを覚えておくべきだと思います。知的観点から見ると、論文を出版できるようなアイデアを具現化したひどい言語を設計するのと同じくらい、プログラマに気に入られる言語を設計することが重要です。

未解決の問題

1. 大規模なライブラリを整理するにはどうすればよいですか?

ライブラリはプログラミング言語の重要な部分になりつつあります。大きくなりすぎて危険です。必要なことを実行する関数をライブラリ内で見つけるのに、その関数を自分で記述するよりも時間がかかる場合、すべてのコードはマニュアルを分厚くするだけです。 (Symbolics マニュアルはこの例でした。) したがって、ライブラリの組織化の問題を解決する必要があります。理想的には、プログラマがどのライブラリ関数が適切かを推測できるように設計します。

2. 人々は本当にプレフィックス構文を恐れているのでしょうか?

これは、私が数年間考えてきましたが、まだ答えがわからないという意味で未解決の問題です。プレフィックス構文は、おそらく数学での使用を除いて、私にとってはまったく自然なものに思えます。しかし、Lisp の不人気の多くは単純に不慣れな構文によるものかもしれません...それが本当であれば、それについて何かをする価値があるかどうかは別の問題です。

3. サーバー ソフトウェアには何が必要ですか?

今後 20 年間に作成されるアプリケーションのほとんどは、プログラムがサーバー上に常駐し、Web ブラウザを通じて通信するという意味で、Web アプリケーションになると思います。そして、そのようなアプリケーションを作成するには、新しいものが必要です。

その 1 つは、サーバー アプリケーションをリリースする新しい方法のサポートです。デスクトップ ソフトウェアのように年に 1 ～ 2 回の大規模なリリースではなく、サーバー ソフトウェアは一連の小さな変更を加えてリリースされます。 1 日に 5 件または 10 件のリリースがある場合もあります。そして誰もが常に最新バージョンを手に入れることができます。

保守しやすいプログラムを設計する方法を知っていますか?サーバー ソフトウェアは変更可能に設計する必要があります。簡単に変更できるか、少なくともマイナーな変更が何を意味し、何が重要であるかを知っておく必要があります。

サーバー ソフトウェアで役立つもう 1 つの点は、突然、配信の継続性です。 Web アプリケーションでは次のようなものを使用できます CPSステートレスな Web セッションの世界でルーチンの効果を得るには。機能がそれほど高価でない場合、供給を継続することは価値があるかもしれません。

4. まだ発見されていない新しい抽象化は何ですか?

その希望がどれほど合理的かはわかりませんが、個人的には新しい抽象化、つまりファーストクラスの関数や再帰、あるいは少なくともデフォルトのパラメータと同じくらい意味のあるものを発見したいと思っています。もしかしたらこれは実現不可能な夢かもしれない。このようなことは発見されないことが多いです。しかし、私は希望を失いません。

あまり知られていない秘密

1. 好きな言語を使用できます

以前は、アプリケーションの作成はデスクトップ ソフトウェアの作成を意味していました。また、デスクトップ ソフトウェアでは、オペレーティング システムと同じ言語でアプリケーションを作成することに大きな偏りがあります。したがって、10 年前、ソフトウェアを書くということは、一般に C でソフトウェアを書くことを意味していました。最終的には、アプリケーションは珍しい言語で書かれるべきではないという伝統が進化しました。そして、この伝統は長い間進化してきたため、マネージャーやベンチャーキャピタリストなどの非技術者もそれを学びました。

サーバー ソフトウェアはこのモデルを完全に破壊します。サーバー ソフトウェアを使用すると、任意の言語を使用できます。このことを理解している人はまだほとんどいません（特に経営者やベンチャーキャピタリスト）。しかし、一部のハッカーはこれを理解しているため、Perl や Python などのインディー言語についてよく耳にします。 Perl や Python についてはあまり聞きません。Windows アプリケーションを作成するために Perl や Python が使用されているからです。

これは、プログラミング言語の設計に興味がある私たちにとって、私たちの仕事を見てくれる潜在的な読者がいるということを意味します。

2. スピードはプロファイラーから生まれる

言語開発者、少なくとも言語実装者は、高速コードを生成するコンパイラーを作成することを好みます。しかし、それはユーザーにとって言語を高速にするものではないと思います。 Knuth 氏はずっと前に、速度はほんのいくつかのボトルネックによって決まることに気づきました。そして、プログラムの高速化を試みたことがある人なら誰でも、ボトルネックがどこにあるのか推測できないことを知っています。プロファイラーがその答えです。

言語開発者は間違った問題を解決しています。ユーザーは迅速に実行するためにベンチマークを必要としません。プログラムのどの部分を書き直す必要があるかを示すことができる言語が必要です。この時点で実践ではスピードが求められます。したがって、言語実装者がコンパイラーの最適化に費やす時間の半分を、優れたプロファイラーの作成に費やした方がよいかもしれません。

3. あなたの言語を進化させるアプリが必要です

これは究極の真実ではないかもしれませんが、最高の言語は、それが使用されるアプリケーションとともに進化したようです。 C はシステム プログラミングを必要とする人々によって書かれました。 Lisp は部分的には記号微分を目的として設計されており、マッカーシーは非常に使い始めたかったので、1960 年の最初の Lisp 論文で微分プログラムを書き始めました。

これは、アプリケーションがいくつかの新しい問題を解決する場合に特に役立ちます。これにより、言語にプログラマーが望む新しい機能が追加されます。個人的には、サーバー アプリケーションに適した言語を書くことに興味があります。

[議論の中で、Guy Steele 氏もこの点を指摘し、言語がコンパイラを作成するように設計されている場合を除き、アプリケーションはその言語用のコンパイラを作成することで構成されるべきではないと付け加えました。

4. 言語は XNUMX 回限りのプログラムを作成するのに適している必要があります。

ワンショット プログラムが何を意味するかはご存知でしょう。それは、限られた問題を迅速に解決する必要がある場合です。周りを見渡せば、単発で始まった本格的なプログラムがたくさんあると思います。ほとんどのプログラムが単発的なものとして始まったとしても、私は驚かないでしょう。したがって、一般的なソフトウェアの作成に適した言語を作成したい場合は、一回限りのプログラムの作成にも適している必要があります。なぜなら、これは多くのプログラムの初期段階だからです。

5. 構文はセマンティクスに関連しています

伝統的に、構文とセマンティクスはまったく異なるものであると考えられています。これは衝撃的に聞こえるかもしれませんが、そうではありません。プログラムで達成したいことは、それをどのように表現するかに関係すると思います。

私は最近 Robert Morris と話しましたが、彼は演算子のオーバーロードが中置構文を持つ言語の勝利に大きなプラスになると指摘しました。接頭辞構文を持つ言語では、定義した関数は実際には演算子です。作成した新しいタイプの数値を追加したい場合は、それを追加するための新しい関数を定義するだけです。これを中置構文を使用する言語で実行すると、オーバーロードされた演算子を使用することと関数を呼び出すことの間には大きな違いがあることがわかります。

時間が経つと戻ってくるアイデア

1. 新しいプログラミング言語

1970 年代を振り返ると、新しいプログラミング言語を開発するのが流行っていました。今はそうではありません。しかし私は、サーバー ソフトウェアによって、新しい言語を作成する流行が再び復活すると信じています。サーバーソフトを使えばどんな言語でも使えるので、誰かが他より良さそうな言語を作ったら、それを使おうと思う人もいるでしょう。

2. タイムシェアリング

リチャード・ケルシーがこのアイデアを思いつきましたが、その時が再びやって来ました。私はそれを全面的に支持します。私の推測では (マイクロソフトも)、多くのコンピューティングがデスクトップからリモート サーバーに移行すると考えています。言い換えれば、タイムシェアリングが戻ってきたということです。これには言語レベルでのサポートが必要になると思います。たとえば、Richard Reeves と Jonathan Reeves は、Scheme 48 のプロセス スケジューリングを実装するために多くの作業を行ってきました。

3.効率

最近では、コンピューターはすでに十分に高速になっているようです。バイトコードについて聞くことが増えていますが、これは少なくとも私にとっては、ある程度の余力があることを意味します。しかし、サーバー ソフトウェアにはそれがないと思います。ソフトウェアを実行するサーバーの料金は誰かが支払う必要があり、サーバーがマシンごとにサポートできるユーザーの数は資本コストの約数になります。

少なくともコンピューティングのボトルネックにおいては、効率が重要になると思います。サーバー アプリケーションはそのような操作を多数実行するため、これは I/O 操作の場合に特に重要です。

最終的には、バイトコードが答えではないことが判明する可能性があります。 Sun と Microsoft は現在、バイトコード分野で対決しているようだ。しかし、彼らがこれを行うのは、バイトコード自体が良いアイデアだからではなく、バイトコードがプロセスに埋め込むのに便利だからです。この戦い全体が見過ごされることになるかもしれない。それは面白いでしょう。

スネアとスネア

1. クライアント

これは単なる推測ですが、恩恵を受けるのは完全にサーバーサイドのアプリケーションだけであるということです。誰もが顧客を持つという前提で動作するソフトウェアを設計することは、誰もが正直であるという前提に基づいて社会を設計するようなものです。それは間違いなく便利ですが、それは決して起こらないと想定する必要があります。

今後、Web 対応デバイスが急速に増加すると考えられ、基本的な HTML とフォームがサポートされることが予想されます。携帯電話にブラウザはありますか? PalmPilot には電話が付いていますか?あなたのブラックベリーには大きな画面が搭載されますか?ゲームボーイからインターネットにアクセスできますか?時計からですか？わからない。そして、すべてがサーバー上にあると賭けても、それを知る必要はありません。すべての頭脳がサーバー上にあるほうが、はるかに信頼性が高くなります。 。

2. オブジェクト指向プログラミング

これが物議を醸す発言であることは承知していますが、OOP はそれほど重要ではないと思います。これは、ウィンドウ システム、シミュレーション、CAD システムなど、特定のデータ構造を必要とする特定のアプリケーションに適したパラダイムだと思います。しかし、なぜそれがすべてのプログラムに適している必要があるのか​​わかりません。

大企業の人々が OOP を愛しているのは、一つには、仕事のように見えるものが OOP によってたくさん作られているからだと思います。自然には、たとえば整数のリストとして表現されるものを、あらゆる種類の足場があり、喧騒が渦巻いている教室として表現できるようになりました。

OOP のもう 1 つの魅力的な特徴は、メソッドによってファーストクラス関数の効果の一部が得られることです。しかし、これは Lisp プログラマにとってはニュースではありません。真のファーストクラス関数があれば、すべてをクラスやメソッドの定型文に押し込むのではなく、当面のタスクに適した方法で簡単に使用できます。

これが言語設計にとって意味することは、OOP を言語設計にあまり深く埋め込むべきではないということだと思います。おそらくその答えは、より一般的で基礎的なものを提供し、あらゆるオブジェクト システムをライブラリとして設計できるようにすることです。

3. 委員会による設計

あなたの言語が委員会によって設計されている場合、誰もが知っている理由だけではなく、あなたは罠にはまってしまいます。委員会がでこぼこした一貫性のない言語設計を作成する傾向があることは誰もが知っています。しかし、大きな危険は、彼らがリスクを冒さないことだと思います。一人の人間が責任者である場合、委員会が引き受けることに決して同意しないようなリスクを負うことになります。

良い言語を作成するにはリスクを冒す必要がありますか?多くの人は、言語設計では伝統的な知恵にかなり近づける必要があるのではないかと疑っているかもしれません。きっとそうではないと思います。人々が行う他のすべてのことにおいて、報酬はリスクに比例します。では、なぜ言語設計がこれまでと異なる必要があるのでしょうか?

出所： habr.com