这个只作为参考

他们参考数据除了包含问卷外，搜索引擎是个重要的因素，而Google Trends的数据和他们的排名差不多。

C，C++，Fortran的Google Trends比较
http://www.google.com/trends?q=C%2CC%2B%2B%2CFortran&ctab=0&geo=all&date=all&sort=0

Windows，Mac，Linux的Google Trends比较
http://www.google.com/trends?q=Windows%2CMac%2CLinux&ctab=0&geo=all&date=all&sort=0

排名只作为参考，没有什么实际意义。数值计算这边也是C/C++/Fortran混合编程（甚至加上汇编）为多，没有什么绝对性的语言上的优劣，算法才是最重要的核心内容。

操作系统方面，搜索引擎出入就很大了，Windows本身就水分很大（含义太广），Linux有众多的领域，搜索时也不一定使用Linux（人家可能搜索bootloader啊、ubuntu、fedora之类的），Mac呢，包含的太多，什么IOS、Iphone、Ipad开发必然牵扯到Mac OS（此开发近几年相当热），此消彼长，Mac暂时在搜索引擎上据第二也不足为奇了。

勋哥, fortran其实还有什么优势呢? 现在好像lapack这种出生就为fortran编写的函数库都已经加上C接口了.

[quote]勋哥, fortran其实还有什么优势呢? 现在好像lapack这种出生就为fortran编写的函数库都已经加上C接口了.[/quote]
对于熟练程序员来说，优势只在源码本身的高效性和本身默认传址，这是因为Fortran相对于其他语言来说，语法还较为严格，这样有利于编译器把重点放在目标代码的优化上（尤其表现在循环和四则运算上）。
对于一般程序员来说，Fortran遗留下来的大量代码是一个宝贵的财富，当然并不排除有人会将这些代码重写。
lapack只是加了C的接口，他的原生代码导出还是Fortran的，使用C的接口时，也得链接Fortran的底层库。不过lapack的各种优化库都不是Fortran写的，上面已经说过了，只考虑相同的原生源代码算法，Fortran编译器一般来说要优化的更好一些，而要进一步优化的话，必须采用特殊的CPU或GPU指令，而这些Fortran并无优势。因此，Fortran未来如果加入直接使用SIMD指令还是很有前途的，此外，gcc未来可能也会引入OpenCL标准，不知道gfortran会不会也可以原生使用。当然，这些东西现在的Fortran编译器只要支持ISO_C_BINDING模块都可以自行封装后使用，可能对个人的混合编程水平要求较高，但也远远没有直接使用C/C++来的方便。
很期待Fortran标准直接加入内嵌汇编/SIMD指令/OpenCL。

今年3月份時去參加了Intel的高性能大會。有點感觸吧，正好借這個機會跟大家分享一下。
Intel出了一個傳說中叫做Cilk Plus的東東，算是C/C++的擴充吧。
它有如下特性：
Cilk/Cilk++特性
ABB
而這東西的誕生個人估計是想用HPC（高性能C）代替HPF（高性能Fortran）
Cilk包括了并行的特性，使用的并行技術在類似于多重循環或是其他特殊的地方，會更優于OpenMP模型；
而ABB則根本就是一個FORTRAN數組處理的一個翻本！它讓C數組也可以整體處理了！而FORTRAN原本的優勢也正在此（可以方便地讓編譯器自動生成SIMD指令！）

如果Cilk Plus成熟并成為高性能C的實際標準，那無疑對Fortran是一個致命地打擊！

當然，短期內Intel還是會讓Fortran好好地活著的！但一旦Cilk Plus風行，那……我們可愛的Fortran可能就真的要面臨進入墳墓的OOXX了：）

