现在越来越多的人开始承认动态语言在开发效能方面的优势，但是应该说这还只是停留在人的感觉上，缺乏客观、量化的证据。当然，真正要做到客观的比较是不可能的。一个团队开发一个具有一定规模的软件项目，这是一个复杂的过程，牵扯到的各方面因素很多，不可能做到完全客观、仅仅针对开发语言本身效能的比较。但是，为数庞大的开源软件项目当中，挑出一些使用不同语言开发的目标相同的项目，并且对其开发效能做一个比较，这是可能的。尽管这种比较未见得公允，但是仍然具有一定参考价值。

我看到的一个比较有意义的比较是在C、Java和Python三种语言之间进行的，目标都是开发符合SSH服务端协议的软件包。这是一个具有相当技术性且有一定规模的任务，由各语言的专家级开发者完成，因此具有可比性。相关数据如下（截至2003年）：

C语言：OpenSSH，直接基于Unix系统服务，从1999年开始开发，4年之后共有64,000行C源代码。2003年时，开发者列表上共有84人。平均每人写了762行代码，也就是190.5行/人年。

Java语言：J2SSE，基于Java 1.3 Standard版提供的API，从2002年初开始开发，由SUN官方支持，2003年拥有20,000行Java源代码，开发者7人，平均每人2857行代码，1428.5行/人年。

Python语言：Conch，基于Twisted Framework，项目起点时间不详，大致为2002年中，到2003年共有5,000行源代码，开发者1人，约4000-5000行/人年。

这个数据可以给大家评估动态语言的效能做一点参考。需要注意的是:

1. C语言版的OpenSSH本身就带有探索性质，所以开发周期较长。
2. OpenSSH开发者虽然多达84人，但是一般来说开源项目中起核心作用的开发者一般在6-8人左右，很可能这几个人贡献了大部分代码，因此上面对C语言开发效能的评估严重偏低。
3. Conch本身架构在Twisted之上，后者是一个高层的网络开发框架，本身也是具有6万行代码规模的项目。Conch的高效能很大程度上受惠于此。
4. J2SSE是Sun官方开发的项目，其开发方式不同于开源松散的开发方法，因此上述得到的开发效能可能被高估。

综合以上的考虑，我认为从这个case study中得出三种语言开发效能的比大致在1:4:10的估计值。

附带一提，据Twisted文档宣称，Conch的运行时性能并不逊色于OpenSSH。在同一台计算机上，OpenSSH每秒钟可接纳3个连接，传输速度7.4MB/s。而纯Python实现的Conch每秒钟可接纳8个连接，传输速度3MB/s。经过Psyco编译优化后，每秒钟可接纳11个连接，传输速度8.1MB/s。

请注意，这是2003年的数据。

本文主要素材来源与Twisted创造者Glyph Lefkowitz发表在USENIX 2003会议上的论文，题为《Network Programming for the Rest of Us》，并在此基础上进行了一些历史资料调查。关于开发年限的调查可能有误，希望得到有识之士的纠正。

评论

#   hefei2 发表于2006-08-07 21:33:00  IP: 222.172.138.*

#   myan 发表于2006-08-07 22:35:00  IP: 219.236.52.*

to hefei2: 好几个朋友看了这篇blog，对于开发效能都不是很在意，反而是对于最后这个运行时性能的比较非常感兴趣。然而我的看法是，不要过于看重这个评测结果。 首先，这是Twisted自己的文档，尽管我相信评测者不会故意伪造试验条件贬低OpenSSH，但是没有尽心优化，却是非常可能的。 其次，经Psyco编译之后，Conch实际上是一个native code program。你说“解释型语言不大可能超过编译型语言”，但这里是两个机器码程序之间的比较。 第三，请注意当你用C语言写一个高层应用程序的时候，你的思路不得不在高级设计和底层细节之间不断跳越，很难把握好，形成真正优化的设计。而你做的很多事情是在重复Python等高级语言已经内建并且经过极度优化的工作，用Python写代码，可以集中力量思考高级设计问题，所以比较容易形成良好的设计。很早有人就发现，用C语言进行正则表达式分析还不如Perl快，这并不是语言本身的比较，而是当开发者能力相当时，采用高级语言能够比较容易地得到优化的整体设计。 第四，我相信，如果设计上水平相当，C肯定跑得比Python快十倍。问题在于，一旦程序规模达到一定程度，完成一个与对应Python程序在设计上水平相当的C程序，所付出的代价恐怕要多出几十倍。

