最新のプログラミング言語開発のためのプロセス計算とPL理論の使用

しばらくの間、私はプログラミング言語理論とプロセス計算に非常に興味があり、それらを研究し始めました。正直なところ、それはキャリアのために行くことを気にしないものです。私は理論が非常に魅力的であると思います。私が継続的に遭遇する1つの定数の質問は、PL理論またはプロセス計算のいずれかが、現代のプログラミング言語開発においてまったく重要であるかどうかです。Pi微積分には非常に多くのバリアントがあり、多くの活発な研究がありますが、それらは必要になるか、重要なアプリケーションを持つでしょうか？私が尋ねる理由は、プログラミング言語の開発が大好きであり、真の最終目標が実際にPLを構築するために理論を使用することであるからです。私が書いたものについては、理論との相関はまったくありませんでした。

私の答えは本当に私が書いた前に読んだことがなかったGillesの精巧さです。それでも、それは役立つでしょう。

一般的なプログラミング言語理論、特にプロセス計算とは大きく異なる2次元のプログラミング言語作業の違いから、あなたの質問に答える私の試みを始めましょう。

• 純粋な研究。

• 製品中心の研究開発。

後者は通常、製品としてプログラミング言語を提供することを目的として業界で行われます。OracleでJavaを、MicrosoftでC＃を開発しているチームがその例です。対照的に、純粋な研究は製品に結び付けられていません。その目的は、本質的に関心のあるオブジェクトとしてプログラミング言語を理解し、すべてのプログラミング言語の基礎となる数学的構造を調査することです。

目標が異なるため、プログラミング言語理論のさまざまな側面は​​、純粋な研究と製品中心のR＆Dに関連しています。以下の図は、どこが重要かを示している場合があります。

この時点で、2つの次元が一見非常に異なっているように見える理由と、それでもそれらがどのように関連しているのかを尋ねます。

重要な洞察は、プログラミング言語の研究開発には、技術的、社会的、経済的という複数の側面があるということです。ほぼ定義上、業界はプログラミング言語の経済的利益に関心を持っています。マイクロソフトなどは、心の底から言語を開発するのではなく、プログラミング言語が経済的な利点をもたらすと信じているからです。また、一部のプログラミング言語が成功する理由を深く調査しましたが、他のプログラム言語は、一見類似している、またはより高度な機能を備えているにもかかわらず、成功しません。そして、彼らは単一の理由がないことを発見しました。プログラミング言語とその環境は複雑であり、特定の言語を採用または無視する理由も複雑です。しかし、プログラミング言語が成功する最大の要因は、すでに広く使用されている言語へのプログラマーの優先的なアタッチメントです。より多くの人々が言語を使用するほど、より多くのライブラリー、ツール、教材が利用可能になり、プログラマーの生産性が向上します。その言語を使用できます。これはネットワーク効果とも呼ばれます。もう1つの理由は、個人や組織の言語を切り替えるコストが高いことです。特に、あまり経験のないプログラマにとっては言語を習得する必要があります。また、使い慣れた言語とのセマンティックの距離が遠い場合、時間と手間がかかります。これらの事実を踏まえると、なぜ新しい言語がまったく魅力的なのかと疑問に思われるかもしれません。企業が新しい言語を開発するのはなぜですか？なぜJavaやCobolにとどまらないのですか？言語が成功する主な理由はいくつかあると思います。

• プログラミングの新しい領域が開かれ、現在の職を失うことはありません。その主な例は、Javascriptの増加を伴うWebです。

• 言語の粘り。これは、言語を変えることの高価格を意味します。しかし、プログラマーは別の分野に移動し、プログラミング言語を取り入れて、新しい分野の古い言語で成功することがあります。

• 言語は、深刻な財政力を持つ大企業によって推進されています。早期導入者は、言語が数年後もサポートされることを合理的に確信できるため、この支援により、導入のリスクが軽減されます。これの良い例はC＃です。