Cilk这个技术早就有了，原来有个CilkArts在gcc基础上搞了个编译器的，也是开源的，所以现在GSoC（Google Summer of Code）有的人想用Cilk技术对gcc的OpenMP进行改进。其中也是直接修改了gcc的前处理，如果修改了gcc/g++的前处理的话，那么gfortran的前处理也比较容易实现，所以技术上不存在什么难题。
问题是intel的Cilk语法和原来的Cilk语法兼容否，gcc会不会搞Cilk的分支？（gcc有个UPC的分支，详见http://gcc.gnu.org/projects/gupc.html，也是针对的并行计算，有兴趣的人也可以自行编译下）
intel现在都是想方设法的兼容gcc的（包含gcc自身的语法扩展），intel自身的东西说不准是否向gcc方面推介（像Google把gold链接器赠与了gnu项目）
总之，这些模型归根到底都是技术使然，哪种取得主流还待时日（OpenMP本来就是在Fortran里弄的，后来不也向C/C++了么）。
说起这次GSoC，很多人都在意向修改gcc的OpenMP，gcc的OpenMP代码毕竟几年都没修改了（至今还是依赖可恶的pthreads），还真说不定这次会有人重构OpenMP取得可喜的成果。

ps：我可耻的希望所有的人都不使用intel编译器，这样intel搞不下去了就给开源了^_^

我被可耻了, 哈哈哈.
勋哥, lapack3.30之后加了个重要的性质就是C接口, 我只是看它的帖子觉得保持了高性能. 理解是做了一些底层的工作.
http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=2068&sid=f9a289644e6ebb290327056e3ad33dbc
fortran便于编译器优化这个确实是方便了程序员. 但是深层次的总是觉得有些无力. 
Cilk++ 以前在intel论坛逛的时候看到过一下, 一直不知道是什么东西, 听cgl_lgs这么一说似乎会是一个不错的发展方向.

[quote]我被可耻了, 哈哈哈.
勋哥, lapack3.30之后加了个重要的性质就是C接口, 我只是看它的帖子觉得保持了高性能. 理解是做了一些底层的工作.
http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=2068&sid=f9a289644e6ebb290327056e3ad33dbc
[/quote]
你说的这个叫lapacke，我看了下源码，提供了完善的C/C++接口（需要在编译时指定），底层上你随便链接高性能lapack和blas库（比如atlas、gotoblas、mkl）。
[quote]Cilk++ 以前在intel论坛逛的时候看到过一下, 一直不知道是什么东西, 听cgl_lgs这么一说似乎会是一个不错的发展方向.
[/quote]
可能也许或者吧……
如果gcc对此有兴趣，肯定会有很大的发展前途，也有利于实现标准化。不过我感觉还是把思想集成进OpenMP比较好，虽然Cilk对语法做了微小的改动，也不见的会有很多人用。就像OpenMP一样，虽然发展很多年了，很多人还是直接使用api直接操作线程，放弃不了传统维护的代码。

在工作单位

办公室的同事都是用VBA

我也感觉我是大熊猫

喔也，需要解释一下：
Cilk和Cilk++是开源的，但Cilk Plus(注意只有一个Plus,而不是Plus Plus)是Intel独有的，它包括了Cilk和ABB(Array Build Block)，也就是整数组处理。如果程序对整数组处理比较多（比如图像处理）那将会有非常大的效果：）

至于大家不用就开源。。。可能不会~~~~~

比如Novel Netware，在它临死前及死后一样是没有开源的~~~~
可惜了这么好的一个系统~~~~

[quote]喔也，需要解释一下：
Cilk和Cilk++是开源的，但Cilk Plus(注意只有一个Plus,而不是Plus Plus)是Intel独有的，它包括了Cilk和ABB(Array Build Block)，也就是整数组处理。如果程序对整数组处理比较多（比如图像处理）那将会有非常大的效果：）
[/quote]
感觉换汤不换药啊，实际上还是指针

[quote]
至于大家不用就开源。。。可能不会~~~~~

比如Novel Netware，在它临死前及死后一样是没有开源的~~~~
可惜了这么好的一个系统~~~~[/quote]
因为那个时候还没什么开源（开源始于98-99年），现在趋势是搞不下去或者想挤垮竞争对手就开源
ps：你Novell写错了