主题：【调查】大家都主要用什么写程序？ -- 还是不懂
家园 看需要了 简单地讲，就是需要决定供给。
对于有一定底子的软件人员来说，临时学一门新的语言并不是很困难的事情，只要有足够的资料，一周到一个月应该差不多了。当然，变成高手的时间远不止此。
Fortran一般只用于科学计算领域；如果Java的性能能够真正提高的话，它可以成为Fortran的替代者；至于C/C++，前者现在已经成了高级汇编，而后者也已经沦落为原始的OO语言。
在我看来，如果Java/C#能够解决对虚拟机的依赖和性能问题，他们完全可以成为C++/Fortran的替代者。
- 复 看需要了
家园 感觉上，需要自己管理资源的，还是需要用C 家园 Pascal也可以自己管理资源的 换Delphi吧。
- 复 看需要了
家园 又向老兵请教 如果Java/C#能够解决对虚拟机的依赖和性能问题，他们完全可以成为C++/Fortran的替代者理论上讲，单是为Java/C#搞个Native Code 的编译器，应该不是难事。但虚拟机有虚拟机的好处，这里不多谈，坏处嘛，就是性能总是差点的，现在的趋势，似乎总是从硬件方面推进性能表现。
问题是，有可能从软件方面大幅度提高虚拟机的性能吗?
- 复 又向老兵请教
家园 回复 首先，编程语言的面向目标程度和它可以编译成本机代码的程度成反比。也就是说，编程语言的面向目标程度越高，所需要的迟后联编也就越多，它可以编译成本机代码的部分也就越少。
这个现象的原因在于编译器/联结器需要确定两样东西，变量的类型和它所需要的空间大小，来分配空间，如果在编译/联结时这两样东西无法确定，就只好用迟后联编来在运行时间解决这个问题，否则程序就无法运行了。这里，迟后联编实际上就是某种解释执行。传统的编译器是不包括迟后联编的，现代的编译器实际上是传统的编译器加上了迟后联编部分。
现实的例子就是SmallTalk，它是如此之纯的面向目标语言以至于搞传统意义上的本机编译的意义已经不大了。将SmallTalk、Java、C#和C++（注意这个顺序）相比较，可以得出一些很有趣的结论来的。
上面的讨论说明了为Java/C#搞传统意义上的本机编译器的难易程度。可以说，用传统意义上的本机编译器来编译Java/C#是不可能的（否则多态就不好办了），现在所谓的Java/C#本机编译器本质上都是静态编译和迟后联编的某种组合，并且随着高级面向目标特性的增多，迟后联编的部分也要增多。
这个结论的一个推论就是，程序的运行性能和它的编程实现语言的面向目标程度是成反比的。该推论的一个现实例子就是Java程序的性能永远不可能赶上C++程序的性能，原因就是Java是比C++更纯的面向目标语言。
其次，讨论一下有无可能从软件方面大幅度提高虚拟机的性能。
只要程序是解释执行的，就必然存在一个中间码到机器码的转换过程。简单地讲，如果把一个程序的全部中间码都一次性转变为机器码后应该是可以消除二者之间的性能差异的（.Net提供了一个这样的工具ngen），但是代价则是可移植性的丧失。否则就只能够动态地将中间码变换为机器码，变换的次数越多，性能损失也就越大，改进办法就是所谓的生成的机器码高速缓存，利用大的机器码缓存来减少重复解释中间码的机会。
这里提高性能的关键是所谓的代码跟踪分析和由此而得到的动态优化所生成的机器码，使生成的机器码尽可能地简洁以至于可以充分利用机器的硬件缓存，这样理论上是有可能产生性能超过本机编译的代码的，但是它受限制于程序的类型和算法，而且要考虑代码跟踪分析和动态优化的开销。
就我个人而言，我觉得最好的解决方案就是微软的.Net的ngen，这样既提供了可移植性，又提供了在目标硬件平台确定的情况下一次性彻底将中间码转换为机器码的能力。
本帖一共被 2 帖 引用 (帖内工具实现) - 复 又向老兵请教
家园 看过一篇文章。作者称C#的性能一定会超过C/C++。 原因很简单，C#/VB.NET/Java这种语言是运行时动态优化的，C/C++是编译时静态优化的。动态优化的语言有更多关于程序执行特点的信息，可以根据程序执行的具体特点达到最佳优化。这些是编译时静态优化（Compile-time optimization）所达不到的。就内存管理而言，CLR/JVM也有特长，也还有很大潜力提升。假以时日，他们一定会超过C++的。
几年前我们在设计一个大型系统的时候，对采用哪种语言展开了大讨论。最后上Benchmark Program。对我们采用的核心算法分别用Java和C++实现。在一到两次计算的时候，C/C++有明显的优势。当一但测试达到一定数量（Hotspot start to kick in）,Java和C++的性能完全是肩并肩，个别测试上Java还胜出C++。由于我们设计的是服务器程序，所以一定数量的测试是符合我们运行特点的。
当然，我并不是说Java总体和C++一样快，在数据库操作,图形图像等方面上Java还很慢。但就数学运算而言，Java是足够快的。
本帖一共被 1 帖 引用 (帖内工具实现)家园 评论 在连续多次运行同样代码的情况下，现代的解释器的确可以达到本机编译器的效果，但是其前提就是“连续多次运行同样代码”，对于数据库和图形用户界面这样的应用来说，这个前提是不成立的，因为它们的工作集太大了。另外，数据库和图形用户界面应用涉及到很多JVM和本机系统的沟通问题，这里的开销很大。
Eclipse在图形用户界面应用方面作了一些改进，这样它的SWT/JFace要比Swing/JFC快。其实办法很简单：大量的本机代码。
- 复 看需要了
家园 据说Fortran 的算法程序久经考验 也有人将Fortran 程序改为C，说是速度没有Fortran 快。
况且人们已经习惯了，所以目前从事科学计算的还都在用Fortran。
家园 回复 呵呵，我不是做科学研究的，对Fortran没有多少项目级别的体会，因此不敢乱说。
不过我觉得Fortran目前能够依然在科学研究领域流行恐怕主要是因为很多老的算法库都是用Fortran写的，这样继续用Fortran写程序是比较方便的，否则以很多现代语言的描述能力，超过Fortran应该是不困难的。
至于将Fortran程序改写成C程序以后性能反而不行，我想主要是因为原有的Fortran程序是经过优化的，而对应的C程序缺乏优化的缘故。毕竟编译器的优化还是有限的，很多主要的优化依赖于编程人员的努力。
单从各种编程语言和汇编语言的接近程度来讲，C的级别要比Fortran更低一些，因此性能应该更好一些才对。
另外提一句，Matlab最初就是用Fortran写的。
