主题：【调查】大家都主要用什么写程序？ -- 还是不懂
想象一下，C语言加上面向目标特性，去掉指针，去掉一些高级特性，那是什么？那就是Java，Unix世界的Visual Basic，编程语言界的傻瓜机。
我在国内的时候客串过C语言培训老师，感觉学生最感困难的就是指针，其它的都很简单。
也许，Fortran在科学计算领域流行的另一个原因是大学的这些学科多数都要求学生学习该语言，因为老师就是用着Fortran长大的。先入为主，自然占便宜。
我同意Fortran的功能用C是可以实现的，但主要是Fortran这么多年了，能用Fortran的，大家也就懒得换成C了。就是说在科学计算中，C比较fortran的优势不明显，在熟悉fortran的情况下，大家也就懒得用C乐。
C正是具有指针的功能，才使得C远远优越于fortran。说来说去，真正编程的时候，有两种语言可以实现同一种功能，那我会选择相对来说实现起来容易的，自己比较熟悉的一个。
大学里用的C比较多，那时候对前后处理（图形图像功能比较感兴趣），后来搞research就基本上用Fortran乐，唯一原因想想就是fortran简单而且足够了，用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 帖 引用 (帖内工具实现)
首先，编程语言的面向目标程度和它可以编译成本机代码的程度成反比。也就是说，编程语言的面向目标程度越高，所需要的迟后联编也就越多，它可以编译成本机代码的部分也就越少。
这个现象的原因在于编译器/联结器需要确定两样东西，变量的类型和它所需要的空间大小，来分配空间，如果在编译/联结时这两样东西无法确定，就只好用迟后联编来在运行时间解决这个问题，否则程序就无法运行了。这里，迟后联编实际上就是某种解释执行。传统的编译器是不包括迟后联编的，现代的编译器实际上是传统的编译器加上了迟后联编部分。
现实的例子就是SmallTalk，它是如此之纯的面向目标语言以至于搞传统意义上的本机编译的意义已经不大了。将SmallTalk、Java、C#和C++（注意这个顺序）相比较，可以得出一些很有趣的结论来的。
上面的讨论说明了为Java/C#搞传统意义上的本机编译器的难易程度。可以说，用传统意义上的本机编译器来编译Java/C#是不可能的（否则多态就不好办了），现在所谓的Java/C#本机编译器本质上都是静态编译和迟后联编的某种组合，并且随着高级面向目标特性的增多，迟后联编的部分也要增多。
这个结论的一个推论就是，程序的运行性能和它的编程实现语言的面向目标程度是成反比的。该推论的一个现实例子就是Java程序的性能永远不可能赶上C++程序的性能，原因就是Java是比C++更纯的面向目标语言。
其次，讨论一下有无可能从软件方面大幅度提高虚拟机的性能。
只要程序是解释执行的，就必然存在一个中间码到机器码的转换过程。简单地讲，如果把一个程序的全部中间码都一次性转变为机器码后应该是可以消除二者之间的性能差异的（.Net提供了一个这样的工具ngen），但是代价则是可移植性的丧失。否则就只能够动态地将中间码变换为机器码，变换的次数越多，性能损失也就越大，改进办法就是所谓的生成的机器码高速缓存，利用大的机器码缓存来减少重复解释中间码的机会。
这里提高性能的关键是所谓的代码跟踪分析和由此而得到的动态优化所生成的机器码，使生成的机器码尽可能地简洁以至于可以充分利用机器的硬件缓存，这样理论上是有可能产生性能超过本机编译的代码的，但是它受限制于程序的类型和算法，而且要考虑代码跟踪分析和动态优化的开销。
就我个人而言，我觉得最好的解决方案就是微软的.Net的ngen，这样既提供了可移植性，又提供了在目标硬件平台确定的情况下一次性彻底将中间码转换为机器码的能力。
本帖一共被 2 帖 引用 (帖内工具实现)
换Delphi吧。
自己选学过编译原理的课，学过smalltalk，不过不是自己的专业，完全是课余爱好了，当时是云里雾里的，这次听老兵这么一讲解，回忆起了一点了
在连续多次运行同样代码的情况下，现代的解释器的确可以达到本机编译器的效果，但是其前提就是“连续多次运行同样代码”，对于数据库和图形用户界面这样的应用来说，这个前提是不成立的，因为它们的工作集太大了。另外，数据库和图形用户界面应用涉及到很多JVM和本机系统的沟通问题，这里的开销很大。
Eclipse在图形用户界面应用方面作了一些改进，这样它的SWT/JFace要比Swing/JFC快。其实办法很简单：大量的本机代码。
没想到在这里骗了一杯麦乳精。
有理论，有实践，解释的一清二楚。佩服得紧!
mpi_init
mpi_send
mpi_recieve
mpi_end
execl? give me a break.
welcome more gnu software.
realy good!!
1.如果你想告诉别人自己是黑客，就说不用别的，只用c和perl
2.如果做很大的分布式系统，告诉别人用J2EE/java，C#（.NET），什么三层架构之类的
3.如果做desktop程序，告诉别人用VC, VB, delphi或C#(一年后)
4.如果要写简单的网站，告诉别人用php和mysql
5.如果有人告诉你，为了开发跨平台的应用程序，用java，那就说他傻。