• 言語には説得力のあるツールとエコシステムが付属している場合があります。ここでもC＃です。例として、.NetとVisual Studioエコシステムを挙げます。

• 古い言語は新しい機能を採用しています。Javaが頭に浮かびます。これは、反復ごとに、関数型プログラミングの伝統からより良いアイデアを取り入れます。

• 最後に、新しい言語には固有の技術的利点がある可能性があります。たとえば、表現力が向上し、構文が向上し、より多くのエラーをキャッチするタイピングシステムなどになります。

このような背景を考えると、純粋なプログラミング言語の研究と商用プログラミング言語の開発との間にいくらかの分断があることは驚くべきことではありません。特に大規模ソフトウェアの場合、どちらもソフトウェアの構築と進化をより効率的にすることを目的としていますが、産業用プログラミング言語の仕事は、クリティカルマスに到達してネットワーク効果を得るための迅速な導入を促進することにもっと関心を持つ必要があります。これは、働くプログラマが気にすることに焦点を当てた研究につながります。そしてそれは、ライブラリの可用性、コンパイラの速度、コンパイルされたコードの品質、移植性などのようなものになる傾向があります。今日私たちが実践しているプロセス計算は、主流のプロジェクトに取り組んでいるプログラマーにはほとんど役に立ちません（ただし、将来的には変わると思います）。

純粋なプログラミング言語の研究はかなり異なります。プログラミング言語の簡略化されたモデルで動作します。 -calculusは、関数型プログラミングを大幅に簡略化したものです。同様に、 -calculusは、並行プログラミングを大幅に簡略化したものです。これらの大幅な簡素化は、研究を成功させる鍵です。彼らは、コアの計算機序に焦点を当てるために私たちを可能にする（例：π $\lambda$$\pi$$\beta$-関数型プログラミングの削減、論理プログラミングの解決/統一、同時計算の名前渡し）。Scalaのような言語が完全な型推論を実行できるかどうかを理解するために、JVMについて心配する必要はありません。実際、JVMについて考えることは、型推論のより良い理解を損なうことになります。そのため、小さなコア計算への計算の抽象化が不可欠で強力です。

したがって、プログラミング言語の研究は、人々がおもちゃで遊ぶ大規模なサンドボックスと考えることができます。特定のおもちゃで遊ぶときに何か面白いものを見つけ、そのおもちゃを徹底的に調査した場合、その興味深いおもちゃは主流の産業的受容への長い道のりを開始します。プログラミング言語研究者によって最初に発明された言語機能が広く受け入れられるようになるまでに数十年かかる傾向があるため、私は長い行進を言います。たとえば、ガベージコレクションは1950年代に考案され、1990年代にJavaで広く利用可能になりました。パターンマッチングは1970年にさかのぼり、Scala以来広く使用されています。

プロセス微積分は特に興味深いおもちゃです。しかし、それは完全に調査されるにはあまりにも新しいです。それにはさらに10年の純粋な研究が必要です。プロセス理論の研究で現在行われているのは、プログラミング言語研究の単一の最大の成功事例である（順次）型の理論を取り上げ、メッセージパッシングの同時実行のための型の理論を開発することです。逐次プログラミングのための適度な表現力のタイピングシステム、たとえばHindley-Milnerは、広く理解され、広く普及しており、実際のプログラマーに受け入れられています。並行プログラミングには適度に表現力のあるタイプが欲しいです。これに関する研究は、1980年代に、ミルナー、サンジョルジ、ターナー、小林、ホンダなどの先駆者によって開始され、多くの場合、明示的または暗黙的に、線形論理から生じる線形性の概念に基づいています。ここ数年は活動が大幅に増加しており、この上向きの軌道は近い将来も続くと予想しています。また、プロセス計算のトレーニングを受けた若い研究者が産業R＆Dラボに出向いて作業するという実用的な理由だけでなく、CPUとコンピューターアーキテクチャの進化により、この作業は製品中心のR＆Dに漏れ始めることも期待しています計算の順次形式から。

