——根据2006年的讨论收集整理
一般印象中,脚本缺乏编译纠错,也没有好的调试跟踪工具
写写零零星星的工具、原型是上手快
但是做较大的项目,可能会难以胜任
但是,从代码量与复杂度的角度分析,好像正好倒过来了
python/ruby这些新的语言,不仅仅支持库强大,本身的表达能力也比较强悍/精炼
原来java需要1000行的,它们只要200行就行了
所以,比一般想象中的刚刚够复杂的系统再大5倍之内的系统,它们还是都能应付的
严格来推算,应该是25(5^2)倍或32(2^5)倍吧
因为 代码量的增加 导致的复杂度是加速增加的。。。
假设不采用严格控制的java所能开发的系统的复杂度极限为X,用java代码衡量,大约10000行(假设)的话
用python开发只要2000行就行了
如果一个系统,python也需要10000行,java就需要50000行,
那就是说这个系统的复杂度已经是X的32(2^5)倍了。。。
代码效率高5倍,能控制的项目的代码规模也可以大5倍,换算成复杂度,就是低25、32倍
当然这是理论值,所以最初保守的估计是能控制的项目的复杂度可以大5倍
就像以前只能用汇编语言,一般人能写的程序都比较简单的
有了c/c++后,一般人能写的程序功能也可以强大一些了
有了delphi/vb,一般人能写的程序功能就可以更强大了
虽然说:同样的项目,有 70个人,不能 比 10个人来做 快7倍
(在非严格、有效控制的模式下,多人合作开发时带来的沟通、协调的困难会抵消人多在数量上优势)
但是,一个项目,如果复杂度(代码量)降了7倍,就意味着这10个人会轻松很多;只有大7倍的项目,才是他们以前工作负荷(正常掌控能力)
我的判断的依据是:一个人能控制的代码量是恒定的(在同样人数、同样管理模式的项目中)
代码(本身的表达、描述、控制)效率高了,
在同样人数的开发过程中,
单人能控制的代码量并没变,
但是同样行数的代码量,新语言能完成的功能(复杂度)已经提高了很多倍
另一个规则:代码量的增加,会导致复杂都加速(而不是线性)增加
在同样人数的开发过程中,
单人能控制的代码量并没变,
但是换算成旧语言(java)的代码量,两者就会有5倍的差距了
对应的项目的复杂度按旧语言的代码量计算,对应地,就有5^2或2^5的差距了
换一个角度:在相同的开发模式、相同的人数下,一个人能控制的代码量是有极限的,假设为1万行--a
按旧到新排列:汇编语言、java、python都是1万行
(其实,旧的语言一般更难控制,人能控制的极限行数应该更少,这里姑且认为一样吧)
但是语言本身的表达、描述、控制的效率(平均到每行)是有差异的
估计java的表达能力是汇编的5倍,python的表达能力是java的5倍--b
以java的1万行为基准,汇编大约要5万行才能实现同样的功能效果,而python可能只需要2千行
再套用一个人能控制的代码量的极限:1万行
再以java为基准,1万行的汇编代码,只能实现java的2千行的功能,而1万行的python已经能实现5万行java能实现的效果了--c
再套用一个规则:项目的复杂度与代码量成平方或指数的关系--d
5万行java的项目的复杂度已经是1万行java的项目复制度的5^2(=25)或2^5(=32)倍了
所以,结论是:一个人用不同语言,能控制的项目的复杂度极限分别为:
以java为基准,设1万行java的复杂度为:X
汇编:X/25或X/32
python:X*25或X*32
考虑到python目前尚无好用的跟踪调试手段,保守一点,应该也有X*5吧
附:
使用过delphi之后,再使用c/c++(没使用string,只使用char*或s[]),总感觉特别费劲
仔细想了一下,原来是字符串操作最明显:
本来delphi字符串赋值或附加是一句话的事情,c里面却不得不先计算好事后的字符数,再分配空间,才能复制或追加,而且很多时候还必须释放空间。。。。。
当然,delphi写服务程序(需要长期运行)也容易因为频繁或大量的字符串操作所引发的内存碎片等问题而不稳定