#   tonny1982 发表于2006-08-07 23:44:00  IP: 61.135.146.*

开发效率和运行效率是一个很难来平衡的事情 关键是要看你的需求,如果你要做一个压力特别的忘了服务的话,我相信C是一个比较好的选择,当然如果你的项目马上要上线,而且刚刚开始那种压力不会一下子变的很大,ok,Python PHP...但是你要随时准备好重新用C重写你的核心代码 注意是核心,不一定是全部,曾经看到这样一句话觉得很有道理: 80%的瓶颈出现在20%的代码,那么你只要重写这20%就Ok了,当然这要得益于动态语言很好的粘性,Python和PHP都具备这种能力 另外我对文章中的几个数据比较不以为然,这些东西跟象是广告 再从另外一个角度将OpenSSH运行效率不要只能怪代码烂(只是一种假设:P)

#   TripleX 发表于2006-08-08 01:00:00  IP: 222.128.6.*

#   TripleX 发表于2006-08-08 01:04:00  IP: 222.128.6.*

看了一下 Conch用的加密库不是OpenSSL的libcrypto 是自己带的 我的debian系统上有如下动态库 /usr/lib/python2.4 /usr/lib/python2.4/site-packages /usr/lib/python2.4/site-packages/Crypto /usr/lib/python2.4/site-packages/Crypto/Hash /usr/lib/python2.4/site-packages/Crypto/Hash/MD2.so /usr/lib/python2.4/site-packages/Crypto/Hash/MD4.so /usr/lib/python2.4/site-packages/Crypto/Hash/SHA256.so /usr/lib/python2.4/site-packages/Crypto/Cipher /usr/lib/python2.4/site-packages/Crypto/Cipher/Blowfish.so /usr/lib/python2.4/site-packages/Crypto/Cipher/XOR.so /usr/lib/python2.4/site-packages/Crypto/Cipher/ARC2.so /usr/lib/python2.4/site-packages/Crypto/Cipher/ARC4.so /usr/lib/python2.4/site-packages/Crypto/Cipher/CAST.so /usr/lib/python2.4/site-packages/Crypto/Cipher/DES3.so /usr/lib/python2.4/site-packages/Crypto/Cipher/AES.so /usr/lib/python2.4/site-packages/Crypto/Cipher/DES.so /usr/lib/python2.4/site-packages/Crypto/PublicKey /usr/lib/python2.4/site-packages/Crypto/PublicKey/_fastmath.so 速度肯定都从这些库里来 看来这些库写得比OpenSSL要稍快一些

#   TripleX 发表于2006-08-08 01:05:00  IP: 222.128.6.*

什么时候有空单独写一些程序 对比python-crypto和openssl libcrypto的速度 估计原因就出来了

#   redsea 发表于2006-08-08 01:30:00  IP: 219.137.203.*

不管怎么说, python 拥有很多良好的资源, 一些cpu 消耗大的计算也有 .so 的代码, 写很多程序都不觉得慢. 我们现在就是用 C++/C + python. 上次一个朋友想开发web, 想快速开发, 又想以后万一规模大了的时候, 也能够支持得住. 我建议他目前用python 的 turbogears 框架(当然数据库部分不能选sqlobject , 必须用sqlalchemy), 以后万一规模上来了, 那么能够静态化的网页就静态化,无法静态化的少数网页, 用c写lighttpd 的plugin就好; form 提交处理继续用写好的代码即可, 这部分不是主要消耗, 即使负荷不起,用linux virtual server 均衡到几台机器上也很简单, 不会多很多机器. 这样, 框架简单(比起java 的方案), 开发快, 以后也有提升空间.

#   TripleX 发表于2006-08-08 01:48:00  IP: 222.128.6.*

其实python写很多程序都不慢 呵呵 按照代码一行一行比 python当然比c慢 但是很多情况下 这些都只是包子的褶 肉都不在这个上 :-)

#   myan 发表于2006-08-08 07:32:00  IP: 219.236.52.*

to TripleX: 非常感谢。 请注意是OpenSSH，不是OpenSSL。

#   TripleX 发表于2006-08-08 00:53:00  IP: 222.128.6.*

