一
1、C#設計過程
?
Bruce Eckel：我聽說C#是一個工程師小組在一個屋子裡設計出來的？
Anders Hejlsberg：是的。4年來，我們一直呆在這個屋子裡。現在，每周一、三、五，我們仍然在這裡會面。
Bruce Eckel：我很想了解一些關於C#設計過程的情況。我直接或間接參與過幾種語言的設計工作，如Python。在Python設計過程中，Guido van Rossum被我們戲稱為“仁慈的獨裁者”。
Anders Hejlsberg：哦，Guido van Rossum就相當於我的位置。
Bruce Eckel：那麼你是C#小組“仁慈的獨裁者”麼？
Anders Hejlsberg：我一般扮演最後拍板者的角色。比如，我們被一個問題困擾多時，到了非解決不可、只能作不二選擇的時候，是由我來作最後決定的。當然大多數這樣的情況下，正確的選擇是顯而易見的。
Bruce Eckel：C#的設計過程是不是和Turbo Pascal、Delphi十分相似？
Anders Hejlsberg：後面兩者的設計過程不是那麼規范的。因為Turbo Pascal主要由我一個人設計，而Delphi也是我和Chuck Jazdzewski、Gary Whizin等幾個為數不多的人來完成，所以沒有必要引入非常規范的設計過程。相反的，C#的設計過程則十分規范，每周一、三、五從1：00到3：00, 我們都會召開一個正式會議，會議議程也相當靈活，所有的問題都會拿到桌面上公開討論、仔細推敲。我們還在互聯網上建立了一個Wiki，這些問題及其解決方案，以及其他一些相關的東西都被發布在上面。
Bruce Eckel：那你們是如何發現這些的問題呢？
Anders Hejlsberg：呵呵，我們有一套行之有效的方法。我們可以通過很多途徑來得到用戶對語言設計的反饋意見——如軟件設計咨詢會、網絡新聞組。這些反饋意見包括：疑問、軟件Bugs、不一致、不規范問題等。這樣我們就能有的放矢了。最後我們將這些問題整理成表，並一一重現它們。對於每個問題，我們都會認真對待，詢問自己：“我們對這個問題有新的想法嗎？真的沒有嗎？這個問題已經擱置好幾個星期了，我們立即花30分鐘集中精力研究一下，看這次是否能有所斬獲。”
Bruce Eckel：那可能一個問題長期沒有解決，都臭不可聞了……
Anders Hejlsberg：也許有些臭問題只有放到下一個版本才能解決了。但是我認為這樣一個過程可以保證不會遺漏任何問題，因為它們都被登記在冊。有時候，你面對這些問題呆坐了很長時間，可能也沒什麼結果。但問題畢竟是被我們逮住了，總有一天會再去“拜訪”它的。也可能不會再去“拜訪”了，但問題終歸是不會被弄丟的。
Bill Venners：C#設計小組包含哪些成員，他們都擔當什麼角色？
Anders Hejlsberg：參與最初的C#設計的有Scott Wiltamuth、Peter Golde、Peter Sollich、Eric Gunnerson和我。C#2.0設計小組包括：Peter Hallam、Shon Katzenberger、Todd Proebsting，以及我自己。微軟研究院的Don Syme和Andrew Kennedy承擔了大部分一般性研究工作。
?
?
2、語言可用性研究和語言美學
?
Bill Venners：在C#的設計中，可用性研究、市場策略和語言美學的側重是如何權衡的？
Anders Hejlsberg：一般而言，好的語言設計過程體現了對設計小組成員的美學品味取向的綜合，也就是你剛才所說的語言美學觀。美學品味帶有極大的主觀性，很難定論，只有產品出來後，你才能仔細體味它。我認為任何程度的可用性研究都不能取代語言美學的價值，因為可用性研究是極有針對性、非常具體的。可能有人問你：“你認為這部分功能如何？”這個問題很難回答。“你對這個語言有什麼看法？”你從何談起呢？你怎麼可能花兩個小時就解決掉所有可用性問題？絕無可能。
Bruce Eckel：人們必須深入理解這個問題。
Anders Hejlsberg：使用一種編程語言會經歷一個感覺微妙變化的過程。只有使用幾個月之後用戶才能真正喜歡上它。他們會逐漸發現：“哦，它給人的感覺很舒服嘛。”你不能急於求成。
開始說過，我們在可用性研究上也做了大量工作，但主要是針對特定的功能。
Bill Venners：可以舉個例子麼？
Anders Hejlsberg：我們將可用性研究的重點放在了IDE功能實現上。我們會問自己：“用戶是否知道在這裡點擊右鍵會有什麼結果？”在純語言功能部分，我們也考慮了一些可用性問題——例如在一些屬性和事件上——不過沒什麼必要，真的。
我想在可用性研究上，語言特性不可能帶來和IDE特性一樣高的收益。你可以看到用戶點擊一個菜單項立即得到正確的反饋信息。
