g*****g
发帖数: 34805 | 1 俺个人用得比较多的脚本语言是javascript，以前也用过一点perl。
python/ruby等等，在可读性上有进步，在某些领域的好处是毋庸置疑的。
比如写一个quick and dirty或者prototype的东西，肯定很快。
坏处也是共通的。
1. 可维护性，ruby的创始人说软件是依靠单元测试，而不是编译器来查错的。
充分测试的软件，动态还是静态类型没有区别。他说的并没有错，问题是
复杂软件往往难以充分测试，在成为产品之后发现问题是正常的。静态类型局限了
这些bug是逻辑问题，而动态类型，就有简单typo等等错误引发的可能。你很不希望
看到因为这样的简单错误而必须去patch你的系统。
2. public API
前面coconut提过，动态类型使得调用者依赖于文档而不是接口本身来了解接口。
这往往会使代码难读，容易出运行时错。可读性好的源程序并不需要很多注释，
当你觉得注释很必要的时候可能更需要的是refactor。对于这个大家可以读读这
本书。emule上有。
Addison Wesley - Refactoring Improving the Design of Ex |
r****t
发帖数: 10904 | 2 他说的是对的，可维护性有多种因素。动态类型有这个问题，所以要求很完全详细的测
试，尽量充分。静态类型写出来的东西也逃不掉单元测试，不同的是测试的时候你的信
心多一些，你的code可能更容易写出来就通过测试。可是你需要写更多的code, 对每
piece 多的 code, 你要写多出来的测试。
现在严肃点的 project, 就我看到的从 python 里的，testing 是很严谨的。
【在 g*****g 的大作中提到】
: 俺个人用得比较多的脚本语言是javascript，以前也用过一点perl。
: python/ruby等等，在可读性上有进步，在某些领域的好处是毋庸置疑的。
: 比如写一个quick and dirty或者prototype的东西，肯定很快。
: 坏处也是共通的。
: 1. 可维护性，ruby的创始人说软件是依靠单元测试，而不是编译器来查错的。
: 充分测试的软件，动态还是静态类型没有区别。他说的并没有错，问题是
: 复杂软件往往难以充分测试，在成为产品之后发现问题是正常的。静态类型局限了
: 这些bug是逻辑问题，而动态类型，就有简单typo等等错误引发的可能。你很不希望
: 看到因为这样的简单错误而必须去patch你的系统。
: 2. public API
|
g*****g
发帖数: 34805 | 3 我说的是测试事实上总是不够充分的，而打patch是昂贵的。
你不希望为了typo这样的错误打patch. 并不是说静态类型
就可以不单元测试。
【在 r****t 的大作中提到】
: 他说的是对的，可维护性有多种因素。动态类型有这个问题，所以要求很完全详细的测
: 试，尽量充分。静态类型写出来的东西也逃不掉单元测试，不同的是测试的时候你的信
: 心多一些，你的code可能更容易写出来就通过测试。可是你需要写更多的code, 对每
: piece 多的 code, 你要写多出来的测试。
: 现在严肃点的 project, 就我看到的从 python 里的，testing 是很严谨的。
|
r****t
发帖数: 10904 | 4 这个其实很快就有体会，确实接口看起来模糊了，你得靠文档，甚至经常需要看源码。
我想这是很多 project refractory 好几回的原因，开始时候大家都不清楚，
scripting 的大 project 本来就不多，很多时候是摸着石头过河。
从我个人的感觉来说，这强迫写接口的人写的尽量 generic, 好像写 template 一样，
而把实现的细节放到数据对象里面， focus on data 而不是 procedure. 我没参加过
什么大 project, 只能是就自己感觉随便说说。
【在 g*****g 的大作中提到】
: 我说的是测试事实上总是不够充分的，而打patch是昂贵的。
: 你不希望为了typo这样的错误打patch. 并不是说静态类型
: 就可以不单元测试。
|
c*****t
发帖数: 1879 | 5 我觉得单纯的依靠 test driven dev 比较愚蠢。这根本不是什么万能的
东西，只是作为一个辅助手段而已。test 本身需要大量的时间和精力去
写 case 和测试，花的时间可以比写程序多出很多。随便一个程序里面都
有 N 个 branch，你想把每个 branch 都测试么？考虑一下需要多少 test
case 先。而说不定 spelling mistake 就在那里。
再不说 test 的时间有限，甚至连 documentation 的时间也都是个问题。
scripting language 在这两面都是弱点。在时间紧迫的情况下，你是花
时间写 test case，documentation 还是去 code ？
【在 r****t 的大作中提到】
: 他说的是对的，可维护性有多种因素。动态类型有这个问题，所以要求很完全详细的测
: 试，尽量充分。静态类型写出来的东西也逃不掉单元测试，不同的是测试的时候你的信
: 心多一些，你的code可能更容易写出来就通过测试。可是你需要写更多的code, 对每
: piece 多的 code, 你要写多出来的测试。
: 现在严肃点的 project, 就我看到的从 python 里的，testing 是很严谨的。
|
f*****Q
发帖数: 1912 | 6 ship源代码是个问题。当年在公司混的时候用perl做的东西自己用的好好的，后来卖的
时候都改JSP和Servlet了。 |
r****t
发帖数: 10904 | 7 没错，测试很可能不充分，所以这个强迫 scripting project 有更完善的测试，是没
有办法的事。typo 这样的错误只能指望 tests cover 住了，这就是为什么很多
project 每一 piece code 都必须通过测试，没测试的 code 不许 commit。
scripting project 都还不大，不到打 patch 昂贵的时候，大多还 open source, 用
户随手打了往 mailing list 上就扔。
【在 g*****g 的大作中提到】
: 我说的是测试事实上总是不够充分的，而打patch是昂贵的。
: 你不希望为了typo这样的错误打patch. 并不是说静态类型
: 就可以不单元测试。
|
g*****g
发帖数: 34805 | 8 That's what I think too. Java generics helps reduce a lot of
runtime classcast exception, that's the biggest boost of using
generics. static-type languages are going more static for a reason.
When every line of code has such potential, it's gonna
be a problem.
【在 c*****t 的大作中提到】
: 我觉得单纯的依靠 test driven dev 比较愚蠢。这根本不是什么万能的
: 东西，只是作为一个辅助手段而已。test 本身需要大量的时间和精力去
: 写 case 和测试，花的时间可以比写程序多出很多。随便一个程序里面都
: 有 N 个 branch，你想把每个 branch 都测试么？考虑一下需要多少 test
: case 先。而说不定 spelling mistake 就在那里。
: 再不说 test 的时间有限，甚至连 documentation 的时间也都是个问题。
: scripting language 在这两面都是弱点。在时间紧迫的情况下，你是花
: 时间写 test case，documentation 还是去 code ？
|
r****t
发帖数: 10904 | 9 在时间紧迫的情况下，scripting project 可以完全放弃 documentation and tests。
当然这是以牺牲 project 质量为代价，问题是对很多这样的 project 来讲他们牺牲的
起，因为code base 小，也足够灵活。
我前面说的是，如果想要用 scripting language 开发严肃的大 project, 我所看到的
做法。如果讲时间紧迫的情况，自然 scripting language 可以有很不讲理的办法。在
这两种做法中间根据情况取平衡，是我看到的现状。因为不同的 project 对这方面的要
求本来就不一样。twisted 这样的就搞的严谨，因为比较底层，关系比较广，用的人也
很多。可以说twisted code 算是 rock solid 的我信。如果是关系不太大的 project，
完全可以除掉这些包袱，或者说到后来再慢慢加上，整个是个 evolve 的过程，比如
IPython 这样的。
【在 c*****t 的大作中提到】
: 我觉得单纯的依靠 test driven dev 比较愚蠢。这根本不是什么万能的
: 东西，只是作为一个辅助手段而已。test 本身需要大量的时间和精力去
: 写 case 和测试，花的时间可以比写程序多出很多。随便一个程序里面都
: 有 N 个 branch，你想把每个 branch 都测试么？考虑一下需要多少 test
: case 先。而说不定 spelling mistake 就在那里。
: 再不说 test 的时间有限，甚至连 documentation 的时间也都是个问题。
: scripting language 在这两面都是弱点。在时间紧迫的情况下，你是花
: 时间写 test case，documentation 还是去 code ？
|
c*****t
发帖数: 1879 | 10 那为什么写大 project 用 scripting language 呢？想给自己找麻烦？
又难开发，又难测试，又难 document，又花的时间长，执行起来又慢。
难道是大老爷们比富，不求最好，只求最贵？还是为了那个口号 yes we can?
【在 r****t 的大作中提到】
: 在时间紧迫的情况下，scripting project 可以完全放弃 documentation and tests。
: 当然这是以牺牲 project 质量为代价，问题是对很多这样的 project 来讲他们牺牲的
: 起，因为code base 小，也足够灵活。
: 我前面说的是，如果想要用 scripting language 开发严肃的大 project, 我所看到的
: 做法。如果讲时间紧迫的情况，自然 scripting language 可以有很不讲理的办法。在
: 这两种做法中间根据情况取平衡，是我看到的现状。因为不同的 project 对这方面的要
: 求本来就不一样。twisted 这样的就搞的严谨，因为比较底层，关系比较广，用的人也
: 很多。可以说twisted code 算是 rock solid 的我信。如果是关系不太大的 project，
: 完全可以除掉这些包袱，或者说到后来再慢慢加上，整个是个 evolve 的过程，比如
: IPython 这样的。
|
|
|
r****t
发帖数: 10904 | 11 底层支持是个问题，这就是为什么有 Jython, IronPython 这样的其他实现，
mpipython也是，现在我都没碰过这些，没有什么发言权。
【在 g*****g 的大作中提到】
: That's what I think too. Java generics helps reduce a lot of
: runtime classcast exception, that's the biggest boost of using
: generics. static-type languages are going more static for a reason.
: When every line of code has such potential, it's gonna
: be a problem.
|
g*****g
发帖数: 34805 | 12 据说开发快，5倍那么快，Python/Ruby的用户说的，我没有实际经验。
【在 c*****t 的大作中提到】
: 那为什么写大 project 用 scripting language 呢？想给自己找麻烦？
: 又难开发，又难测试，又难 document，又花的时间长，执行起来又慢。
: 难道是大老爷们比富，不求最好，只求最贵？还是为了那个口号 yes we can?
|
r****t
发帖数: 10904 | 13 well，可能你讲的大 project 比我讲的要大吧。
开发、测试、document 不见得更难，有可能更简单。就讲 doctest 吧不难啊。
花的时间长，执行起来又慢，这些问题自然是不用我们讲，如果没一点好处自然没人用
了。
就我看到的，everything in pure python 是有这种说法，有这种做法，但是这不只是
yes we can 的问题，这种选择和 deployment 有关，JAVA is a platform, Python
is only a language, 再怎么 battary included 也比不上 JAVA。追求 pure python
的作者很多时候是因为 pure python module/app is much easier to be
distributed/deployed, 因为有 cross-os 的原因。
"yes we can" 也不是什么坏事，python glue 也还没到啥东西拿来就能用的程度。
【在 c*****t 的大作中提到】
: 那为什么写大 project 用 scripting language 呢？想给自己找麻烦？
: 又难开发，又难测试，又难 document，又花的时间长，执行起来又慢。
: 难道是大老爷们比富，不求最好，只求最贵？还是为了那个口号 yes we can?
|
g*****g
发帖数: 34805 | 14 我不是bash python/ruby，最近scripting language 的hype很多，
想了解一下主要好处和一些关键问题怎么解决。
python/ruby的行数比java要短，相对而言java verbose。这个毫无疑问，
但我个人认为想占用了主要时间，而不是写代码本身。我个人不是很相信
特定任务以外，能有5倍的生产率。
python
【在 r****t 的大作中提到】
: well，可能你讲的大 project 比我讲的要大吧。
: 开发、测试、document 不见得更难，有可能更简单。就讲 doctest 吧不难啊。
: 花的时间长，执行起来又慢，这些问题自然是不用我们讲，如果没一点好处自然没人用
: 了。
: 就我看到的，everything in pure python 是有这种说法，有这种做法，但是这不只是
: yes we can 的问题，这种选择和 deployment 有关，JAVA is a platform, Python
: is only a language, 再怎么 battary included 也比不上 JAVA。追求 pure python
: 的作者很多时候是因为 pure python module/app is much easier to be
: distributed/deployed, 因为有 cross-os 的原因。
: "yes we can" 也不是什么坏事，python glue 也还没到啥东西拿来就能用的程度。
|
r****t
发帖数: 10904 | 15 是有 hype 的成分，当然 hype 也是有原因的。我不像你们干过很多 project, 很有
experience, 就只能就自己看见的来说，可能对你们不是很有帮助。
我觉得5倍效率看你怎么取舍了，是要速度还是要质量/可持续开发性，你要是 test/
document 上面不要求这么严，我看不要说 5 倍， 就是 10 倍都有可能，但是搞出来
的东西，maintain 的时候可能要 refractor 一遍，改写一遍都有可能。这些方面很多
都是在试，不是马上就能给个断言的东西，出的问题不是都能预见到。用scripting的
公司不那么多，也有这原因都在慢慢摸索。有 worry about scalability 肯定是有。
但是我听说 youtube 基本是 python 写的，所以说也有人也做到了。
code base 小是个好处，有些笑话讲, c++ team 开上几个会，定几个 paradim, 类结
构什么的，画完那什么图，然后开始coding 的 project, 一个 python coder 自己想
想，一个下午就搞了。虽然有点夸张，但不是不可能的(实现的优虐不论),
【在 g*****g 的大作中提到】
: 我不是bash python/ruby，最近scripting language 的hype很多，
: 想了解一下主要好处和一些关键问题怎么解决。
: python/ruby的行数比java要短，相对而言java verbose。这个毫无疑问，
: 但我个人认为想占用了主要时间，而不是写代码本身。我个人不是很相信
: 特定任务以外，能有5倍的生产率。
:
: python
|
f*******y
发帖数: 988 | 16 动态这个东西越小越爽，程序一大debug挺麻烦
尤其是perl这种一句话有10种说法的，一编译全是语法正确的，一运行全错光
【在 g*****g 的大作中提到】
: 俺个人用得比较多的脚本语言是javascript，以前也用过一点perl。
: python/ruby等等，在可读性上有进步，在某些领域的好处是毋庸置疑的。
: 比如写一个quick and dirty或者prototype的东西，肯定很快。
: 坏处也是共通的。
: 1. 可维护性，ruby的创始人说软件是依靠单元测试，而不是编译器来查错的。
: 充分测试的软件，动态还是静态类型没有区别。他说的并没有错，问题是
: 复杂软件往往难以充分测试，在成为产品之后发现问题是正常的。静态类型局限了
: 这些bug是逻辑问题，而动态类型，就有简单typo等等错误引发的可能。你很不希望
: 看到因为这样的简单错误而必须去patch你的系统。
: 2. public API
|
N********n
发帖数: 8363 | 17
是快点，但5倍是吹牛皮而已。PYTHON和JAVA的比较我看过，什么JAVA代码长
之类的。STRONG TYPE的CODE虽然长，但很多是用INTELLISENSE/AUTO COMPLETE
快速生成的，实际工作量根本没有看上去那么大。
Dynamic Language强调不用定义变量，可是不定义变量的话IDE不知道你的TYPE，
那还能Intellisense么？如果不能的话，这样的DL恐怕是COUNTER-PRODUCTIVE
而不是PRODUCTIVE。试想一下定义一个OBJECT里面诸多VARIABLE，METHOD。没
INTELLISENSE/AUTO COMPLETE咋玩，所有名字全凭记忆，开玩笑吗。
【在 g*****g 的大作中提到】
: 据说开发快，5倍那么快，Python/Ruby的用户说的，我没有实际经验。
|
r****t
发帖数: 10904 | 18 completion 很重要么？我偶尔想不起来了也用用，不是critical的因素吧。这些图还只是VI里面，full IDE该更不是问题。
面向对象的 scripting language 可以有 introspection. 有 interactive shell 你可以 play with and experiment with 小块 code, 这是好用的关键。
http://omploader.org/vNnp5
【在 N********n 的大作中提到】
:
: 是快点，但5倍是吹牛皮而已。PYTHON和JAVA的比较我看过，什么JAVA代码长
: 之类的。STRONG TYPE的CODE虽然长，但很多是用INTELLISENSE/AUTO COMPLETE
: 快速生成的，实际工作量根本没有看上去那么大。
: Dynamic Language强调不用定义变量，可是不定义变量的话IDE不知道你的TYPE，
: 那还能Intellisense么？如果不能的话，这样的DL恐怕是COUNTER-PRODUCTIVE
: 而不是PRODUCTIVE。试想一下定义一个OBJECT里面诸多VARIABLE，METHOD。没
: INTELLISENSE/AUTO COMPLETE咋玩，所有名字全凭记忆，开玩笑吗。
|
N********n
发帖数: 8363 | 19
写大程序时还是很有用的。试想一个项目成百上千个CLASS，每个CLASS里面数
个FIELDS, METHODS，如果没有INTELLISENSE怎么记得住这些名字。每次要用的
时候还要自己去查去记忆。这类机械性的工作应该让IDE去做，而不是人力。这
个时候就体现出STRONG TYPED的优势了。ST那些预定义是和IDE做交易，得到的
回报是INTELLISENSE. DL象个铁公鸡，一毛不拔，结果IDE不管了，“你不给我
预定义那你自己玩去吧”。贪小便宜吃大亏。
【在 r****t 的大作中提到】
: completion 很重要么？我偶尔想不起来了也用用，不是critical的因素吧。这些图还只是VI里面，full IDE该更不是问题。
: 面向对象的 scripting language 可以有 introspection. 有 interactive shell 你可以 play with and experiment with 小块 code, 这是好用的关键。
: http://omploader.org/vNnp5
|
r****t
发帖数: 10904 | 20 Scripting language 也有 Strong typed 的，Python 就是 Strong typed. Strong typed 和 dynamic typed 并不矛盾。Strong <-> weak, dynamic <-> static
你可能不习惯使用 interactive shell，introspection 和 interactive shell 一起能弥补你说的这个问题：
在 Python 里面，你要想知道一个object 有那些 method, 用 dir(obj) 就可以了，如果你用下面这个图里面的IPython，只要 obj? 甚至 obj.之后按 TAB 补全就行，然后可以一直 introspect 下去。比如这儿，你有了一个 string, 你想要知道这个 string 有那些 method, 按 s. 之后 TAB, 所有的 method 都列出来了，你可以 s.replace? 看 .replace method 的文档， 或者加打个? 直接看这个method 的源码。
你看，Dynamic typing language, 这儿是Py
【在 N********n 的大作中提到】
:
: 写大程序时还是很有用的。试想一个项目成百上千个CLASS，每个CLASS里面数
: 个FIELDS, METHODS，如果没有INTELLISENSE怎么记得住这些名字。每次要用的
: 时候还要自己去查去记忆。这类机械性的工作应该让IDE去做，而不是人力。这
: 个时候就体现出STRONG TYPED的优势了。ST那些预定义是和IDE做交易，得到的
: 回报是INTELLISENSE. DL象个铁公鸡，一毛不拔，结果IDE不管了，“你不给我
: 预定义那你自己玩去吧”。贪小便宜吃大亏。
|
|
|
X****r
发帖数: 3557 | 21 老实说我不觉得这些自动补全之类的功能对总体的开发速度有多大影响。
就像前面有人说的那样，程序员的主要时间不是花在把代码从键盘输入到计算机里。
项目越大，这个的比重越小。输入代码的时间和代码大小成正比，而一般认为bug
的数目和代码大小的平方成正比（当然单元测试这些作得比较好的会好一点，但我
觉得怎么也有1.5次方吧），就算每个bug的解决时间是常数（实际我估计是代码
大小的.5次方左右），代码大了以后也会有越来越多的时间在QA周期上。还有一个
就是iteration带来的refactoring。假设feature数和代码大小成正比，每个feature
在单位时间里需求要改变的可能性为常数，而iteration次数和feature数目的.5次方
成正比，那refactoring所花的相对时间也会越来越多，虽然没有QA那么多。
你看那些大的项目，比如Windows，你把它的总代码行数除以开发人员的数目和所花
的时间，它名义上的每人每天写的行数是很小的数字。
起能弥补
如果你用下面这个图里面的IPython，只要 obj? 甚至 obj.之后按 TAB 补全就行，然
后可以一直 intro
【在 r****t 的大作中提到】
: Scripting language 也有 Strong typed 的，Python 就是 Strong typed. Strong typed 和 dynamic typed 并不矛盾。Strong <-> weak, dynamic <-> static
: 你可能不习惯使用 interactive shell，introspection 和 interactive shell 一起能弥补你说的这个问题：
: 在 Python 里面，你要想知道一个object 有那些 method, 用 dir(obj) 就可以了，如果你用下面这个图里面的IPython，只要 obj? 甚至 obj.之后按 TAB 补全就行，然后可以一直 introspect 下去。比如这儿，你有了一个 string, 你想要知道这个 string 有那些 method, 按 s. 之后 TAB, 所有的 method 都列出来了，你可以 s.replace? 看 .replace method 的文档， 或者加打个? 直接看这个method 的源码。
: 你看，Dynamic typing language, 这儿是Py
|
N********n
发帖数: 8363 | 22
你如果不知道TYPE怎么补全？别人PASS给你一个LIST，你不知道里面存的是什么
OBJECT，你怎么去interactive shell？你的INTEPRETER环境只能判断出静态的
信息，运行时谁知道那个LIST里面放的是什么。
【在 r****t 的大作中提到】
: Scripting language 也有 Strong typed 的，Python 就是 Strong typed. Strong typed 和 dynamic typed 并不矛盾。Strong <-> weak, dynamic <-> static
: 你可能不习惯使用 interactive shell，introspection 和 interactive shell 一起能弥补你说的这个问题：
: 在 Python 里面，你要想知道一个object 有那些 method, 用 dir(obj) 就可以了，如果你用下面这个图里面的IPython，只要 obj? 甚至 obj.之后按 TAB 补全就行，然后可以一直 introspect 下去。比如这儿，你有了一个 string, 你想要知道这个 string 有那些 method, 按 s. 之后 TAB, 所有的 method 都列出来了，你可以 s.replace? 看 .replace method 的文档， 或者加打个? 直接看这个method 的源码。
: 你看，Dynamic typing language, 这儿是Py
|
r****t
发帖数: 10904 | 23 没错，自动补全不重要。
但是 interactive shell 很重要，如果你用 scripting lang 的话，简直是 critical
. 我自己如果没了 interactive shell 可能连20行都不能写出来。
【在 X****r 的大作中提到】
: 老实说我不觉得这些自动补全之类的功能对总体的开发速度有多大影响。
: 就像前面有人说的那样，程序员的主要时间不是花在把代码从键盘输入到计算机里。
: 项目越大，这个的比重越小。输入代码的时间和代码大小成正比，而一般认为bug
: 的数目和代码大小的平方成正比（当然单元测试这些作得比较好的会好一点，但我
: 觉得怎么也有1.5次方吧），就算每个bug的解决时间是常数（实际我估计是代码
: 大小的.5次方左右），代码大了以后也会有越来越多的时间在QA周期上。还有一个
: 就是iteration带来的refactoring。假设feature数和代码大小成正比，每个feature
: 在单位时间里需求要改变的可能性为常数，而iteration次数和feature数目的.5次方
: 成正比，那refactoring所花的相对时间也会越来越多，虽然没有QA那么多。
: 你看那些大的项目，比如Windows，你把它的总代码行数除以开发人员的数目和所花
|
r****t
发帖数: 10904 | 24 interactive shell 就是 interpreter, 你当然要拿个 list 去试验。比如，你 evoke interactive shell after the list is passed. 然后 type(list[0]) 就知道了，这和gdb debug 是一个道理，不同的是你跳过了compiling 和 linking。interpreter 知道 dynamic 的信息，只要你提供 dynamic tests.
补全只是补全name, 要了解 name 指向的 object，需要 introspection.
【在 N********n 的大作中提到】
:
: 你如果不知道TYPE怎么补全？别人PASS给你一个LIST，你不知道里面存的是什么
: OBJECT，你怎么去interactive shell？你的INTEPRETER环境只能判断出静态的
: 信息，运行时谁知道那个LIST里面放的是什么。
|
r****t
发帖数: 10904 | 25 关于这一点我忘了提 Python 的 Traits, 明天再聊。
【在 g*****g 的大作中提到】
: 我不是bash python/ruby，最近scripting language 的hype很多，
: 想了解一下主要好处和一些关键问题怎么解决。
: python/ruby的行数比java要短，相对而言java verbose。这个毫无疑问，
: 但我个人认为想占用了主要时间，而不是写代码本身。我个人不是很相信
: 特定任务以外，能有5倍的生产率。
:
: python
|
g*****g
发帖数: 34805 | 26 这个bug跟行数成正比是不对的，很多脚本语言里里你可以把很多东西
pack到一行，复杂无比，你不能说这跟简单的一行成正比。
另外比如大多数语言都有{}或者start/end，python没有，
这你也不能算行数。
http://www.dmh2000.com/cjpr/
这里，红黑树java实现282行，ruby/python都是210行左右。
扣掉这些，我想差别也就在10%-20%。5倍怕是达不到。
【在 X****r 的大作中提到】
: 老实说我不觉得这些自动补全之类的功能对总体的开发速度有多大影响。
: 就像前面有人说的那样，程序员的主要时间不是花在把代码从键盘输入到计算机里。
: 项目越大，这个的比重越小。输入代码的时间和代码大小成正比，而一般认为bug
: 的数目和代码大小的平方成正比（当然单元测试这些作得比较好的会好一点，但我
: 觉得怎么也有1.5次方吧），就算每个bug的解决时间是常数（实际我估计是代码
: 大小的.5次方左右），代码大了以后也会有越来越多的时间在QA周期上。还有一个
: 就是iteration带来的refactoring。假设feature数和代码大小成正比，每个feature
: 在单位时间里需求要改变的可能性为常数，而iteration次数和feature数目的.5次方
: 成正比，那refactoring所花的相对时间也会越来越多，虽然没有QA那么多。
: 你看那些大的项目，比如Windows，你把它的总代码行数除以开发人员的数目和所花
|
g*****g
发帖数: 34805 | 27 这个就要花额外时间了吧，而且也容易错。
evoke interactive shell after the list is passed. 然后 type(list[0]) 就知道
了，这和gdb debug 是一个道理，不同的是你跳过了compiling 和 linking。
interpreter 知道 dynamic 的信息，
object，需要 introspection.
【在 r****t 的大作中提到】
: interactive shell 就是 interpreter, 你当然要拿个 list 去试验。比如，你 evoke interactive shell after the list is passed. 然后 type(list[0]) 就知道了，这和gdb debug 是一个道理，不同的是你跳过了compiling 和 linking。interpreter 知道 dynamic 的信息，只要你提供 dynamic tests.
: 补全只是补全name, 要了解 name 指向的 object，需要 introspection.
|
N********n
发帖数: 8363 | 28
能在静态环境下靠COMPILER纠正的错就不应该推迟到运行时刻。比如访问数
据库，不管是用STRONG TYPED DATASET还是各类ORM 的TOOL，机器自动生成
一堆CODE看上去很多，但都是DRAG/DROP出来的，没有实际工作量，生成之
后就不用管了。但是保证绝不会类型失配，不会把DATETIME存到STRING的
COLUMN里面。程序员只要注重其他部分的逻辑就可以了，以后单元测试时根
本不用担心这类问题。测试起来要快得多。
DL图快，把TYPE CHECK丢给RUNTIME，即使有单元测试也未必能COVER完全。
另外也没觉得DL有多快，写Hello World是挺快。作大程序时不定义变量类型
没INTELLISENSE，没AUTO COMPLELE还有多快就不知道了。
【在 X****r 的大作中提到】
: 老实说我不觉得这些自动补全之类的功能对总体的开发速度有多大影响。
: 就像前面有人说的那样，程序员的主要时间不是花在把代码从键盘输入到计算机里。
: 项目越大，这个的比重越小。输入代码的时间和代码大小成正比，而一般认为bug
: 的数目和代码大小的平方成正比（当然单元测试这些作得比较好的会好一点，但我
: 觉得怎么也有1.5次方吧），就算每个bug的解决时间是常数（实际我估计是代码
: 大小的.5次方左右），代码大了以后也会有越来越多的时间在QA周期上。还有一个
: 就是iteration带来的refactoring。假设feature数和代码大小成正比，每个feature
: 在单位时间里需求要改变的可能性为常数，而iteration次数和feature数目的.5次方
: 成正比，那refactoring所花的相对时间也会越来越多，虽然没有QA那么多。
: 你看那些大的项目，比如Windows，你把它的总代码行数除以开发人员的数目和所花
|
r****t
发帖数: 10904 | 29 experimenting code in interactive shel 占去开发的大部分时间，在scripting里面
不是什么奇怪的事。我觉得这是节约了compiling/linking 的时间
【在 g*****g 的大作中提到】
: 这个就要花额外时间了吧，而且也容易错。
:
: evoke interactive shell after the list is passed. 然后 type(list[0]) 就知道
: 了，这和gdb debug 是一个道理，不同的是你跳过了compiling 和 linking。
: interpreter 知道 dynamic 的信息，
: object，需要 introspection.
|
r****t
发帖数: 10904 | 30 我看了下这个 http://www.dmh2000.com/cjpr/， 比较行数的问题放一边。
他的 Python 实现(可能 ruby 实现也是）基本上是literally translated from Java
version。
【在 g*****g 的大作中提到】
: 这个bug跟行数成正比是不对的，很多脚本语言里里你可以把很多东西
: pack到一行，复杂无比，你不能说这跟简单的一行成正比。
: 另外比如大多数语言都有{}或者start/end，python没有，
: 这你也不能算行数。
: http://www.dmh2000.com/cjpr/
: 这里，红黑树java实现282行，ruby/python都是210行左右。
: 扣掉这些，我想差别也就在10%-20%。5倍怕是达不到。
|
|
|
g*****g
发帖数: 34805 | 31 你的意思是他的实现很不python，重写一下会简单很多？
他看似根据读者意见改了很多版本，应该不是问题吧。
Java
【在 r****t 的大作中提到】
: 我看了下这个 http://www.dmh2000.com/cjpr/， 比较行数的问题放一边。
: 他的 Python 实现(可能 ruby 实现也是）基本上是literally translated from Java
: version。
|
r****t
发帖数: 10904 | 32 我是有这个worry. 如果他改了很多那应该还可以把。这样实现的RBTree 不好直接用在
自己程序里。Python 有个 RBTree module, 如果一定要用我会用那个。
俺贴一个这种比较贴看看，先找一下去。
【在 g*****g 的大作中提到】
: 你的意思是他的实现很不python，重写一下会简单很多？
: 他看似根据读者意见改了很多版本，应该不是问题吧。
:
: Java
|
r****t
发帖数: 10904 | 33 http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/
JRuby 快得惊人阿。
【在 r****t 的大作中提到】
: 我是有这个worry. 如果他改了很多那应该还可以把。这样实现的RBTree 不好直接用在
: 自己程序里。Python 有个 RBTree module, 如果一定要用我会用那个。
: 俺贴一个这种比较贴看看，先找一下去。
|
g*****g
发帖数: 34805 | 34 俺怎么看了一眼，结论是出了Java/C++, 其他语言performance太差了。
Java居然beat C++这么多到时没想到，不过通常他俩在一个量级上。
【在 r****t 的大作中提到】
: http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/
: JRuby 快得惊人阿。
|
r****t
发帖数: 10904 | 35 object creation/init, attribute manipulation, object destroy， scripting
language 怎么和 java/c++ 比？整个多了一层interpreter嘛。比得是同类的
【在 g*****g 的大作中提到】
: 俺怎么看了一眼，结论是出了Java/C++, 其他语言performance太差了。
: Java居然beat C++这么多到时没想到，不过通常他俩在一个量级上。
|
g*****g
发帖数: 34805 | 36 通常在10这个量级上还好，到100就有顾虑了。
python/ruby/groovy要想成为通用语言，不能
比静态语言慢10倍以上。
【在 r****t 的大作中提到】
: object creation/init, attribute manipulation, object destroy， scripting
: language 怎么和 java/c++ 比？整个多了一层interpreter嘛。比得是同类的
|
