インタビューC# の主任設計者である Mads Torgersen 氏は、先週の仮想 QCon Plus 開発者会議でこの言語の進化について語り、何がうまくいったか、何がうまくいかなかったかについて率直に語りました。
このプログラミング言語は「約20年前に誕生しました」とトルガーセン氏は言う。「その間、変革の道を歩んできました。20世紀末の非常に古典的なオブジェクト指向言語として始まりました。」
C# は Anders Hejlsberg (他の功績としては Borland Delphi や最近では Microsoft TypeScript など) によって作成されましたが、Torgersen は約 15 年間 C# に取り組んでおり、そのうち 5 年間は主任設計者を務めています。
C# 9.0 のレコードは、同じ型で同じプロパティを持つ場合、等しいとみなされます。
どのように変化したのでしょうか？トルガーセン氏はQConの参加者に対し、C#が関数型プログラミングの機能を徐々に取り入れてきた経緯について語り、いくつかの質問に答えました。C# 1.0にもデリゲート型は存在していました。「関数型のようなもので、色々な意味で使いにくいのですが…それでも十分に役割を果たします」と彼は言いました。
しかし、C#はすぐに進化しました。ジェネリック（C# 2.0）、型推論（varキーワード）（C# 3.0）、ラムダ式（C# 3.0）。実際、2007年後半のC# 3.0は、匿名型、拡張メソッド、そしてクエリ式（後者は言語統合クエリ（LINQ）とも呼ばれます）を備えた大きなリリースでした。
「起こった出来事の多くは、機能的な世界からインスピレーションを受けたり、借りたり、盗んだりしたものです」とトルガーセン氏は認めた。
関数型言語として、C#はScalaと比べてどうでしょうか？「C#が関数型とオブジェクト指向の完全なバランスを実現できる段階には到達できないと思います」とトルガーセン氏は言います。「私たちは常にオブジェクトファーストなので、関数型ファーストの言語と競合することはありません。関数型プログラミングには、非常に多くの要素、非常に多くのイディオム、そして膨大な量の型推論が含まれており、現状では到底到達できないでしょう。」
トルガーセン氏は、近年の大きなトレンドはパターンマッチングであり、これはクラウドコンピューティングによって推進されており、「データはクラウド上にあり、さまざまなアプリケーション間で共有される」と述べた。
オブジェクト指向は、このシナリオにはあまり適していないと彼は述べた。「オブジェクト指向プログラミングは、機能とデータを一緒にカプセル化することに重点を置いています」が、この新しい世界では、「機能をデータと一緒にパッケージ化することはもはや意味がありません。関数は外側に置く必要があります」と彼は言った。つまり、「何らかのオブジェクトを受け取る関数を書く必要があります。オブジェクトは関数の存在を認識しませんが、関数はオブジェクトの型に応じて異なる処理を行います。これがパターンマッチングの目的です」。
パターンマッチングは、2017 年 3 月にリリースされた C# 7.0 で導入され、それ以来着実に強化されてきました。今週 .NET 5.0 とともにリリースされた C# 9.0 では、変数の型に一致する型パターンなど、さらに 6 つのパターン改善が追加されました。
C# 9.0ではレコード型も導入されました。「レコード型によって得られる主なメリットは、デフォルトで値セマンティクスが使えるようになることです」とトルガーセン氏は言います。彼が念頭に置いているのは、「AはBと等しいか」という一見単純な問いです。オブジェクト指向では通常、デフォルトをオーバーライドするための等価性メソッドを記述する必要があり、これは「メンテナンスの悪夢」だとトルガーセン氏は言います。レコード型が導入されたことで、「等価性メソッドとハッシュコード用の合成メソッドは、2つのレコードのプロパティがすべて等しい場合、それらを等しいと見なします」とドキュメントには説明されています（もちろん、レコード型は同じである必要があります）。「これは関数型プログラミングへの新たな一歩です」とトルガーセン氏は言います。
C# は何に適していますか?
C# は誰にとっても万能なものになり得るのか、そうでないなら C# のニッチな分野は何なのか、他の言語の選択肢と比較した C# の特別な価値は何なのか、私たちは尋ねました。
「C#が生まれたのは、WindowsがC++やJavaに少し似た、優れた現代的なアプリ言語を必要としていたからです」とトルガーセン氏は語る。「当初のターゲットは非常に限定的でした。関数型は、関数型プログラミングとは全く関係のないシナリオのために、ほとんど間違えて存在していたのです。私たちは成功を収め、人々に好まれたため、他のシナリオにも進出してきましたが、同時にC#は独り歩きして広まっていったのです。ゲームの世界を見てみると、大多数はMicrosoft社外で開発されたC#エンジンをベースにしたUnityで書かれています。これは、Monoがオープンソースで簡単に変更できたという理由もありますが、C#がそうした点でも好まれたという理由もあります。」
Mads Torgersen 氏、C# リード デザイナー
過去5年間、C#のリリースごとに私たちが行ってきたことの一つは、低レベル機能の強化です。C#は常にアンセーフコードのサポートを提供してきましたが、より安全で効率的な低レベルコードを様々な方法で提供しています。ほとんどの人が使っていないにもかかわらず、私たちはこの分野に多大な投資を行ってきました。なぜなら、アーキテクチャの低レベル部分のほとんどをC#で構築し、.NET上で実行し、移植性を持たせることができるからです。しかし、そこからC#をシステムプログラミング言語と呼ぶのは、私たちが言うべきことではありませんし、それを追求すれば言語の他の部分に悪影響を及ぼしてしまうでしょう。つまり、限界があるということです。私たちは、C#を有機的に成長させ、今価値のあるものを追求しようと努めています。
10年前、C# 4.0で動的型が導入されました。これは実行時に型が解決される機能です。これはC#にとって大きな出来事でしたか？
これは優れた言語機能であり、動的処理への反発の一部でしたが、私たちが感じていたほどではありませんでした。当時、私たちはIronPythonとIronRUbyを開発していました。これらは.NETプラットフォーム上にPythonとRubyを実装したもので、これらとJavaScriptの間に優れた相互運用性を持たせたいと考えていました。そこで、.NET上の動的処理を解決するためのインフラストラクチャ全体を構築しました。
実行時にコストがかかるため、構築方法には若干の後悔があります。これは素晴らしいもので、コンパイラの全機能を使ってオーバーロード解決をコンパイル時ではなく実行時に行うのです。理論的には非常にエレガントで、私は誇りに思っています。しかし、コストとオーバーヘッドが一部のシナリオでは法外なため、このダイナミックな動作はパフォーマンスとうまく両立しません。
「これは C# にとって大ヒット機能というわけではなく、時々少し後悔しますが、時には、通常は組み合わせられないものを組み合わせられる、まさにこの機能が私を幸せにしてくれるのです。」
Null安全性についてはどうでしょうか。C# 8.0では、実行時にNull参照例外を回避するために、コンパイラにNull許容コンテキストを追加する作業が行われましたが、デフォルトでは無効になっています。有効にした場合、参照型はデフォルトでNull非許容となりますが、必要に応じてNull許容として明示的に宣言できます。ただし、これはコンパイラの機能であり、ランタイムによって強制されるものではありません。この点において、C#は適切な位置にあると言えるでしょうか？
「これは非常に大規模で厄介な機能でした。概念的なオーバーヘッドはそれほど大きくありませんが、エンジニアリングの作業と細部へのこだわりは膨大です」とトルガーセン氏は語った。「TypeScriptの設計体験に似ています…TypeScriptには、非常に複雑な型システムがありながら、複雑に感じさせないように設計されているのです。特にnullに関しては、私たちも同じことを試みました。小さな疑問符の注釈をあちこちに配置できるようにすることで、シナリオ全体に美しく流れるようにしたかったのです。」
「C# 9.0 では、もう少し時間をかけて、これはエラーではなく警告だけの問題だと判断しました。自分たちで調整していくつもりです。今は、その長い道のりの途中だと思います。ほぼ完了したと思います。」
C# で廃止したい機能があるかと尋ねられると、トルガーセン氏は「関数リテラルや匿名メソッドへの最初の試みは、扱いにくいミスでした。C# 3.0 ですぐに上書きしてしまいました。もちろん、削除することはできません」と答えた。
プログラミング言語には何かを追加することはできても、削除することはできない、というのが現状です。「人々はコミットしたコードを持っているので、何かを削除したり意味を変えたりすると、多くのものが壊れてしまいます。私たちはそうすることができません」と彼は言いました。®