其实这个事情特别简单 因为ssh的速度限制主要在加密/解密的部分 而那部分一般都是用汇编写的(c库) 如果测试出来速度有明显差别 那么表明其余部分的代码速度和加密一样慢 我的天 那得慢多少个数量级阿..... 想起来以前有一个公司把quakeII用java重写了 发现速度和c的版本差不多 我下载了一个回来试 在我的机器上c的版本快了不少 !! 看了一下测试机器的配置 发现他们用2G的AMD cpu配TNT M64显卡 瓶颈在显卡上~~ 而我的机器显卡是Radeon7200 cpu却只有800MHz CPU是瓶颈 所以速度差别就显现出来了 用OpenGL的Performance工具看也看到了差别 用c写的版本有50%的时间是处理器在等显卡 而java的版本只有20%多一点的时间是处理器等待显卡 很明显c的版本差不多要快一倍 :-)

#   myan 发表于2006-08-08 07:48:00  IP: 219.236.52.*

to redsea: 介绍一下你自己的Python体验嘛 :-) Python在动态语言里并不是以快闻名的，其实它的设计思想主要是追求高层次上的简单优雅，在性能上不仅不是最快的，而且很多年以来一直有“最慢”的恶名。可是放在实践中感觉完全不是那么一回事，大家觉得开发效率和运行效率都令人满意。我想主要原因就是Python的资源丰富而且质量很高，当性能遇到瓶颈的时候，有人会去开发extension。这样一来就形成了良好的平衡。 在这方面我自己是有体验的，在简单的小规模问题上，我可以轻易用C/C++写出效率8-10倍于Python的程序，所花费的开发时间大致也是8 -10倍。但是程序规模一大，两方面的比率都会发生非常不利于C/C++的变化：运行效率优势降低，而开发时间比开始恶性膨胀。尤其是在没有基础库的支持下用C写程序时，如果代码质量要求比较高，那么开发效率是非常低的。

#   TripleX 发表于2006-08-08 09:49:00  IP: 222.128.6.*

To myan: OpenSSH用的libcrypto就是OpenSSL项目提供的libcrypto加密库 #ldd /usr/sbin/sshd linux-gate.so.1 => (0xffffe000) libwrap.so.0 => /lib/libwrap.so.0 (0xa7fc1000) libpam.so.0 => /lib/libpam.so.0 (0xa7fb9000) libdl.so.2 => /lib/tls/libdl.so.2 (0xa7fb4000) libresolv.so.2 => /lib/tls/libresolv.so.2 (0xa7fa1000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xa7e67000)

#   TripleX 发表于2006-08-08 10:53:00  IP: 222.128.6.*

#   analyst 发表于2006-08-08 12:28:00  IP: 222.70.126.*

这样的比较是不公平的，前面也说了，Conch本身架构在Twisted之上，Twisted本身也是具有6万行代码规模的项目。开发一个Twisted需要多少人年呢？而OpenSSH是直接基于Unix系统服务开始构建的。 做成熟应用，python有很多成熟的库可以用，开发效率当然要比从头构建要快的多。但是如果做新的应用，没有成熟的库可以用，你免不了还得用C写extension，写extension的时候还得考虑更多的通用性，性能之类的问题，这样的开发效率跟直接用C差不了多少。

#   ywchen2000 发表于2006-08-08 12:38:00  IP: 218.107.29.*

myan 我现在就是在用C++从写PYTHON写代码，抓狂中

#   redsea 发表于2006-08-08 13:05:00  IP: 218.19.157.*

我用python 的体验? 应该没有什么特别的吧. 1. 用python 的时候, 感觉是花在 语言,库使用方面的时间大大降低, 主要的时间花在问题域上了. 这一方面应该是python语言本身比C/C++ 之类的就更简单, 各种基本支撑措施都齐全易学(log, serialization, rpc, db,regex 等等) 且跨平台, 很少需要费心在这些方面 -- 不像C/C++, 如果在某个领域没有积累, 可能需要自己写上不少底层支撑代码, 跨平台代码之类的, 换个项目这些方面的选择变了, 又要重新学; pythonic 原则设计的各种库很齐全,使用也很容易. 另一方面, 选择了python 做开发的时候, 也就更有了自觉, 优化是整体设计级别, 语句级别没有太多搞头. 2. 编写, 调试循环快 python 写同样的东西, 语句比c 少, 没有编译时间; 由于是解释型的, 一些功能较独立的函数直接可以在解释器里面测试是否工作正常. 这些特点造成编写, 调试周期短. 3. 字符串操作轻松 编程工作里面, 有很多的时候要进行字符串操作, 这些方面, 脚本语言都易用而且效率不差. 例如 python % 算符的键值替换方法, 用来构造 sql 的时候, 写起来方便不容易错, 读起来也直观 -- 如果python 字节码编译器不笨的话, 编译结果的运行效率也应该比printf 高. 说到C++, 多扯几句. C++ STL 库, 强大但丑陋, 写出来就是不准备让人看的, 读这些代码吃力不讨好, 和著名的只读语言forth, 难读语言perl 也没有什么区别, 不但初学者无法从中学习编程, 我这种已经入门了的人也很难读. 当初读iostream, 想看看其中某个特性做得如何的时候 -- 心里怨恨, 不知道 STL 算不算 lib 开发者友好, 但肯定是lib 使用者不友好.

