为什么软件必须编译

java的目的是用于多平台，所以不能编译成本地代码。
可以参见gcj，这是Source直接编译成本地代码的编译器。http://gcc.gnu.org/java/
想象一样开发环境是windows,那么编译器如果编译成本地代码，那么发布到unix上肯定不行了，除非重新编译一遍。但是本地代码到本地代码重编译又造成恐怖的问题，那还不如不要引入java，直接用c或delphi。
所以java或一般跨平台的语言有两种方式，一种是字节码或中间码，象java和.net，另一种是解释运行，象perl之类。

十分同意。我就是喜欢利用编译时期的类型检查。一般改完编译错误，程序就可以运行。对于很多工厂模式中大量利用字符串来决定创建的类型,我是不赞成的。用字符串传递参数通常会产生运行时才能发现的错误，并且难以测试。当然，返回强类型的编程方式可能会丧失一些灵活性，可是相比之下，我更喜欢稳定性。
我的编程设计原则之一就是尽量把运行时错误转化作编译时错误。
我还想发明一个词，叫做 cno编程,意思是compile and ok,可惜我不是什么大师，没有这个资格。

用C++模板写的泛型程序就是“compile and OK”的。只要编译好，结果也已经算出来了。很多我们认为是业务逻辑、要到运行时才能检查的东西，用C++泛型可以在编译时检查，这个价值是很可观的。

最简单的例子：有个List，一头往里放，另一头往外取，取的人和放的人想法是否一致呢？就只有到运行时才知道——要是俩人想法不同就抛个ClassCastException。现在我们有了泛型容器，我创建这个List的时候就写List<Person>，你一看就知道：“哦，这是拿来放‘人’的，我就别再打算从里面取几只狐狸出来了。”俩人产生误会的几率减小了，开发效率提高了。

可惜Java的泛型采用类型擦拭的实现，而不是像C++那样代码铺开，这个说到底就是降低了类型检查的强度。所以Java的泛型也没什么更大的用处。

虽然如此，还是觉得这个泛型挺有用的。c++那个说穿了太复杂，又没有约束，gp倒是编译时候出错，错误比运行时的还难调，有时候就是想骂娘！c#的泛型不错的。够简单实用。
有人说java的类型检查是又繁琐，也检查不出太多错误。浪费了开发时间，还是要花大量时间调试。
haskell的类型系统强得多。基本上编译成功了，就离目的地至少有一半了。

同意gigix 的观点， 编译时进行的强类型检查是开发高质量大型软件的保证。关于这一点， 可以参考 〈c++ design and evolution > 一书中对c++ 类型系统的考虑。
C++ template 对强类型检查的支持是C++ template 一个显著的优点。

动态的脚本语言在大型系统的开发中为什么只是用来开发测试，工具等周边的东东， 是因为对软件质量的要求不同。 软件中 bug 导致的后果不同。

femto 的问题不成立，是一种期待一个简单的一揽子解决方案的懒汉思想。 问题的复杂性导致了解决方案的复杂性，每种技术有它的适用之处。没有 silver bullet.

动态语言有他的适用之处。但是没有一个大型系统是完全用动态语言开发的。

动态语言的效率也是一个大问题。就不讨论了。

另外，感觉这篇帖子不应该是精华帖，除了gigix 及相关言论 说得有内容， 大部分都是言之无物，言不及意。

多有得罪。 :-)

我想还是效率的问题，如何在开发速度与运行速度上找到平衡点，如果真要这样做我估计改进编译器还不如从CPU从操作系统出发了。
其实楼上的各位总结的已经很好了~

不单是C#，java也可以动态编译，只不过C#在语言生成上的技术更成熟，可以构造出不同的语言。（目前只有C#和VB.NET)

大家有没有想到过 版权的问题啊？

其实现在 也完全可以做到你们需要得啊，
你把代码拿到客户那，在安装得时候再编译，用ant可以容易得达到编译－部署....