主题：庆祝Python跃居世界第四程序语言 -- 空格
听些PyCon的视频，包括Guido自己说的，拍桑和拍森的发音都有了。
目前实际应用如果需要较多第三方模块，还是Python 2.x较为成熟。
不过支持Python 3的也开始一步一步多起来了，过去一年，科学计算方面的库进展比较大。
有些程序员还是喜欢单一编程语言。
一口气看完了所有的回帖，做为一个天天跟汇编，C/C++较劲，并且只用过PHP的程序员，我也谈点感想。感想挺多，统一回复在楼主贴下面，希望楼主不要介意。
我觉得，任何一种语言都有自己的特性，语言之间没什么可比性。飞机快，也没取代汽车；汽车快也没取代自行车。一个语言的出现，实际上是语言作者为了满足某种需求而开发，经过社区的力量，或商业推广发展壮大。
C++确实是个有争议的语言，从它出现的那天起就没消停过，C和C++争论过，java和C++也争论过。
脚本语言的优势是易于学习，易于使用，抱着本书一个星期就可以进项目开发，支持库也多，开发人员只需要把精力放到功能逻辑的实现，其他的就交给支持库来完成即可。程序搞定之后，想放哪个平台上就放哪个平台上，只要解析器、虚拟机支持，可以让写好的程序跑在咖啡机里。
如果是从事系统级别的开发，想用脚本语言实现点功能是门都没有；但是搞WEB应用，死抱着C/C++来干，那真是有点拙死。处理一个HTTP请求的数据包就够喝一壶。
有人说C++的语法功能太搓了，用起来很别扭，学起来太费劲，但是我感觉实际情况是，任何一种语言，要完全掌握语言特性，基本都需要一年的学习实践时间，C++和PHP相比，C++的入门难度大，PHP入门简单一些罢了。C++的难度体现在它的灵活，而真正的大师，正是那些能灵活运用语言特性写出一些让人无法理解，但是在跟踪调试之后令人感觉到心旷神怡的代码的人。
所以说，就按照需求选择语言，大型的跨平台应用，可以用java，python。别跟某某语言过不去，语言是死的，人是活的。如果项目非要用C/C++写跨平台的代码，那就努力写出高质量的代码，要么就把ISO的人给做了。至少ISO的人不是什么白痴，最恨他们的应该是编译器的作者。
再说说OOP的事情，我感觉这就是个思想性的东西，和语言无关，语言支持不支持并不重要，有这个思想，面向过程的语言一样可以按照OOP的思想来实现产品，Windows内核就是很经典的例子。即使不使用OOP照样也可以实现功能，和这个那个思想比起来，优秀的框架设计，良好的代码风格和充分的注释，以及功能实现的设计文档才是最重要的。说句良心话，一个版本的实现，时间花费最大的地方是调试和测试。
语言就是语言，现在的应用是越来越庞大，无论C++还是PHP，实现一个应用代码量基本差不多，西西河这样一套系统，至少也得有个10万行以上的代码量。就功能而言，语言对功能影响是比较小的，分配内存，释放内存能占多少行代码？那就是一个细心的问题，对于一个习惯使用C/C++的程序员来说，绝对不会认为这是一个诟病。
我觉得专注事务处理应该是语言发展的趋势，比如在企业应用整合和大型ERP系统中，事务过程处理的语言是脚本语言所无法比拟的。当然，效率也是要考虑的，不能因为硬件发展了，效率就忽略了。
脚本语言的一个问题是版本混乱，一开始是一个样子，之后添加特性过多，反而没了特点。版本间功能不兼容，特性不支持，对于生产环境来说，稳定才是最重要的，不到万不得已不会随随便便更新生产环境的配置。至少C++还能用个extern "C"保证编译后函数命名的统一，脚本语言用什么保证向下的兼容性统一呢？
安全是脚本语言面临的另外一个问题，看看各种脚本语言发布的release，都会有安全缺陷的修正，对于稳定第一的生产环境来说，某些安全缺陷可以是致命的。另外一方面，脚本语言基本是源码，即便是那种可以生成二进制中间码的也都很容易被逆向出源代码，保护源代码就是一个问题。C/C++这样的程序，很容易保护，有各种各样的加密加壳程序，相对于脚本语言，逆向起来没有点技术水平是比较困难。
啥事都有好坏两方面，就看个人选择了，喜欢一门语言就跟恋爱一样。和版本功能实现，代码维护管理相比而言，语言之间的比较真就是浮云。。。
甚至是枷锁，是浪费时间。
比如说关于源码保护的问题，作为用户来说，真的有些不以为然。从程序员的角度看，也许源代码对他很重要。但是作为用户，最重要的是可以方便的了解程序正在做哪些事。说实话，有文档，我当然看文档。但是，光看文档是不行的。当一个程序漏洞百出，文档缺乏，偏偏又没有源码，只能当黑箱来分析的时候。我真的是杀人的心都会有的。大多数时候，我觉得源码就是最好的文档。只要提供源码，哪怕没有文档我也会宽心一些。所以让我选择的话，我肯定是会选对我开放源码的程序。
说实话，如果我花时间写了一大段代码，结果谁也不看，只知道拿去用，那我肯定是不高兴的。好吧，我承认我没有牛逼到别人追着看我的代码的程度。
另一方面，还是对于我来说，效率绝大多数时候不是问题。我就看到有些程序员对于使用纯文本的数据库感到不可思议，认为效率低下。但我却觉得，花费时间给这些东西做优化才是真的不可思议。除非极为必要，否则，我宁愿牺牲cpu和内存，也不愿使用什么数据库来增加业务中的维护环节。脚本语言一开始就是给系统管理员使用的，事实上他们才是真正在第一线的生产环境干活的。绝大多数脚本程序都可以非常好的适应它们的应用。
关于脚本语言的兼容性问题。现在python 3.x正在开发中，python主要的库正在由2.x向3.x迁移。有兴趣的话可以跟踪一下。而最传统的shell脚本，基本上都是依靠作者的自律来保证脚本的兼容性的。现在也有dash这样，强迫用户考虑兼容性的脚本。就像你说的最重要的问题永远是程序的作者。绝大多数脚本，也许历史悠久，但解释器实现都是上乘之作，无论是在windows上还是在AIX上，都工作的很好。
至于oop的问题，确实与语言无关，比如说gobject就是C的OOP框架。说实话，如果使用oop的话也许gobject比学习C++要来的顺手的多。
每种存在确实都是有理由的，但是有些理由，对一部分人重要，对另一部分来说就完全两样了。大多数人本来只需要学习脚本语言就够的，却由于浮躁的商业宣传、僵化的教育体制，而学了一大堆对自己用不上的东西。就算是骂娘也是很自然的。
但是总得来说，我觉得脚本语言是大势所趋。成为绝大多数不过是个时间问题。这不是说什么汇编/C/C++不重要了，我现在还在用Fortran呢。一门语言有一门语言的用武之地脚本语言就是那种可以让所有人都可以编程的语言。关键是让每个人都知道他合适哪种语言，而不是争论哪种语言好在哪里。
不过,
PYTHON 和 PERL (以及SLANG) 是可以比的.
FORTRAN和C 是可以比的
Ｃ 和 C++ 是可以比的
去年开始，给公司开发一套自动测试的framework，当时由我自己决定选择哪种语言。
本来在python和ruby之间选一个。我决定选择python，虽然之前没有用过。但是一年用了下来，确实比较顺手。
我凌乱了，凌乱了。。。
真没想到
。。。。。
overload,还不如说是因为隐形的类型转换（Implicit conversion），即int被允许自由的转换成float。如果不允许int隐形转为float，你如果想调用void foo(float)，只能写成foo(1.0)或者foo(static_cast<float>(1))。而如果code里写成foo(1)，读你的code的人必然意思到还有一个函数void foo(int)存在。这个隐形的类型转换是C的几个最被人指责的缺点之一。C++中为了和C兼容而不得不支持。在具体的工程开发中，比如我所在的公司，禁止使用隐形的类型转换。
运算符overload最重要的应用是在generic programming。可以说如果不支持运算符overload，你不可能实现generic programming。
在overload上，你反对灵活，不允许任意overload，希望有更加严格的控制，比如支持显示的overload表达。在泛型上，你则完全相反，讨厌现行的严格准确的声明范型的方法，而希望引入更灵活的宏来声明范型。这里你又看重简介高效了，而不去考虑由此带来的各种问题，比如可读性差，编译困难等。所以，关键问题是你到底希望C++是一种什么样的语言？
f(0){return 1;}
f(n){return n*f(n-1);}
但必须引入template.
因为C++是一种强类型语言，重载一般是指1）参数的个数不同或者2）参数的类型不同.
此例如果0与n类型一样，不满足的以上重载适用的条件。 但是1）引入模板可以使得整数(integral)可以变成类型（type），2)对圆括号（）运算符重载可以使类(class)变成函数。
所以可以这样：
template<int n> struct f
{
size_t operator()()
{
return f<n-1>()*n；
}
};
template<> struct f<0>
{
size_t operator()()
{
return 1；
}
};
这么使用：
assert(f<0>() == 1);
assert(f<1>() == 1);
assert(f<2>() == 2);
assert(f<3>() == 6);
虽然形式上有点差异（有尖括号，而且参数在尖括号里），但思想本质上是一致的：即根据数值而不是类型重载，不知这是不是你想要的效果。