プログラミング言語処理系が好きな人の集まりというコミュニティーがあります。ここは言語処理系を作っている人が多く集まっています。自作言語界隈とも言えます。そこでの話題について、色々と思うところがあったので、記事を書いてみます。
まず、「オレオレ言語界隈も標準化委員会を作って統一した言語を作ってみてはどうですかね？」という意見について。
私としては統一言語はいい考えとは思えません。独自の言語を作る人は、学習用のものを除けば、既存の言語ではできないこと（簡潔な記述、アイディアの実現）を実現したくて作っているはずです。なので、統一言語を仮に制定したとしてそれに満足できない人が新しい言語を作るだけです。
統一言語でなくても、ある程度コンパイラーの基盤を共有するという考えもあります。コンパイラー基盤と言えばLLVMですね。フロント側ではlex/yaccみたいなやつもあります。なのでこれは実績のある考え方なのですが、大抵は「実装に使う言語」という壁があります。
lex/yaccは言語ごとに存在します。バックエンドに関して例を挙げると、MLRISCというコンパイラーバックエンドの基盤がありましたが、Standard MLで書かれているので他の言語からは使えません。LLVMは中間言語の外部表現があって比較的言語依存しない方ですが、REPL等から高速に呼び出すためにはC++のインターフェースを経由する必要があったとSML/NJのレポートに書かれていました。
なので、実装に使う言語が異なると使える基盤も違っていたりして協働しづらいということです。LLVMは例外的です。
次に、パーティーを組めばいいのではという意見について。
私個人的にはこれも難しいのではないかと思います。複数人のチームで一つの言語を作る例はありますが、職場が同じだったり、ある程度お互いの状況を知っていて信頼関係が築けている間柄の人たちが多いのではないでしょうか。オンラインの、趣味でやっている人が多いコミュニティーでは、方向性が同じだったとしても、それぞれ費やす熱量とか信頼の差があり、歯車が噛み合わないことがあるのではないかと懸念されます。
もちろん、言語がある程度形になり、方向性も明確になった後なら、貢献したい人が現れて共同のプロジェクトになることはあり得ます。ですが、開発の初期段階では個人で作業するのが自然なのではないかと思います。
他にも「就職活動のための言語作り」とか「国を背負って立つべきリーダー」とか、突っ込みたい発言は色々ありますが、ほどほどにしておきましょう。
否定ばかりしていては建設的ではないので、こういうコミュニティーが提供できる協働の在り方について、私なりの考えを書いておきます。
まず、具体的なコードや成果物を共有するのは、既に述べた理由で、条件が揃わないと難しいでしょう。
従って、共有しやすいのはもっと抽象的なもの、知見・アイディアになります。
言語処理系を実装する上でぶつかる問題の種類は言語に依存しないことが多いでしょう。フロントの書き方、最適化のやり方、コード生成の仕方、あるいはVMやGCの書き方。こういう知見を共有することは有意義です。
こういう知見は既に論文という形で公開されていることが多いかと思いますし、論文にできる内容であれば論文として書くべきかと思います（私自身は投稿論文は書いたことがないのでちょっと無責任発言っぽいですが）。論文にするほどでもない、既存の論文の日本語での紹介とか、サーベイみたいな内容であれば、日本語のブログ記事とかでも十分だと思います。
（私がこのブログに書いているLunarML進捗報告も、もうちょっとトピックごとに分かれていれば読みやすいのかもしれません。）
もっと抽象度を上げて、「言語の各部分を設計する際のベストプラクティス」も知見として有益だと考えられます。
例えば、新しいプログラミング言語を作りたいけども、数値型に関してはそこまでこだわっておらず、「普通」でいいや、という考えの人がいたとします。ですが、数という誰でも知っている概念であっても、計算機言語で取り扱う上では落とし穴や失敗と考えられる先例が色々あるわけです。こうした失敗例や、ありうる「良い」設計をまとめた文書は有益であると考えられます。
数値型だけじゃなくて、文字列や日付・時刻なんかにも同じようなことが言えます。ライブラリー面の知見だけではなくて、モジュールシステムやパッケージ管理の知見もあると良いでしょう。
というわけで、早速ひとつ書きました：
gfn氏もこういう方向性の記事をいくつか書いておられます：
この記事の結論は、「知見を文書として共有しよう！」ということになります。