要約すると、私はあなたがプロセス計算のような最先端のプログラミング言語理論をあなた自身の言語構築の仕事に役立たないことを心配しないでしょう。それは、最先端の理論が現在のプログラミング言語の懸念に対応していないからです。将来の言語についてです。「現実の世界」が追いつくまでにはしばらく時間がかかります。今日の言語を構築するために使用する知識は、過去のプログラミング言語理論です。プロセス計算は理論的なコンピューターサイエンスのすべての最も存在する領域の1つであるため、プロセス計算について詳しく学ぶことをお勧めします。

プログラミング言語設計の科学は非常に初期の段階です。理論（プログラムの意味と言語の表現力の研究）と経験主義（プログラマーが管理するまたは管理しないもの）は、言語を設計する際に、何らかの方法で比較検討する多くの定性的な議論を提供します。しかし、決定する定量的な理由はほとんどありません。

ある理論が実用的なプログラミング言語で使用できるように理論​​が安定するまでの時間と、この技術革新が「主流」の言語で出現し始める時間の間には遅延があります。たとえば、ガベージコレクションを使用した自動メモリ管理は、1960年代半ばに産業用に成熟したと言えますが、1995年にJavaで主流に達したに過ぎません。パラメトリック多態性は1970年代後半によく理解され、 200年代半ばにJavaに。研究者のキャリアの規模では、30年は長い時間です。

言語の大規模な産業採用は、社会学者が研究する問題であり、その科学はまだ初期段階にあります。市場の考慮事項は重要な要素です。Sun、Microsoft、またはAppleが言語を推進する場合、これは多くのPOPLおよびPLDI論文よりもはるかに大きな影響を与えます。選択肢のあるプログラマーであっても、ライブラリの可用性は通常、言語設計よりもはるかに重要です。これは、言語設計が重要ではないと言っているわけではありません。適切に設計された言語を持つことは安心です！それは通常、決定的な要因ではありません。

プロセス計算はまだ理論が安定していない段階にあります。私たちは逐次計算を理解していると信じています—逐次計算と呼んでいるもののすべてのモデルは同等です（それはChurch-Turingの論文です）。これは同時実行性には当てはまりません。異なるプロセス計算では表現力に微妙な違いがある傾向があります。

プロセス結石は実際に影響を及ぼします。多くの計算が分散されています。サーバーと通信するクライアント、他のサーバーと通信するサーバーなどが含まれます。ローカル計算でもマルチスレッド化され、複数のプロセッサで並列処理を利用し、環境の同時性（独立したプログラムとの通信）に対応しますとユーザーと）。

より良いソフトウェアを作るために研究の進歩は必要ですか？結局のところ、パイ計算と空のパイを区別できない10億ドル規模の業界が世の中にあります。さらに、その業界は数十億ドルを費やしてバグを修正しています。

「それが必要になるか」というのは、研究において価値のある問題ではありません。何が長期的な結果をもたらすかを事前に予測することは不可能です。私はさらに進んで、どんな研究もある日結果をもたらすことは安全な仮定であると言います—その日が来年か来年のミレニアムのどちらになるかは現時点ではわかりません。

Pi微積分には非常に多くのバリアントがあり、多くの活発な研究がありますが、それらが必要になるか、重要なアプリケーションがあるでしょうか？

私が尋ねる理由は、プログラミング言語の開発が大好きであり、真の最終目標が実際にPLを構築するために理論を使用することであるからです。私が書いたものについては、理論との相関はまったくありませんでした。

これはトリッキーな質問です！私の個人的な意見をお伝えしますが、これは私の意見であることを強調します。

並列計算の表記法として、パイ計算は直接適切だとは思いません。ただし、並行プログラミング言語を設計する前に、必ず検討する必要があると思います。その理由は、円周率計算によって低レベルが提供されるためです。---同時実行のアカウント。その結果、必要なすべてを表現できますが、常に便利であるとは限りません。

