每个程序员都应该学习使用Python或Ruby，你怎么认为？

OwnWaterloo

回复 80# starwing83

>> 代码行数绝不代表写这些代码的速度！！

这点同意。那么代码行数与维护性呢？

呃，这与Python vs C++没什么关系……  反正这种比较多了去了……
比如许多Haskell的文章都喜欢说自己的merge sort只要1行，对比的C/C++要多少多少行……
但haskell的merge sort里直接使用filter等函数，不算在总行数内……
而C/C++的就自己实现，算在总行数内……

倒是与《梦断代码》有点关系。


我认为那种写得快，读起来也比较顺畅的，行数长的代码，最终不一定能提高整个项目的可维护性。
记得AD在前段时间也提到过"有没有某项目维持不下去，头脑转换不过来的感觉"还是什么的。
对我个人来说的话，代码总行数也是因素之一。总行数多到一定的数目，比如1w（差不多就是lua那个样子）就感觉力不从心。心理上就自己认为无法了解它的全部细节。
如果代码行数 —— 无论每行多么简单 —— 是爆掉脑栈的因素之一的话，被爆掉的后果就是必须分工。一些人了解一部分细节，另一些人了解另一部分。
但分工不是无代价的 —— 这东西应该在《人月神话》里提得比较多，不知道《梦断代码》有没有专门提出这点 —— 分工造成的额外负担是否靠人力赚得回来？
如果能，能赚回多少？如果比例很小，那就真成人海战术了，靠人去撑、去堆，基本不死也残废。如果周期再长一点，换一轮血什么的…… 基本死定……

当然，也不是说那种每行都包含很多技巧的代码维护性就好了。
这问题是无解的？

walleeee

有本书叫短码之美

walleeee

回复 121# OwnWaterloo


    你的砖家出现了

hbsycw 发表于 2012-05-09 11:56
非常好的活动，支持！

信息安全很重要是因为信息的安全太脆弱了~

KanonInD

回复 121# OwnWaterloo


    看ghc7.04的源码包，haskell的merge sort 明明没filter。 而quicksort的实现当中倒有一个，而且还用了万恶的++。
    要是当初Paul Graham被众多lisp macro爆了脑栈, viaweb就完了。

OwnWaterloo

回复 124# KanonInD

>>  看ghc7.04的源码包，haskell的merge sort 明明没filter。 而quicksort的实现当中倒有一个，而且还用了万恶的++。

我指的不是ghc源代码，而是：

>> 比如许多Haskell的文章都喜欢说自己的merge sort只要1行，对比的C/C++要多少多少行……

比如给你找一个： http://www.haskell.org/haskellwiki/Why_Haskell_Matters#Elegance
这是quicksort的。不过有类似"比较"的文章很多很多……


>>  要是当初Paul Graham被众多lisp macro爆了脑栈, viaweb就完了。

如果没有那些lisp macro，他的脑栈会不会已经爆了？

OwnWaterloo

回复 124# KanonInD

应该是我记错了。即使有文章比较haskell与C时，mergesort内部使用了filter，也应该是作者将merge与quick弄混了。

将121楼里的mergesort改为quicksort，或者将filter改为split什么的。
"haskell的那些文章使用了一些标准函数，但作为对比的C/C++版本手工实现并算在总行数内"这点依然没变……

starwing83

有一件事必须要说明：分工在接口清晰的前提下是比较容易无代价实现的——我现在的项目就已经被划分为好几个完全不相干的部分了，以纯c接口连接

OwnWaterloo

回复 127# starwing83

"分工在接口清晰的前提下"这个前提本身又容易达成么？

KanonInD

回复 125# OwnWaterloo

如果没有那些lisp macro，他的脑栈会不会已经爆了？

那是因为“人(们)不会用会爆自己脑栈的方式coding”这个假设成立了，至少暂时成立了，有点"理性人假设"的味道。

OwnWaterloo

回复 129# KanonInD

且别说lisp/haskell…… 就是C++，这个假设不成立也得完蛋……