#   charon 发表于2006-08-08 11:58:00  IP: 210.52.78.*

/*很早有人就发现，用C语言进行正则表达式分析还不如Perl快，这并不是语言本身的比较，而是当开发者能力相当时，采用高级语言能够比较容易地得到优化的整体设计。 */ 严重同意！！！

#   redsea 发表于2006-08-08 16:03:00  IP: 124.248.72.*

to analyst >这样的比较是不公平的，前面也说了 我没有觉得这种比较有什么不公平, 语言之间的比较当然不应该只是比较语言本身, 还应该加上该语言中成熟的库一齐比较. 如果 Java 和 C++ 一样, 标准库那么少, 还会那么受欢迎吗 ? twisted 是一个成熟的库, 作为python 的一个基本装备并无不可. C++ 网络方面也有不少的库, 例如 ACE, 但是种种原因, 开发人员进行开发的时候 不一定选择这些库. 这可能是和具体应用场合有关的业务领域相关问题, 也可能是和 C++, 目标库特点的技术选择问题. 如果属于后者, 是属于语言/库的缺点造成的.

#   Gawain 发表于2006-08-08 18:29:00  IP: 10.218.12.*

这样的方法对C很是不公，这样的话是不是可以搭上AppleScript. 因为在C中的实现只要一行或数行便可以完成AppleScript或python在2倍或3倍以上的代码量。

#   analyst 发表于2006-08-08 19:03:00  IP: 222.70.125.*

争论公平不公平到也是没什么意义，我一向主张实用主义，哪个好用就用哪个。我只是对1:4:10这样的数据颇不以为然，因为没有什么代表性。 另外redsea 对 C++ STL 的认识与事实恰恰相反，STL 是用起来简单实现起来难，没有哪个人用STL的时候还要去读STL源代码的，除非是以研究为目的。

#   redsea 发表于2006-08-08 20:21:00  IP: 218.19.157.*

to analyst: 既然用到 C++, 我就会对性能和内存占用考虑得比较多, 否则我就不会用C++了, 我会用python 或者 delphi, 我并不是 C++ 狂热者 --- 其实我不是编程爱好者, 能够不写代码, 我是不想写的, 能够不研究某些技术, 我是不想研究的. 要关注性能和内存占用, 需要准备怎样的 allocator 给它才能长久运行不会产生内存碎片, 等等, 我就只好阅读源代码了. 举个例子, STL list 的实现, 如果我用来放一个指针, 以便避免昂贵的对象构造和复制, 那么我当然要知道它内部是每个entry 都申请一次内存, 还是更聪明, 内部申请大块自己管理. 如果它每次都申请, 我用heap 方式的allocator 就会有很大的代价 -- heap 管理的overhead, alignment(现在缺省8byte) 的overhead, 使得每个指针最后耗费的内存可能是很多倍, 而且申请到的内存在空间中也不连续.

#   狗见愁 发表于2006-08-08 22:02:00  IP: 222.90.74.*

C++给了人造轮子的可能，就有人非要舍弃现有的轮子不用，去重新发明轮子，然后说C++如何如何麻烦； C++就像是最好的登山装备，最好的登山者唯一的选择，但最好的登山者想要征服的也是最危险的山峰。

#   shhgs 发表于2006-08-09 07:12:00  IP: 70.27.117.*

十年 发表于2006-08-08 22:23:00 IP: 218.18.19.* 我自己认为Python的运行效率高是与C语言分不开的。要知道Python的很多库都是用C写的，然后套上Python的解释器执行罢了。所以说他们之间的比较确实没有多大意义。比去比来，结果是比较“高手的C代码”与“低手的C代码”之间的比较。毕竟Python的C代码是经过实践考验的，值得信赖，但一般的C程序员不一定写出那么高的C代码。 严重同意！！

#   analyst 发表于2006-08-08 22:22:00  IP: 211.161.210.*