このコメントを説明するには、型について少し考える必要があります。まず、有用なプログラミング言語は、一般的に抽象化を構築するために、ある種の型の規律を必要とします。特に、ソフトウェアをビルドするときに手続き型の抽​​象化を利用するには、ある種の関数タイプが必要です。

現在、パイ計算の自然型の規律は、古典的な線形論理の変形です。たとえば、Abramskyの論文Process Realizabilityを参照してください。これは、単純な並行プログラムを線形論理からの命題の証明として解釈する方法を示しています。（文献にはパイ計算プログラムを入力するためのセッションタイプに関する多くの研究が含まれていますが、セッションタイプと線形タイプは非常に密接に関連しています。）

$A \multimap B$$A^\bot ⅋ B$

これはPOV型理論からは問題ありませんが、プログラミングするのは面倒です。その理由は、プログラマーが関数呼び出しだけでなく呼び出しスタックも管理することになるためです。（確かに、ラムダ計算からpi計算へのエンコードは、通常はCPS変換のように見えます。）これで、タイピングはこれを台無しにしないことを保証しますが、それでもプログラマーにとっては膨大な簿記です。

これは、同時実行理論に固有の問題ではありません。mu-calculusは、call / ccのようなシーケンシャル制御演算子の証明理論的な説明を提供しますが、スタックを明示的にすることを犠牲にして、厄介なプログラミング言語にします。

したがって、並行プログラミング言語を設計する場合、私の意見では、生のpi計算よりも高いレベルの抽象化を使用して言語を設計する必要がありますが、賢明な型付きプロセス計算に明確に変換する必要があります。（これの最近の素晴らしい例は、Tonhino、CairesおよびPfenningの高次プロセス、関数、およびセッション：モナディック統合です。）

「本当の最終目標は、理論を使用して実際にPLを構築することです」とあなたは言う。それで、あなたはおそらく他の目標があることを認めますか？

私の見解では、理論の最大の目的は理解を提供することです。これは、既存のプログラミング言語とそれらで記述されたプログラムについて推論する際に役立ちます。私の余暇には、何十年も前にLispで作成された大量のソフトウェア、メールクライアントを維持しています。Hoareロジック、分離ロジック、データ抽象化、関係パラメトリック性、コンテキスト等価性など、私が知っているすべてのPL理論は日常業務で役立ちます。たとえば、新しい機能でソフトウェアを拡張する場合、元の機能を維持する必要があることはわかっています。つまり、新しい機能を実行する場合でも、すべての古いコンテキストで同じように動作するはずです。新しいコンテキスト。文脈的等価性について何も知らなかったとしたら、おそらくそのように問題を解決することさえできないでしょう。

パイ計算についての質問ですが、パイ計算は言語設計でアプリケーションを見つけるにはまだ少し新しいと思います。pi-calculusのWikipediaページでは、pi-calculusを使用する言語設計としてBPMLとoccam-piについて言及しています。ただし、その前身であるCCSのページや、多くのプログラミング言語の設計で使用されているCSP、結合計算などのその他のプロセス計算を参照することもできます。SangiorgiとWalkerの本の「Objects and pi-calculus」セクションを調べて、 pi-calculusが既存のプログラミング言語とどのように関連しているかを確認することもできます。

私は実際にプロセス計算の実用的な実装を検索するのが好きです:)（理論について読むことに加えて）。

1. Clojure非同期チャネルはCSPに基づいています：http : //clojure.com/blog/2013/06/28/clojure-core-async-channels.html
2. Golangには、CSPに基づくチャネルもあります（これは、私が考えるclojureのためのインスパイアされたRich Hickey）：http : //www.informit.com/articles/printerfriendly/1768317
3. Scala（下付き文字）にACPベースの拡張を行った人がいますが、リンクを投稿するのに十分な評判がありません...

等