読者です 読者をやめる 読者になる 読者になる

『【13-B-7】言語の現在・過去・未来を語る』話題メモ - C# side

.NET

Developers Summit 2008『【13-B-7】言語の現在・過去・未来を語る』のメモ.C# side.
誰かメモを公開してくれてるかなぁと勝手に期待してましたが,裏番組に id:amachang の『【13-D-7】JavaScript Tips & Technique』が入っていたせいもあってか今のところあまり見ないですね.というわけで憶えているうちに少し書いておきます.なお,これで全部じゃないのと,話題に上った順序とは必ずしも一致していないことに注意.あちこち話題が飛びながらまったり聞いて楽しむ感じの内容でした.「ラジオの深夜放送みたいだった」という渋木さんの表現はまさにぴったり.
以下の内容で興味を持たれた方は,当日聞いていた人を適当に捕まえて詳細を聞き出してみて下さい.

波村さん自己紹介

  • C# との出会い
    • インターンで Microsoft に行ったのが出会い
      • 「Windows のような巨大なプロダクトをどうやって開発しているんだろう?」という興味から
      • インターンの配属先が当時まだ秘密だった C# チームだった.
        • 配属先が決まって受付行ったとき,受付のお姉さんから「こんなビル (部署?) 聞いたこと無い」と言われた
          • COOL (C like Object Oriented Language) などのコードネームで呼ばれていた時代
  • 波村さんと関数型言語
    • 大学の課題で,scheme を使って人工知能を作ったことがある
      • およそ関数型言語らしからぬプログラムを書いてしまった
      • 100 行を超えるコードになってしまい,結局動かなかった
      • 正解が非常に短い (20行ぐらい?) コードで驚いた

C# の言語仕様

  • クエリ式の,from x in xs という構文について
    • 当初は foreach(var item in source) where ... といった構文も検討されていた
    • Anders はクエリ式に 1 年ぐらい反対していた
      • しかしユーザビリティテスト (テスタに新しい構文を試してもらう) をやってみたところ,メソッド方式では誰も join を書けなかった
    • SQL での語順を弄って,select よりも from が先に来ているのは,IntelliSense で型情報を使うため
      • 2005 年の発表段階では,Visual Basic は select x in xs だった
        • VB では当初 select x を書いた時点で in xs まで自動生成されたが,カーソルが前後に激しく動くのが使いにくいということで結局 C# 方式に変更された
        • (Anders) 「だから言っただろ」
    • from from in xs は,当初書けるようにするつもりだったが,文法上の曖昧さが起きることが分かってサポート外となった
      • 常に複数のパーサを書いて検証している
      • yacc だとコンパイルエラーが扱いにくいので結局手書きになる
      • Visual C++ は最も yacc を酷使しているコンパイラのひとつかも?
        • yacc の結果を yacc で処理するようなことをしている
  • var による型推論の話は C# 1.0 の頃からあった
    • 当時は JavaScript に間違われると「良くない」と思われていた
    • 今は状況が変わった
  • 今では Ruby がデザインミーティングで話題に上ることも
    • (Anders) 「Ruby ではできるのになんで C# ではできないんだ!」
  • 昔,まだ海外で Ruby がそこまで騒がれていない頃,波村さんが Anders に Ruby の話を振ったらスルーされた
  • 今 Anders が興味があること
    • メタプログラミング
  • 言語設計で後悔していること
    • anonymous method で yield が使えないこと *1
    • void の扱い
    • Equals の扱い
    • null の扱い
      • Ruby の nil はすばらしい
    • Tuple を入れるとしてもパターンマッチの文法をどうするかの良い解決法が見つからない

C# のチーム規模

  • C# 2.0 の時点で,言語開発は 10 人
    • designer 3 人
    • developer 5 人
    • tester 2 人
  • IDE 等を含めるともっと増える
  • 今はもっと増えている

C# の開発形態

  • デザインミーティングは週 3 回,各 2 時間
    • 言語仕様が決まったら実装してみてテスト
  • C# 1.0 がリリースされる頃にはもう,Microsoft Research からほぼ動く形の Generics 実装が上がってきていた
    • 結局ほとんど書き直して 2 年ぐらいかかった
      • 中身はほとんど同じ
      • 「シンボル名の付け方が Research くさい」のが気に入らない等々
      • 後でマージするときに困った
    • もたもたやっていると Research の連中は勝手に fork して自分たちで言語拡張をやり出す
  • ソフトウェアってのはやはり属人的な面が強い
    • 2 週間ぐらい黙々と作業して一気に書き上げてチェックインする人も
      • 「機械のような奴」と呼ばれている
    • チェックインしてすぐに vacation に出かける奴がいて困る
  • お気に入りのところは Anders がコードを書くことも
    • でも実際に製品コードにするには色々テストとかチェックリストがあってそこまでやってくれる訳じゃない*2
  • できれば C#C# コンパイラを書き直したいけどそのコストが正当化できないため未だにできない*3

C# の要望の上げ方

  • 色々なチャンネルがある
  • 要望は一旦 PM がとりまとめて適当に集計して Anders に提出される
    • 確実に reject されるものはここで落とされる
      • でも以前 reject されたものが通ることもあるから難しい
    • Anders の機嫌が良さそうなときにリストの上から挙げていく
  • 波村さん自身がプッシュして採用された部分も
    • C# 2.0 の yield return は,最初 yield のみだった.return があった方がよいと波村さんが推して通った.

C# の互換性

  • ある言語仕様が,後でどう影響してくるか,最初から見通すのは非常に困難
  • 今回波村さんが来日するときに,「Ruby の変数スコープについては触れるな」とアドバイスされた
  • 一度決めた言語仕様の変更は非常に困難
    • 既に社内で多数の C# プロジェクトがある
      • 現在,Microsoft 社内での新規プロジェクトの半分は C#
      • 別部門でのトラブル対応が副社長経由で降ってくることも
      • C++ コンパイラチームには,ビルド時間が 10 % 増えただけで Windows チームから「バグ」が上がってくる
        • 48 時間かかるビルドが 52 時間になると色々問題が起きる
  • foreach に対して出力する IL コードを変更しただけで,問題が報告されてくる
    • IL 解析ツールの動作が影響を受けた


過去の関連記事

*1:2009年9月5日追記: [http://blogs.msdn.com/ericlippert/archive/2009/08/24/iterator-blocks-part-seven-why-no-anonymous-iterators.aspx:title=]というエントリがある

*2:参考,「BEST SOFTWARE WRITING」より『電球を替えるのにMicrosoft社員は何人必要か?

*3:以前波村さんにお聞きしたところ,Microsoft の C# コンパイラC++ で書かれているそうです.ちなみに mono の C# コンパイラC# で書かれています.