飽きっぽい人のブログ

プログラマとしてもテスターとしても中途半端な人のブログ

C# for Systems Programming

リーク情報ではM#とも呼ばれているマイクロソフトが開発中のC#をベースとした新しい言語らしいですね。
すでにM#という全くの別物が存在します。関係ないですが
去年の暮れぐらいに公開された中の人のブログでは、今年の半ばぐらいになんらかの情報開示がされるとのこと。まあお蔵入りになる可能性も高いですが
なんとなく和訳したくなったのでしてみました。といってもGoogle翻訳頼みなので英語読める人は原文読んだ方がいいと思います。
原文のブログ:C# for Systems Programming
尚、訳注は[]で括った中に書くものとします。

--------------------------------------------------------------------------訳ここから--------------------------------------------------------------------------
このブログはいくつかのコミュニティの対話を容易にするための投稿がかなり多くなっている。

私の履歴からすれば明らかなように、私の研究生活は[プログラミング]言語であると説明される。それ以外の何物でもない。
MSR[マイクロソフトリサーチ?]の者として考えれば文書公開は私のブログではなくPLDIへ提出手続きするのが妥当だ。
私は単にこのような論文が受理されて取得するのに十分な才能がないだけだ。

私は、何らかの"深い意味"か"手がかり"だからではなく、オープンな精神で全てのコミュニティの連携の書き込みを今後数ヵ月で期待していますが、それは既に進行中かもしれません。あまりにも多い憶測だ![訳が微妙]

私は熱意を見るのが大好きだから、今後来る技術的な対話の場を保管してほしい。他の思惑は静かな死を迎え、私は幸せになるだろう。

私のチームは過去4年間C#に"システムプログラミング"拡張の設計と実装を行っている。やっとのことで、私はブログ記事のシリーズで経験を共有することから始めるだろう。

第1の疑問は"なぜ新しい言語なのか?"だ。私はすぐに、世界は言語を過度に持っていることを認めるだろう。

理由は次の通りだ。
もしあなたが"安全性と生産性"と"パフォーマンス"を軸として主要言語の範囲を描く場合、あなたは以下のようなものを描くかもしれない。

f:id:qwerty2501:20140504234730p:plain

(これは話半分に聞いてほしいのだが、私は多数の安全性の種類があるなどのことによって、安全性と生産性(それらは確かに連携しているけれども--どの程度の時間と労力を見るかは、一般的に安全なバグ、lintツールなどと一緒にすごすかだ。)が等価ではないと理解している)

まあ、私は今日の言語コミュニティは4分割された領域の内、2つの大きな領域に支配されていると主張している。

図の左上の領域についてだが、開発者の生産性を重視し、ガベージコレクションを備えた言語がある。
過去数年にわたり、Googleが先導して方法と何ができるかを見せてくれたおかげで、JavaScriptのパフォーマンスが劇的に改善している。
最近ではみんながPHPと同じことをしてきた。動的型付け言語ファミリ全ては現在与えられているC#Javaのように彼らの金のために実行されているのは明らかだ。[訳が微妙]
現在の選択肢は、パフォーマンスを控えるか、より多くの静的型システム望むかということになる。
これは、C#のような言語がますます排中律に苦しむ苦しむことになる。真ん中は悪い場所ということだ。

図の右下について、パフォーマンスに対して最大限の努力を発揮することができる。
正直、ほとんどのプログラマは図のこの領域にC#Javaを置かないだろうだろう、私も同意見だ。
多くの人々が苦い思いをしてガベージコレクションからC++に逃げ戻ったのを私は見てきた。(公平を期すために、これはガベージコレクション自身の部分的なものだけだ。それは主にデザインパターンが貧弱だったり、フレームワークだったり、言語での改善機会の喪失によるところが大きい。)
Javaはコードのピッチングとスタック割り当てを採用したHotSpotのような仮想マシンでの素晴らしい働きにより、よりC#に近い。
しかし未だに、ほとんどのハードコアシステムプログラマはパフォーマンス上のアドバンテージのため、C#JavaよりもC++を選択する。
C++11では生産性と安全性の分野でC#Javaのような言語に近い調整が行われたにもかかわらず、それはC++に型安全性の保障を追加するための明示的な目標ではない。最近では危難に遭遇するのは減少したが、私は妊娠と同じように、"あなたを半端な安全にすることはできない"と固く信じている。
その存在はあなたが常に最悪のケースを想定し、型システムが持っている安全性よりも事後の安全性を回復するためのツールの使用する必要があることを意味している。