呵呵，你这就钻牛角尖了，至少我写这么多年C++从来没有自定义过allocator。STL原本已经有不错的效率，我为什么还要去担心这个？难道你写python的时候会对效率提心吊胆吗？一个成熟的开发者是不会去盲目优化程序的，更不会刻意的玩弄技巧。当然反过来说，万一如果某个STL容器确实构成了性能瓶颈，那我干吗还要在STL里面死磕呢？自己实现一个简单的容器不就得了，自己写的最有把握。

#   十年 发表于2006-08-08 22:23:00  IP: 218.18.19.*

我自己认为Python的运行效率高是与C语言分不开的。要知道Python的很多库都是用C写的，然后套上Python的解释器执行罢了。所以说他们之间的比较确实没有多大意义。比去比来，结果是比较“高手的C代码”与“低手的C代码”之间的比较。毕竟Python的C代码是经过实践考验的，值得信赖，但一般的C程序员不一定写出那么高的C代码。

#   Ishou 发表于2006-08-09 12:03:00  IP: 202.156.165.*

这种比较怎么没有意义？起码让您认识到，脚本语言写的程序的运作效能 在很多时候与 纯C/C++的程序 并没有多大差别，甚至由于脚本核心/库程序的优化， 脚本程序的运行效率更好！人们应该改变“脚本语言慢”的观念！ 脚本语言“慢”在程序码需要“解释”方面，如果需要“解释”程序码不长，这里的“解释”所消耗的时间是微不足道的。 另外，对于Windows中的一步操作， 程序消耗1毫秒 与消耗0.01毫秒是没有本质差别的，尽管后者比前者快了99倍之巨！ 脚本语言在组合现有已知的功能方面的灵活性、简洁性大大超过C/C++程序语言，但是在处理未知复杂的问题时，往往需要让脚本运行很多程序码，会大大降低脚本语言的运效率，通过脚本语言提供的C/C++接口，把这些复杂的东西用C/C++程序实现，做成脚本语言简便调用的库函数之类，脚本语言的程序可以获得很好的 开发和运行效率。 如果没有C/C++语言做后盾，纯粹用脚本语言开发会有瓶颈。 总之， 脚本语言 ＋ C/C++语言 可以获得很好的 开发和运行效果！

#   Ishou 发表于2006-08-09 12:08:00  IP: 202.156.165.*

这种比较怎么没有意义？起码让您认识到，脚本语言写的程序的运作效能 在很多时候与 纯C/C++的程序 并没有多大差别，甚至由于脚本核心/库程序的优化， 脚本程序的运行效率更好！人们应该改变“脚本语言慢”的观念！ 脚本语言“慢”在程序码需要“解释”方面，如果需要“解释”程序码不长，这里的“解释”所消耗的时间是微不足道的。 另外，对于Windows中的一步操作， 程序消耗1毫秒 与消耗0.01毫秒是没有本质差别的，尽管后者比前者快了99倍之巨！ 脚本语言在组合现有已知的功能方面的灵活性、简洁性大大超过C/C++程序语言，但是在处理未知复杂的问题时，往往需要让脚本运行很多程序码，会大大降低脚本语言的运效率，通过脚本语言提供的C/C++接口，把这些复杂的东西用C/C++程序实现，做成脚本语言简便调用的库函数之类，脚本语言的程序可以获得很好的 开发和运行效率。 如果没有C/C++语言做后盾，纯粹用脚本语言开发会有瓶颈。 总之， 脚本语言 ＋ C/C++语言 可以获得很好的 开发和运行效果！

#   Wayne 发表于2006-08-09 12:20:00  IP: 218.75.242.*

我们现在做的项目就是用c++和python，python跨平台很好用，而且开发速度很快。我很喜欢 python:)

#   Ishou 发表于2006-08-09 12:55:00  IP: 202.156.165.*

用 脚本语言 ＋ C/C++语言 做项目，尤其是大的项目，该脚本语言往往自然成为该项目进行 二次开发的脚本语言， 可以显著增强/拓展该 项目的功能！ 用C/C++搞一个适合本项目的二次开发语言，其难道往往比项目本身要大得多！

#   愚公 发表于2006-08-09 22:36:00  IP: 58.100.161.*

愚蠢的，毫无意义的比较。

#   redsea 发表于2006-08-12 11:27:00  IP: 219.136.215.*

