プログラミング言語はプラットフォームのオーサリングツールである

プログラミング言語はプラットフォームのオーサリングツールである。 ブログの導入... 新しいプロジェクトを計画し、どの言語を使用するかを決定する際、人々はしばしば2つの幻想のいずれかに陥ります。彼らは、関数型パラダイムや型システムの純粋さのような「学術的な系譜」を崇拝するか、GitHubのスター数やプログラマーコミュニティの話題に流されて「コミュニティのトレンド」に盲目的に従います。 エレガントな数学的証明や流行の構文が製品の存続を保証すると考えるのはナイーブな仮定ですが、ある意味では理解できます。人々は、自分がキャリアをかけて習得した言語とその世界観／パラダイムが、時の試練に耐えることを望んでいます。正直なところ、もしC#とTypeScriptが明日市場シェアを失い始めたら、私はあらゆるプログラミングフォーラムでそれらがどれほど優れているかという議論を貼り付けるでしょう。 それにもかかわらず、あらゆるプログラムの実行は、最終的にはマシンによって実行される命令と状態遷移に還元されます。インタプリタがソースコードやバイトコードをステップバイステップで読み取る場合、元のプログラムはマシンコードに完全に翻訳されないかもしれません。それでも、計算可能性だけを気にするのであれば、高水準言語は厳密には必要ありません。同じ計算は、マシンコードまたはアセンブリだけでも表現できます。 しかし、実際の歴史は私たちが知っているように展開しました。人々はすべてのプログラムをアセンブリとCだけで書いたわけではありません。さまざまな問題やプラットフォームに対処するために、膨大な数の高水準言語と実行時環境が出現しました。新しいハードウェアが登場し、オペレーティングシステムが出現し、ブラウザやスマートフォンが普及するたびに、それらを操作するための言語とツールがすぐに続きました。それは、より高価な問題が、マシンが何かを計算できるかどうかから、そのマシン上で人々がどれだけのプログラムを構築できるかにシフトしたからです。 IBMがPCプラットフォームのリーダーシップをMicrosoftに譲ったことも、同じレンズを通して読むことができます。IBMはPCとして知られるハードウェア標準を作成しましたが、その上に構築されたアプリケーションソフトウェアと開発者エコシステムは、IBMのマシンではなく、MS-DOSとWindows APIに縛られるようになりました。互換性のあるPCが普及するにつれて、ハードウェアはコモディティ化し、開発者がプログラムを書くためのインターフェースを制御していたMicrosoftが、プラットフォームの真の所有者になりました。 空のプラットフォームはまだ製品ではありません。ゲーム、生産性アプリケーション、コンテンツがその上に蓄積されて初めて、ユーザーが滞在する世界になります。言語はその世界をオーサリングするツールです。そして、プログラマーがそのツールを手に取り、空の空間に論理とルールを課した瞬間、彼らは単なるマシンオペレーター以上の存在になります。しかし、コンピュータプログラマーは、彼だけが法を制定する宇宙の創造者です。これは、ELIZAの作成者であるジョセフ・ワイゼンバウムが『Computer Power and Human Reason』に残した一節です。 しかし、プログラマーが言語で世界を構築できるという事実だけでは、その言語の成功を説明できません。非常に表現力豊かな言語でも、小さな研究コミュニティに限定されることがあります。一方、広く批判されている言語でも、大規模な実行時環境に遭遇し、業界標準になることがあります。プログラミング言語の議論は、通常、型システム、セマンティクス、パラダイム、実装戦略などの学術的な分類から始まります。これらの分類は重要ですが、それだけでは言語の実際の歴史を説明することはできないと私は信じています。 私の見解では、なぜ人々がプログラミング言語を学ぶのかという問いに対するより良い答えは、ジョブマーケットの視点です。ジョブマーケット、そしてより広範な市場のレンズを通して見たこの考え方が、私がこの記事を書くきっかけとなりました。プログラミングの学術的な系譜をたどる文章は数多くあり、私がそれに何かを加えたとしても、競争力はほとんどないでしょう。代わりに、私は異なる視点を提供したいと思います。 私の見解では、言語の歴史を読むには、少なくとも3つの問いを区別する必要があります。アニメーション図の読み込み... それはなぜ作成されたのか？ 開発者はそれをなぜ採用したのか？ なぜそれが長期間支配的であり続けたのか？ これらが、私の意見では最も基本的な問いです。研究のために構築された言語が、大規模な産業プラットフォームを満たすことで成功する可能性があります。一方、特定のプラットフォームのために構築された言語が、そのプラットフォームの境界を超えて広がることもあります。言語の元の動機だけから、その後のすべての歴史を説明しようとすると、すぐに問題に直面します。 プラットフォームと補完財 オペレーティングシステム、ブラウザ、ゲーム機、スマートフォンの価値は、それ上で実行されるプログラムとともに成長します。ユーザーが毎日目にするのは、システムのカーネルやその設計の優雅さではなく、最終製品、つまり生産性アプリケーションやゲームです。ゲームをプレイするためのゲームがないゲーム機は、高価なリビングルームの家具にすぎません。 経済学では、一緒に消費されるときに価値を最大化する財を補完財と呼びます。プラットフォームとアプリケーションは、まさにこの種の補完的な関係を持っています。インフラストラクチャが広大な空のステージだとすれば、アプリケーションとコンテンツはその上の俳優とスクリプトです。劇場の音響と照明システムがいかに最先端であっても、ステージ上で何も演じられなければ、観客は来ないでしょう。言い換えれば、プラットフォームの実際の商業的価値と市場支配力は、それ自体の計算能力によってではなく、そのエコシステム内で継続的に生成される補完財（キラーアプリケーション）の総量に完全に依存して決定されます。 概念的には、これは次のように要約できます。アニメーション図の読み込み... プラットフォームオペレーターにとって、開発ツールは工場の設備に似ています。コンパイラの販売がコア収益源ではないとしても、それは問題ではありません。開発者がより安価かつ迅速にプログラムを構築できるようになれば、プラットフォーム上の補完財の数が増加し、プラットフォーム自体の価値が高まります。ジョエル・スポルスキーが「補完財のコモディティ化」と説明した戦略は、言語やSDKにも同様に適用されます。 したがって、「高水準言語はコンパイラを販売するために作成されたのか」という問いは、私の尺度では、やや一次元的なフレーミングです。企業の収益は、コンピュータ、オペレーティングシステム、ランタイム、ブラウザ、スマートフォンから得られることが多かったのです。言語は、人々がそれらの製品を使い続ける理由を与えるものです。 言語が削減するコスト 言語が削減するコストは、タイピングの手間を省くだけにとどまりません。アニメーション図の読み込み... 「アセンブリで実装できます」と言うのは、チューリング完全性、つまり計算表現性に関する答えです。しかし、それがビジネススケジュール内に構築できるか、別のチームが数年後にそれを変更できるか、次のマシンに移植できるかといった問題は、まったく異なる質問であり、開発コストと実用性に関するものです。チューリング完全な言語は、原理的には同じ計算を表現できますが、問題は、それらの計算を書く、検証する、維持するというコストが言語によって同じではないということです。 では、言語設計の違いをどのように見るべきでしょうか？一般的に、それらの違いは、計算できることよりも、コストと責任が人間、コンパイラ、ランタイムの間でどのように分散されるかに現れます。現実世界で最も繰り返し尋ねられる質問は何でしょうか？それが財政的に実行可能かどうかです。だからこそ、計算の可能性からコストの分散への移行は非常に重要なのです。 この視点から見ると、プログラミング言語の歴史は、各時代のシステムで最も高価だったリソースに対する一連の応答として読むことができます。ハードウェアが希少で高価だった頃は、実行効率が支配的な制約でした。しかし、ソフトウェアが大きくなり、開発組織が拡大するにつれて、コードを書く、検証する、維持するという人間のコストも同様に重要になりました。高水準言語は、かつて人間の記憶と注意によって担われていた作業の一部を...