私たちのトップレベルの目標は、本当に図のこれらの領域の間で選択する必要があるかを探ることだった。つまり、右上のどこかにスウィートスポットがあるのかということだ。
巨大なコードベースにこれを適用するなどをして数年の作業の後、私はその答えが"Yes!"であることを確信している。

その結果は完全に新しい言語より --最小限の破壊的変更を施した-- C#の拡張セットの詳細を見るべきだ。

次の疑問は"なぜC#をベースにしたのか?"だ。型安全は私たちが希望する言語の譲れない機能だ。
そして"現代的で型安全なC++"としてキャンバス上に描き始めるにはC#が滅茶苦茶良かった。
特にラムダやデリゲートといった現代的な機能が存在するため、Javaよりは私たちが望むものに近い。
最近ではD,Rust,Goなど多数の言語が候補としてこの場に挙げられた。
しかし私たちが始めた時にはこれらの言語はまだ十分に表面化していないか、もしくは私たちが焦点している意図した領域にまだ投資がされていなかった。
それとまあ、私のチームはマイクロソフトで働いており、ちょうど手の届く範囲内に特に顧客をベースに十分なC#の才能とコミュニティがあった。
もちろん、これら他の言語コミュニティの専門家との協力を熱望しているし、すでにいくつかの重要な人々とアイディアを共有している。
良いニュースなのは、CやC++,Haskellそして深い型システムを起源とする私たちの系譜が分野領域で働いていることなどがあげられる。

最後に、"なぜC++ベースにしないのか?"とあなたは不思議に思うだろう。
ここまでに述べたように、私は多くの場合、私たちがC++で開始する必要があるかどうかを疑問に思うし、言語の"安全なサブセット"を切り開くのとは逆方向に働いた。
私たちは"ミキサーの中にC#C++を投げ入れて何が出てくるかを見て、"そしていつもC#が私たちによって引き止められるのを認めるだろう。
特に、あなたがRAII、決定的な破棄、参照、その他ジェネリックとテンプレートの対比について考え始めることで絶妙なブログ投稿となる。[このあたりも訳が微妙・・・]
私は教訓を得ることといずれ手段を探ることを期待している。主に以下の二つの理由による。
(1):それはより多くの開発者(地球上にはC#開発者よりもC++開発者の方が多数いる)のために移植性を容易にする
(2):私はOSSコミュニティが困難な"安全性と生産性 VS パフォーマンス"の決定を常にする必要がないように、アイデアを標準化するのが夢だからだ
しかし、最初のプロジェクト目標のために、リッチな.NETフレームワークを設計図として使用するといった理由ではなく(私たちの目標のためには重い変更が必要であると指摘されている)、C#で始まったことに満足している。

私は長年の仕事にわたって、いくつか気付いたことがあった(例として、ここここを見てくれ)。
今後数ヵ月で、私はより多くの細部の共有を始めるだろう。
私の目標は最終的にはこのことをオープンソースにすることだが、言語のいくつかの側面について話をやめる必要があり[訳が微妙]、また、より重要なことでRoslynへのコードベースでの移行が必要になる。そのため、C#との関連性はよりエレガントになる。うまくいけば2014年に。

高レベルの目標では、以下の6つの主要なカテゴリに言語機能を分類した。

1) Lifetime understanding
C++はRAII、決定的な破壊[デストラクタ?]、およびオブジェクトの効率的なアロケーションを持っている。C#Javaは開発者をうまく扱ってGCヒープにあまりに大きく依存させているが、IDisposableを経由して、決定的な破壊のための唯一の"ゆるい"サポートを提供している。
私たちのチームのやることの一部は、定期的にC#をこの新しい言語に変換することだ。そして、私たちに30~50%のGCにかかる時間に遭遇することが珍しいことではなかった。
サーバーの場合、これはスループットを殺す。クライアントの場合は、それが対話の待ち時間が入ることによってエクスペリエンスを劣化させる。
我々にはC++から盗んだ記録がある。 --右辺値参照、ムーブセマンティクス、破棄、参照/借入のような領域において-- そしてまだ安全性の必要な要素を保持し、関数型言語からのアイデアでそれらを統合した。
これは、積極的にオブジェクトはスタックアロケーションし、確実に破壊し、より多くのことができる。