今天看了 boost.serialization 在 vs 2005 下面生成的二进制码. 已经开了优化, 尽量 inline, 但是生成的代码还是无比冗长, 我想不会比 python pickle 的代码高效很多. boost.serialzation 里面又是用map, 又是用tree 的,似乎完全不考虑效率的. 加上 boost.filesystem, 已经看到 boost 里面两个基本不考虑效率的库了.

#   aaa 发表于2006-08-12 11:53:00  IP: 222.35.78.*

从这一个小项目能说明个p啊。 太无聊了吧？ 还有那么多人跟风。 可以肯定得说c得开发效率肯定低于Java,这个连入门人都知道，还在这里讨论。

#   问问 发表于2006-08-14 00:41:00  IP: 222.18.1.*

我还在上学，敢问：现在国内真在用python的公司多嘛？ 从书籍市场看，好像很少。

#   sungan 发表于2006-08-14 08:57:00  IP: 159.226.251.*

to redsea 我觉得你好像有些概念不是很清楚，你所说的“生成的二进制码”就是指生成的机器码把，开速度优化，尽量inline都是会使最终的代码量增加的方式，你使用了这些选项编译程序，然后抱怨生成的代码冗长，我觉得不大合适。我曾经使用intel编译器设置了执行速度最快的编译选项，要比vs2005编译器编译出来的代码量大了不只两倍。你认为intel比微软更不了解他的cpu吗？为了提高速度，大多数时候就要在空间上做出牺牲，代码量大不代表效率低，这是最基本的道理。 map和tree都是很有效率的，关键看你用来做什么，当然如果你非要用他们来完成一个用array都可以解决的问题，我就无话可说了

#   PP 发表于2006-08-14 17:35:00  IP: 222.90.66.*

to 问问 : 我们在用，去年的后台逻辑都是用Python写的！

#   abc 发表于2006-08-15 10:30:00  IP:

#   redsea 发表于2006-08-16 13:23:00  IP: 219.136.130.*

to sungan: 是我识lib 不明, 还想用serialization 这种库省掉我写object -> network packet, network packet ->object 的转化代码. 我只需要转换到简单的text 即可, 但我看到一个 int 转换到 text 的代码如此复杂, 里面又是map, 又是tree 的时候, 生成了无数的二进制吗, 我只好感叹, 通用的多功能library, 就是只能做一些很普通的事情, 例如保存配置之类的, 别的就不要指望了.

#   sungan 发表于2006-08-16 14:22:00  IP: 159.226.251.*

我对序列化这种东西了解不多，不敢妄言。但是仅想想动态存储和恢复对像的复杂过程就头疼不已。像你说的这种功能用序列化的确没啥必要。 同时我也很困惑究竟什么才是真正需要使用序列化的时机 在JAVA中序列化似乎也是一个很重要的组成部分，MFC中也提供了序列化的功能，可是为啥我就体会不到序列化的妙用?

#   ZXEOC 发表于2006-09-19 14:19:00  IP: 61.51.104.*

to redsea: 工具都是有适用范围的，如果只是简单的int到text，干吗非得用序列化？基本库里不是有itoa，就好像我只想开啤酒瓶，那只要拿个瓶起子就好了，用不着非花几百块买把瑞士军刀，沉甸甸的不说，弄不好还容易扎手

#   wooyon 发表于2007-01-02 11:53:23  IP: 58.53.76.*

to myan: 对C与Java的评价相对合理,从它们编译本质上看,二者几乎是在同一个级别,即几乎都是从无到有的实现;反而对Python待脚本语言则是高估,而且极其严重.你也知道 "Conch本身架构在Twisted之上，后者是一个高层的网络开发框架，本身也是具有6万行代码规模的项目。Conch的高效能很大程度上受惠于此。"? 因此授予期"10"的比重中极不合理的.至于对开发的工程量相关的比较,我认为只能作为这个比例来源的分析参考,不足以得出三者的这个比例

#   realdreamer 发表于2007-05-11 22:02:17  IP: 58.31.17.*

倒死, 这种数据能做互相比较吗. C 语言算是三语言中最新实现的, 那是基础, 我就不信开发其他语言版本的一点都没做参考. 人也是越来越聪明, 积累越来越多. 这种评价方法, 一点不科学.

#   realdreamer 发表于2007-05-11 22:04:38  IP: 58.31.17.*

序列化这玩意,我看就是好语言之人硬想出来的东西. 不要越搞越复杂了. 这不是万能的

来自：http://blog.csdn.net/myan/archive/2006/08/07/1033201.aspx

分类： 编程语言 程序人生 修炼之道