プログラミング言語と妄想

昨日、友人とチャットしていて考えたことを、だらだら箇条書き。

• プログラミング言語には、bashのような改行コードで区切られる行を構文要素として持つものと、Cのように構文要素としては持たないものがある。Haskellなどのようにインデントの深さを構文上意味あるものとみなす言語と、Cのように意味を与えない言語がある。PHPなどのように「地の文」の概念があってプログラミング的な処理を埋め込むためには特別な指標を必要とする言語と、地の文の概念がない言語がある。関数型言語か、手続き型言語か、動的型か、静的型かという理論的も問題もさることながら、上記のような単純な見た目・構文スタイルの点で、利用目的に対する適否があるので、ナンバーワン・プログラミング言語、オンリーワン・プログラミング言語は登場しないだろう。

• 最近、「地の文」という概念は、けっこう重要なんじゃないかという気がする。これは、伺かを観察して思ったこと。

• .NET Frameworkは正しい方向を向いているように思う。静的型のコンパイラではコンパイル時・リンク時に警告がでるし、動的型のインタプリタでは実行時に警告が出る、という両方に対応できるところも優れている。以前から、Cのライブラリを中心にラッパーをかぶせて他の言語のコンパイラやインタプリタから呼び出せるようにするテクニックもあり、Javaにもリファレンスを使った技術があるが、はじめからコンパイル言語もインタプリタ言語も、動的型も静的型も意識して複数言語の共通基盤を提供しようという方向性が良い。ただ、.NET Frameworkと純粋関数型言語との相性はどうなのかな。アセンブリに組み込む属性をうまく使うことによってある程度は吸収できるだろうが。

• 友人がErlangに関心を示していた。HaskellやConcurrent Cleanをちょっとだけ覗いて啓蒙を受けた身としては、明示的な並列処理と関数型言語っていうのは両極端な組み合わせに感じるが、だからこそ良い取り合わせなのかもしれない。Erlangはさっぱり勉強してないのだが、個々の処理は関数型言語の堅牢性を、処理の組み合わせは並列処理の柔軟性を、並列処理における競合の問題はプロセス間メッセージキューの処理に一本化することを強制することによる解決を、というのは賢いのかもしれない。

• Erlang.NETを作った奴は英雄になれるかもしれん。

• 関数型言語の文法は、Haskellのやつが一番直感的なような気がする。こういうのは慣れの問題が一番大きいが、LISPはすぐに不明瞭なコードを書けてしまうのは鉄板。Erlangは慣れれば読めるんだろうが。

• Haskellのdo構文の「<-」の理解が躓きの石という気がする。

• というわけで、Hakell風の文法で、「地の文」の概念があり、マクロみたいな順次実行もでき、do構文の「<-」が分かりやすく概念化されていて、Erlangみたいな並列処理がある、.NET Frameworkに対応したインタプリタを誰か作ってください。