Fortran 还有存在的必要吗？
其实这是个很私人的问题，完全看你自己需要不需要了。小明手头有一个发展了十年，十几万行的fortran程序。心里琢磨看是不是需要推倒重来呢？小明实在是对fortran看不上眼，决定开启一段伟大的旅程：发展一个全新的C++程序，估计最终规模有十几万行。看看是不是需要把什么oo，design pattern，xml，boost，python封装，traits都用上，规划几十个namespace，几百上千个类，继承个五六七八层……？是不是显得很有big？ 鄙视FORTRAN和推崇C++的人往往喜欢把OO挂在嘴上。但是把复杂系统OO化看来是过于理想主义了。犹如“过早优化是sb”一样，“过早设计也是sb”。但是不断的迭代OO设计会陷入不断的建模-重构-重构-重构，最后疯掉或者从屎山中挣脱出来。复杂的OO设计和goto泛滥同样都是灾难。后来者面对堆积如山的class和复杂的耦合关系，迟早会彻底失去探索的勇气，然后只会流于表层。最后，我们会发现“我TNND把精力都耗费在设计上了，成天折腾这些类之间应该怎么耦合关联交互，而没有精力去研究算法、提高性能和思考物理问题”。 补充： 其实，我并非是死硬fortran用户。我的意思只是说fortran有它自己的用武之地，C++和现代动态语言的fans们没必要狂喷fortran。我其实同时使用fortran与C/C++。不要迷信OO，更不要过度的OO。OO只是一种设计哲学。可是软件设计并非只需要一种哲学。复杂系统OO化是很难的，当你把它分解为许多比较单纯的子系统之后，你会发现某些单纯子系统可能没必要OO。 相反，经过好几年的折腾，我自己发现，在数值计算中，数据和操作分离的设计（有点像函数式编程咯）是值得关注的。 （撇脚的）面向对象设计者往往会： 尽管可以通过精心的分析与设计来避免或者减轻这些问题。但是这纯粹是没事找事。为什么不按照数学公式原有的模样来写呢？这样不就没有这些问题了？比如函数R(\rho,u,v,w,p,s_x,s_y,s_z,vol,\mu,\mu_T)，就编写为 它只是根据参数计算出结果outRes，不会对outRes之外的任何变量进行修改，也不管这些参数从哪里来。很显然，在函数参数较多的情况下，这个做法被很多C++的fans所嫌弃。但是这种方式的价值就在于，它单纯的表现了函数的输入与输出关系，没有不必要的绑定，没有状态记忆，没有高阶对象（只有基本的数组）。 一旦按照这样老土方式设计，函数的重用就简单了。很多基础数学库，就采用了很老土的设计。我琢磨设计者也考虑到在底层不能引入太多的复杂概念，抬高上层应用开发不必要的成本。 但是在更上层，对于合适的情况，可以考虑其它设计思维。 所以，我说的是，设计方式要因地制宜，抱着一种思维不放，那是自找麻烦。迷信OO放之四海而皆准，那是痴人说梦。