这篇是Visual C#产品经理Dan Fernandez的反驳.只翻译大概. http://blogs.msdn.com/danielfe/archive/2005/02/22/378343.aspx
1.针对.Net FrameWork过大,重达25M的反驳
或许我有些较真,不过.Net FramWork是23.7M.Java 的运行时小一些,但也有15M.Richard所指的.Net程序更多的是指客户端或者公共客户端(意味着不在防火墙内).例如,你将.Net FrameWork安装在Server上或者在局域网内，绝对不会出问题。甚至在公共客户端上，也有很多的共享组件从有些到RSS阅读器都需要.Net FrameWork的支持。我跟很多的共享组件开发人员聊过，他们都没有用Java，很多人用了C/C++,VB,Delphi.事实上有很多开发者已经下载了.Net FrameWork。
1.针对.Net FrameWork过大,重达25M的反驳
或许我有些较真,不过.Net FramWork是23.7M.Java 的运行时小一些,但也有15M.Richard所指的.Net程序更多的是指客户端或者公共客户端(意味着不在防火墙内).例如,你将.Net FrameWork安装在Server上或者在局域网内，绝对不会出问题。甚至在公共客户端上，也有很多的共享组件从有些到RSS阅读器都需要.Net FrameWork的支持。我跟很多的共享组件开发人员聊过，他们都没有用Java，很多人用了C/C++,VB,Delphi.事实上有很多开发者已经下载了.Net FrameWork。
2.关于.Net FrameWork的设计
如果仅仅通过一个简单的程序就判定语言的异同，那未免太小儿科了。
for(int i=0;i<X;i++)
{
......
}
你能说出是哪种语言写的吗？如果你回答C，C++或者Java,你答对了。
3.关于.Net支持接口但更希望用类
接口在.Net FrameWork中到处可见，接口对于C#,VB这种单继承的语言有着更加重要的作用。甚至于连简单的string都有IComparable，ICloneable，IEnumerable。
我们没有更喜欢哪种机制。我们只是提供指引，开发人员可以按照适合自己的方式去开发。我们的示范和实践小组提供指引和最佳实践。在其中我没有发现任何倾向于类实现甚于接口。