2) Side-effects understanding
これはOOPSLA 2012で公開された革新的なもので、第一クラスの普遍性と隔離と一緒にC++const(を安全にしたもの)を与える。

3) Async programming at scale
コミュニティは継続渡しや軽量ブロックコルーチンを使用するかによって堂々巡りをさせられてきた。
これはC#だけでなく、地球上のほとんど全ての言語が含まれている。
ここでの重要な技術革新は、実行モデルにとらわれない構成可能な型システムであり、いずれかに効率的にマッピングすることができます。
それは我々がこのようなものを正しい方法で公開しなくてはならないという傲慢だが、他の多くのアプローチ経験を持つ私にとって大好きな着地点だ。

4) Type-safe systems programming
型安全はパフォーマンス固有の消失になるという主張だ。
それは、境界チェックが譲渡禁止であり、我々は既定でオーバーフローチェックを好むということは事実である。
JITコンパイラと比較して良い最適化コンパイラはこれに対して何ができるかは驚愕的だ。(これらの機能でメリットがあるのは、いくつかの最近のセキュリティ情報を監査必要がある)
他の領域ではアロケーションなしに多くを行うことができるように含まれている。(委譲や表示のためというよりはむしろ)アロケーションなしで呼び出すことができる、ラムダベースのAPIを持っているようだ。
そして、アロケーションなしで容易にサブアレイ及びサブストリングを切り開くことができる。[所有権を持たない配列や文字列を指しているのだろうか]

5) Modern error model
これはコミュニティが同意しないものの一つだ。私たちは私が信じる以下のようなスウィートスポットを選んだ。
至る所での契約(事前条件、事後条件、不変条件、アサーションなど)。
fail-fastを既定のポリシーとする。
例外は珍しい動的な失敗のものとする(I/O構文解析など)。
型付けされた例外は絶対に必要とするリッチな例外のみ。
動作を安全かつ健全にするために、全ての適切な必要動作を取得するように、第一クラスによる型システムに統合されている。

6) Modern frameworks
これは、非同期LINQ、パフォーマンス上のC++イテレータと競合と要素の抽出のために二重のインターフェース要求しない改良列挙子のサポートなどといったものをカバーする包括的なバケツだ。
ぶっちゃけ、これは我々がもっている"設計されたが、まだ実装されていない"リストの一番大きなもので、void-as-a-1st-class-type[第一クラス型としてのvoid]、non-null types[非null型]、traits、 1st class effect typing[第一クラスの効果型?]などがある。
私たちが2014年半ばに一部を持っていることを期待するが、そう多くはないだろう。

興味があるなら、私はあなたがどう思うか全体的な考え(だけではなく具体的にも)について聞くことを熱望している。また、側面の人々にはさらに詳細を聞きたい。
私は共有することに興奮している。しかし、現実には今後数ヵ月で書くのには多くの時間を持っていない。
我々がやらなければいけないことは大量にある(ま、人材募集中てことだ[原文にメールリンクあり])。
だが私はなにを共有し、どのような順序で優先順位を決定するかの補助のために、確実に君たちが好きだ。[訳微妙]
最終的に我々が実際のコードを共有する日が来ることを熱心に待っている。それまではハッピーハッキングだ!