例示的なプログラミング

2009年6月30日

世界で最も一般的なプログラミング言語は何ですか？

どのように測定すれば良いのかはわかりませんが、プログラミングとは何かを考慮する必要があるでしょう。私の答えとしては、最も人気のあるプログラミング言語は、プログラマーとは認識していない人々によって広く使用されているものだと考えます。この言語はExcel、より一般的にはスプレッドシートです。

スプレッドシートは小規模なタスクには簡単に使用できますが、驚くほど複雑で重要なことにも使用されています。プロのプログラマーが、重要なビジネス機能が、手を出したくないほど複雑なスプレッドシートで実行されていることを知ったとき、唖然としているのを見たことがよくあります。

一般的に、このような素人プログラマー向けのプログラミング言語は、あまり成功していません。誰かが、複雑な動作を「プログラミングなしで」指定できるようにする新しい環境について語るときはいつでも、プログラマーを排除するために最初に設計されたCOBOLについて言及します。したがって、Excelがプログラミング環境について何を教えてくれるのかを考慮することが重要です。

スプレッドシートの重要な特性の1つは、プログラムの実行とその定義を融合させる能力だと思います。スプレッドシートを見ると、スプレッドシートの数式はすぐにはわかりませんが、代わりに計算された数値、つまりプログラムが何をするかの図解が表示されます。

プログラミング環境の第一級要素として例を使用することは、他の場所（UIデザイナーなど）にも見られます。プログラムの出力を具体的に示すことは、プログラムの定義が何をするのかを理解するのに役立ち、それによって動作についてより簡単に推論できるようになります。

では、なぜこの特定の新語が必要だと感じるのでしょうか？それは基本的に、それについてもっと考える必要があると思うからです。私たちは例示的なプログラミングの例を、それについて本当に考えたり、何がそれらを特別にしているのか、あるいはある意味で特別であるということさえ考えずに見過ごしています。私たちは長年、例示的なプログラミングを使用してきましたが、それに十分な注意を払っていません。私たちは、その本質的な特性や、その長所と短所が何であるかを十分に考えていません。

私はこれを「例示的なプログラミング」という用語で説明することにしました。これは、「例」が多用されている（そして「例示」はそうではない）ということもありますが、「例示」という用語が例の実行の解説的な性質を強調しているからでもあります。例示は、概念を異なる視点から見て理解を助けることを目的としています。同様に、例示的な実行は、プログラムを変更するときにプログラムが何をするかを確認するのに役立ちます。

このように概念を明確にしようとするときは、境界のケースについて考えることが役立ちます。1つの境界は、コードを編集中にクラス階層を表示するIDEなど、編集中にプログラム情報の投影を使用するという概念です。プログラムを修正すると階層表示が継続的に更新されるという点で、これはある意味で似ていますが、重要な違いは、階層がプログラムに関する静的情報から導出できることです。例示的なプログラミングには、プログラムの実際の実行からの情報が必要です。

また、例示的なプログラミングは、動的言語の古典的なREPLループを超えた概念としても捉えています。REPLループでは実行を探索できますが、スプレッドシートがその値で行うように、例を前面に押し出すことはありません。例示的なプログラミング手法は、編集エクスペリエンスの前面に例示を配置します。プログラムは背景に退き、例示の一部を探索したい場合にのみ覗き見ます。

例示的なプログラミングはすべてが良いとは思いません。スプレッドシートやGUIデザイナーで見た1つの問題は、プログラムが何をするかを明らかにするには適していますが、プログラムの構造を軽視してしまうことです。その結果、複雑なスプレッドシートやUIパネルは、理解したり修正したりするのが難しいことがよくあります。それらは多くの場合、制御されないコピーアンドペーストプログラミングに満ちています。

これは、プログラムが例示のために軽視されているという事実の結果であるように思えます。その結果、プログラマーはそれを注意深く扱うことを考えません。通常のプログラミングでもプログラムのケア不足に悩まされているので、素人プログラマーが作成した例示的なプログラムでこれが発生しても驚くべきことではありません。しかし、この問題により、成長するにつれてすぐに保守できなくなるプログラムを作成してしまいます。将来の例示的なプログラミング環境の課題は、例示の背後にある構造化されたプログラムの開発を支援することです。ただし、例示は、構造化されたプログラムとは何かを再考させる可能性もあります。

これの難しい部分は、新しい抽象化を簡単に作成する能力かもしれません。リッチクライアントUIソフトウェアに関する私の観察の1つは、UIビルダーが画面とコントロールの観点でのみ考えるため、それらが複雑になることです。ここでの私の実験は、プログラムに適した抽象化を見つける必要があることを示唆しています。抽象化は異なる形式を取ります。ただし、これらの抽象化は、画面ビルダーが知っている抽象化のみを例示できるため、画面ビルダーではサポートされません。

私の同僚であるRebecca ParsonsとNeal Fordも、この考え方に沿って多くの時間を費やしています。そこで、Nealがメールのやり取りで考えたことをいくつか紹介します。

これらのツールは、素人向けに最適だと思います（したがって、素人プログラマーへのリンク）。ただし、一般的に、このようなツールは経験豊富なパワーユーザーを遅くします。UIパネルについて言及すると、Macはこれらのタイプのコントロールで溢れています。私はKeynoteで多くの時間を費やし、インスペクターをいじっています。少なくとも、これらのすべてのコントロールは1か所にあります（新しいリボンなどのようにではありません）。開発者として慣れ親しんでいるマクロやスニペットなどを使用して、直接定義するために使用できるマークアップ言語をはるかに好みます。

これらのツールが成長するにつれて、扱いにくくなります（ドメイン固有の範囲が狭まっているためかもしれませんか？）。Word、Excel、PowerPointを見てください。これらのツールのすべての機能を公開するために、新しいUIメタファーを発明する必要がありました。プログラミング言語のAPIは、ナビゲートが難しくなる前に、数桁も密度が高く、はるかに優れた拡張性があります。

そこには、リファクタリング、テストのレベルなど、すべてのベストプラクティスとツールが存在しません。また、テキストとの接続が失われるため、マクロ機能が存在しないか、複雑な使い捨てのものが存在します。例示的なプログラミングの制限を強調する良い比較は、bash（大規模、難解、強力、癖がある）とAutomatorの比較だと思います。Automatorは、Dietzlerの法則、つまり必要なものの10％が常に不足しているため、ほとんど使用しません。より多くのパワーが与えられるため、bashの粗雑な表面積を喜んで処理します。

私は、これらのタイプのツールに対してあなたの強気な見方を共有していますが、本格的なアジャイル開発に役立つようになるには長い時間がかかります。すぐに成熟することを願っています。

-- Neal Ford

例示的なプログラミングを真剣に受け止めている数少ない人物の1人がJonathan Edwardsです。彼は、そのような環境がどのように見えるべきかについて、非常に想像力豊かな多くのアイデアを思いつきました。彼の例示的なプログラミングのビジョンは、投影編集と制御されたコピーアンドペーストの概念にも密接に結びついています。

ここで用語を作りたくなったきっかけは、IntentionalSoftwareのような人々による言語ワークベンチによる例示的なプログラミングの使用です。これらの言語ワークベンチは、例示的なDSLを構築することを推奨しています。この場合、例示を使用することは重要です。これは、DSLを使用する目的の1つである素人プログラマーを引き付けるのに役立つはずだからです。課題は、プログラム構造が不十分になるという罠に陥ることなくこれを行うことです。