转：《计算机科学必读经典》
7 views
Skip to first unread message
pongba
Apr 10, 2008, 1:47:30 AM4/10/08
to TopLanguage
问学计算机科学要读什么书的，移驾：http://blog.youxu.info/2008/04/09/classics-in-cs/
--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba
--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba
alai
Apr 10, 2008, 2:11:46 AM4/10/08
to pon...@googlegroups.com
看过这篇BLOG，觉得LZ太强了，佩服佩服！开始刚看A类"基础"的时候，以为LZ把TAOCP都列为基础读物，实在太牛了，后来再看到B类、C类，才明白LZ的分类方法，所谓"基础"不是指基础读物，而是计算机理论基础的意思。
在 08-4-10，pongba<pon...@gmail.com> 写道：
Eli
Apr 18, 2008, 7:45:40 AM4/18/08
to TopLanguage
感觉太机械了， 现在大家都喜欢搞这种指南， 而人和人需要的学习过程是不同的。
我觉得我最后悔买的书之一就有TAOCP， 高老爷子是了不起， 但是对大多数人不会有啥帮助。说的在叛逆一点， 高老爷子现在的水平放在当今计算机领
域， 由于关注的重点不同了， 也就是大学教授的顶尖水平。 TAOCP也就是比大学教科书更好一点的水平。 真是搞相关那些方面的， TAOCP不过
是个入门读物， 对牛人没啥帮助； 可鸡肋就鸡肋在， 对于一般人， 尤其是工作方向已经比较确定的， 很多地方又用不上。 Gates这样的当年的小
菜(更何况现在的主要矛盾也不同了)， 可能确实做过里面的题； 可是对于John Carmack这样的程序员， 恐怕就是买了这种书也没时间翻上一
翻。
Introduce to Algorithm足够了。 然后做哪方面工作的， 在自己的领域中找专精的书和论文读读就可以了。
还有你翻译的那本《修改代码的艺术》， 作者整个是个糊里糊涂的家伙， 以后千万别再接这种作者的东西了。 他们老板那本书， 对面向对象感兴趣的倒是
都应该读一读。 对了， 你翻译的那个《代码之美》怎么还见不到啊， 一直是预定中....
SICP确实每个人都应该看， 但是最好最先看， 很多人我觉得， 学了命令式以后， 简直看也白看。 我自己算是有点体会的， 但是脑子里想问题也总
是有裂痕。
我觉得我最后悔买的书之一就有TAOCP， 高老爷子是了不起， 但是对大多数人不会有啥帮助。说的在叛逆一点， 高老爷子现在的水平放在当今计算机领
域， 由于关注的重点不同了， 也就是大学教授的顶尖水平。 TAOCP也就是比大学教科书更好一点的水平。 真是搞相关那些方面的， TAOCP不过
是个入门读物， 对牛人没啥帮助； 可鸡肋就鸡肋在， 对于一般人， 尤其是工作方向已经比较确定的， 很多地方又用不上。 Gates这样的当年的小
菜(更何况现在的主要矛盾也不同了)， 可能确实做过里面的题； 可是对于John Carmack这样的程序员， 恐怕就是买了这种书也没时间翻上一
翻。
Introduce to Algorithm足够了。 然后做哪方面工作的， 在自己的领域中找专精的书和论文读读就可以了。
还有你翻译的那本《修改代码的艺术》， 作者整个是个糊里糊涂的家伙， 以后千万别再接这种作者的东西了。 他们老板那本书， 对面向对象感兴趣的倒是
都应该读一读。 对了， 你翻译的那个《代码之美》怎么还见不到啊， 一直是预定中....
SICP确实每个人都应该看， 但是最好最先看， 很多人我觉得， 学了命令式以后， 简直看也白看。 我自己算是有点体会的， 但是脑子里想问题也总
是有裂痕。
图灵刘江
Apr 19, 2008, 12:33:11 PM4/19/08
to TopLanguage
Eli同学太强悍了。估计会遭口水。
修改代码那本书我看各位大佬评价都很高，自己看了看，内容不简单，此前没有
什么人谈过这一主题，才选着出的。光凭原书的名字，没有人敢做的。
作者糊里糊涂么？证据在哪里？他也是代码之美一书的作者之一，第6章。
修改代码那本书我看各位大佬评价都很高，自己看了看，内容不简单，此前没有
什么人谈过这一主题，才选着出的。光凭原书的名字，没有人敢做的。
作者糊里糊涂么？证据在哪里？他也是代码之美一书的作者之一，第6章。
Eli
Apr 19, 2008, 9:28:26 PM4/19/08
to TopLanguage
他的主题选的确实挺好的， 也挖掘了一些问题， 不过我不知道他是推广自己的理念或自己公司的解决方案呢， 还是偏执狂， 很多说法简直就是不经大脑
的。
比如“运行的不快的不是单元测试”， 有这么武断的么？ 假设一个算法耗时3分钟， 而且没法再分割成更小的单元了， 那么针对它的测试是什么测试？
比如此人在中间提到， 对默认的构造函数也要写一个测试， 虽然他自己最后也会把这种没意义的测试再去掉。 怎么说呢， 整个一某种方法论的极端分子和
狂人。
这种东西还有很多， 让自己的偏见和喜好贯穿全书， 这个是非常要不得的。 不是说此人没能耐， 而是此人的能耐不适合写书...
当然， 如果无条件相信他的理念全都是对的， 那对这本书的评价自然就不同了。 McConnell对很多绝对的说法怎么说来着？ 比我可难听多了。
的。
比如“运行的不快的不是单元测试”， 有这么武断的么？ 假设一个算法耗时3分钟， 而且没法再分割成更小的单元了， 那么针对它的测试是什么测试？
比如此人在中间提到， 对默认的构造函数也要写一个测试， 虽然他自己最后也会把这种没意义的测试再去掉。 怎么说呢， 整个一某种方法论的极端分子和
狂人。
这种东西还有很多， 让自己的偏见和喜好贯穿全书， 这个是非常要不得的。 不是说此人没能耐， 而是此人的能耐不适合写书...
当然， 如果无条件相信他的理念全都是对的， 那对这本书的评价自然就不同了。 McConnell对很多绝对的说法怎么说来着？ 比我可难听多了。
pongba
Apr 19, 2008, 11:31:09 PM4/19/08
to pon...@googlegroups.com
2008/4/18 Eli <Eli...@gmail.com>:
对了， 你翻译的那个《代码之美》怎么还见不到啊， 一直是预定中....
稿子早就完工了，出版环节遇到一些问题，在和Oreilly那边沟通呢，好事多磨，唉。。
dreamhead
Apr 20, 2008, 11:38:02 AM4/20/08
to pon...@googlegroups.com
关于单元测试，我宁愿站在作者这边。在敏捷软件开发的理念中，需要的是快速反馈。3分钟的单元测试，就会让人倾向于不运行这个测试。
换个角度说，运行3分钟，而且不可再分的测试，绝大多数情况是有问题的。至少从我的开发实践中，我是没有见到过的。通常出现运行测试时间比较长，都是因为代码耦合度很大。
即便是一个算法，从实现的角度而言，通常也是可以分为几个部分，我们可以针对每个部分进行测试。所谓单元测试，测的应该是单元，而非把所有的部分放在一起，那便成了集成测试。
这本书，我是通读过的。全书所体现的理念，主要是针对遗留代码进行处理的，所以，很多时候，手法并不那么优雅，但实际经验告诉我们，能做到那样已经很不容易了。
我很欣赏你抱着怀疑的态度来读书，但从你对作者的批判来看，可能是你并没有很好理解作者的意图。
在 08-4-20，Eli<Eli...@gmail.com> 写道：
--
Everything is simple!
Dr. Kaynes
Apr 20, 2008, 2:57:57 PM4/20/08
to TopLanguage
关于单元测试我也觉得Eli举的例子过于特殊，其实大部分单元测试都可以也应该在一个很短的时间内完成。
而关于作者的"偏执"，我倒觉得虽然有时候一些做法看起来很繁琐，但是至少可以保证整个过程是"小而稳"的。可能在短期内这样做好像显得效率底下，但是
从长远上看这些做法可以避免很多"意想不到"的事情，从而真正保证了效率。
其实这本书还真的挺实用的，里面的很多方法都让我有相见恨晚的感觉。不过也不能说就无条件接受他的观点了，事实上对于每一个作者我们都不应该无条件接受
他们的观点。
On Apr 20, 11:38 pm, dreamhead <dreamhead...@gmail.com> wrote:
> 关于单元测试，我宁愿站在作者这边。在敏捷软件开发的理念中，需要的是快速反馈。3分钟的单元测试，就会让人倾向于不运行这个测试。
>
> 换个角度说，运行3分钟，而且不可再分的测试，绝大多数情况是有问题的。至少从我的开发实践中，我是没有见到过的。通常出现运行测试时间比较长，都是因为代码耦-合度很大。
>
> 即便是一个算法，从实现的角度而言，通常也是可以分为几个部分，我们可以针对每个部分进行测试。所谓单元测试，测的应该是单元，而非把所有的部分放在一起，那便-成了集成测试。
>
> - Show quoted text -
而关于作者的"偏执"，我倒觉得虽然有时候一些做法看起来很繁琐，但是至少可以保证整个过程是"小而稳"的。可能在短期内这样做好像显得效率底下，但是
从长远上看这些做法可以避免很多"意想不到"的事情，从而真正保证了效率。
其实这本书还真的挺实用的，里面的很多方法都让我有相见恨晚的感觉。不过也不能说就无条件接受他的观点了，事实上对于每一个作者我们都不应该无条件接受
他们的观点。
On Apr 20, 11:38 pm, dreamhead <dreamhead...@gmail.com> wrote:
> 关于单元测试，我宁愿站在作者这边。在敏捷软件开发的理念中，需要的是快速反馈。3分钟的单元测试，就会让人倾向于不运行这个测试。
>
>
> 即便是一个算法，从实现的角度而言，通常也是可以分为几个部分，我们可以针对每个部分进行测试。所谓单元测试，测的应该是单元，而非把所有的部分放在一起，那便-成了集成测试。
>
> 这本书，我是通读过的。全书所体现的理念，主要是针对遗留代码进行处理的，所以，很多时候，手法并不那么优雅，但实际经验告诉我们，能做到那样已经很不容易了。
>
> 我很欣赏你抱着怀疑的态度来读书，但从你对作者的批判来看，可能是你并没有很好理解作者的意图。
>
> 在 08-4-20，Eli<Eli...@gmail.com> 写道：
>
>
>
>
>
> > 他的主题选的确实挺好的， 也挖掘了一些问题， 不过我不知道他是推广自己的理念或自己公司的解决方案呢， 还是偏执狂， 很多说法简直就是不经大脑
> > 的。
>
> > 比如"运行的不快的不是单元测试"， 有这么武断的么？ 假设一个算法耗时3分钟， 而且没法再分割成更小的单元了， 那么针对它的测试是什么测试？
>
> > 比如此人在中间提到， 对默认的构造函数也要写一个测试， 虽然他自己最后也会把这种没意义的测试再去掉。 怎么说呢， 整个一某种方法论的极端分子和
> > 狂人。
>
> > 这种东西还有很多， 让自己的偏见和喜好贯穿全书， 这个是非常要不得的。 不是说此人没能耐， 而是此人的能耐不适合写书...
>
> > 当然， 如果无条件相信他的理念全都是对的， 那对这本书的评价自然就不同了。 McConnell对很多绝对的说法怎么说来着？ 比我可难听多了。
>
> > On Apr 20, 12:33 am, 图灵刘江 <liuj.tur...@gmail.com> wrote:
> > > Eli同学太强悍了。估计会遭口水。
>
> > > 修改代码那本书我看各位大佬评价都很高，自己看了看，内容不简单，此前没有
> > > 什么人谈过这一主题，才选着出的。光凭原书的名字，没有人敢做的。
>
> > > 作者糊里糊涂么？证据在哪里？他也是代码之美一书的作者之一，第6章。
>
> > > On 4月18日, 下午7时45分, Eli <Eli...@gmail.com> wrote:
>
> > > > 还有你翻译的那本《修改代码的艺术》， 作者整个是个糊里糊涂的家伙， 以后千万别再接这种作者的东西了。 他们老板那本书， 对面向对象感兴趣的倒是
> > > > 都应该读一读。 对了， 你翻译的那个《代码之美》怎么还见不到啊， 一直是预定中....
>
> --
> Everything is simple!- Hide quoted text -
> 这本书，我是通读过的。全书所体现的理念，主要是针对遗留代码进行处理的，所以，很多时候，手法并不那么优雅，但实际经验告诉我们，能做到那样已经很不容易了。
>
> 我很欣赏你抱着怀疑的态度来读书，但从你对作者的批判来看，可能是你并没有很好理解作者的意图。
>
> 在 08-4-20，Eli<Eli...@gmail.com> 写道：
>
>
>
>
>
> > 他的主题选的确实挺好的， 也挖掘了一些问题， 不过我不知道他是推广自己的理念或自己公司的解决方案呢， 还是偏执狂， 很多说法简直就是不经大脑
> > 的。
>
> > 比如"运行的不快的不是单元测试"， 有这么武断的么？ 假设一个算法耗时3分钟， 而且没法再分割成更小的单元了， 那么针对它的测试是什么测试？
>
> > 比如此人在中间提到， 对默认的构造函数也要写一个测试， 虽然他自己最后也会把这种没意义的测试再去掉。 怎么说呢， 整个一某种方法论的极端分子和
> > 狂人。
>
> > 这种东西还有很多， 让自己的偏见和喜好贯穿全书， 这个是非常要不得的。 不是说此人没能耐， 而是此人的能耐不适合写书...
>
> > 当然， 如果无条件相信他的理念全都是对的， 那对这本书的评价自然就不同了。 McConnell对很多绝对的说法怎么说来着？ 比我可难听多了。
>
> > On Apr 20, 12:33 am, 图灵刘江 <liuj.tur...@gmail.com> wrote:
> > > Eli同学太强悍了。估计会遭口水。
>
> > > 修改代码那本书我看各位大佬评价都很高，自己看了看，内容不简单，此前没有
> > > 什么人谈过这一主题，才选着出的。光凭原书的名字，没有人敢做的。
>
> > > 作者糊里糊涂么？证据在哪里？他也是代码之美一书的作者之一，第6章。
>
> > > On 4月18日, 下午7时45分, Eli <Eli...@gmail.com> wrote:
>
> > > > 还有你翻译的那本《修改代码的艺术》， 作者整个是个糊里糊涂的家伙， 以后千万别再接这种作者的东西了。 他们老板那本书， 对面向对象感兴趣的倒是
> > > > 都应该读一读。 对了， 你翻译的那个《代码之美》怎么还见不到啊， 一直是预定中....
>
> --
>
> - Show quoted text -
chaosong fu
Apr 21, 2008, 2:44:15 AM4/21/08
to pon...@googlegroups.com
不敢认同这点，至少我还真没有见过能把 TAOCP 当成入门读物看的牛人。
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
说的在叛逆一点， 高老爷子现在的水平放在当今计算机领
域， 由于关注的重点不同了， 也就是大学教授的顶尖水平。 TAOCP也就是比大学教科书更好一点的水平。 真是搞相关那些方面的， TAOCP不过
是个入门读物， 对牛人没啥帮助
--
非常に、非常に強いよい、非常に調和した
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
说的在叛逆一点， 高老爷子现在的水平放在当今计算机领
域， 由于关注的重点不同了， 也就是大学教授的顶尖水平。 TAOCP也就是比大学教科书更好一点的水平。 真是搞相关那些方面的， TAOCP不过
是个入门读物， 对牛人没啥帮助
在08-4-21，Dr. Kaynes <hfe...@gmail.com> 写道：
--
非常に、非常に強いよい、非常に調和した
Eli
Apr 23, 2008, 3:48:18 AM4/23/08
to TopLanguage
这里没有宁愿不宁愿的问题， 只有严谨不严谨的问题。
“至少从我的开发实践中，我是没有见到过的。”
别说你没有见过， 我也不是说天天见， 但是你能说没有吗？ 再给定的输入上随便做点暴力的数学运算， 不超过几十行的Routine， 就可以达到这
种效果； 而如果你测试的时候， 必须包含一个足够复杂的输入， 怎么办？ 在这方面我也不是行家， 但是我觉得“是否存在”这一问题， 是可以直接推
断的。
“换个角度说，运行3分钟，而且不可再分的测试，绝大多数情况是有问题的。”
我并没有看见作者把极少数情况排除在外， 大家可以说我吹毛求疵， 但是并不代表作者不存在问题。
“通常出现运行测试时间比较长，都是因为代码耦 合度很大。 ”
“所谓单元测试，测的应该是单元，而非把所有的部分放在一起，那便 成了集成测试。 ”
这些话是苍白无力的， 因为我并没有把你说的出问题的情况， 或者本来应该定义为集成测试的情况非要当作单元测试， 用来挑作者的毛病； 我只是说，
至少我认为他的说法太过极端， 以至于我不得不降低对他的评价。 并且谨慎的对待他的很多类似的言论， 避免在获取知识的同时， 也吸收到有害物质。
“而关于作者的"偏执"，我倒觉得虽然有时候一些做法看起来很繁琐，但是至少可以保证整个过程是"小而稳"的。可能在短期内这样做好像显得效率底下，但
是
从长远上看这些做法可以避免很多"意想不到"的事情，从而真正保证了效率。 ”
这个道理从根本上讲是对的， 关键是我们有没有把“意想不到的事情”的范围无限扩大。 有关一个方法论其中的支撑点和基础认识是否超出了界限， 有时候
并不仅仅是一个短期的问题。
“事实上对于每一个作者我们都不应该无条件接受他们的观点。 ”
就是这个意思 :)， 只不过这本书比起比如他老板写的书， 至少对于我来说， 需要谨慎对待的地方多出太多了...
“至少从我的开发实践中，我是没有见到过的。”
别说你没有见过， 我也不是说天天见， 但是你能说没有吗？ 再给定的输入上随便做点暴力的数学运算， 不超过几十行的Routine， 就可以达到这
种效果； 而如果你测试的时候， 必须包含一个足够复杂的输入， 怎么办？ 在这方面我也不是行家， 但是我觉得“是否存在”这一问题， 是可以直接推
断的。
“换个角度说，运行3分钟，而且不可再分的测试，绝大多数情况是有问题的。”
我并没有看见作者把极少数情况排除在外， 大家可以说我吹毛求疵， 但是并不代表作者不存在问题。
“通常出现运行测试时间比较长，都是因为代码耦 合度很大。 ”
“所谓单元测试，测的应该是单元，而非把所有的部分放在一起，那便 成了集成测试。 ”
这些话是苍白无力的， 因为我并没有把你说的出问题的情况， 或者本来应该定义为集成测试的情况非要当作单元测试， 用来挑作者的毛病； 我只是说，
至少我认为他的说法太过极端， 以至于我不得不降低对他的评价。 并且谨慎的对待他的很多类似的言论， 避免在获取知识的同时， 也吸收到有害物质。
“而关于作者的"偏执"，我倒觉得虽然有时候一些做法看起来很繁琐，但是至少可以保证整个过程是"小而稳"的。可能在短期内这样做好像显得效率底下，但
是
从长远上看这些做法可以避免很多"意想不到"的事情，从而真正保证了效率。 ”
这个道理从根本上讲是对的， 关键是我们有没有把“意想不到的事情”的范围无限扩大。 有关一个方法论其中的支撑点和基础认识是否超出了界限， 有时候
并不仅仅是一个短期的问题。
“事实上对于每一个作者我们都不应该无条件接受他们的观点。 ”
就是这个意思 :)， 只不过这本书比起比如他老板写的书， 至少对于我来说， 需要谨慎对待的地方多出太多了...
Eli
Apr 23, 2008, 4:05:51 AM4/23/08
to TopLanguage
什么是牛人? :) 哪方面的牛人?
人家自己都说了， 属于参考手册和大学教材， 咱们却非要给他人为拔高。 其实确实， 包括我自己在内， 周围能把这些全都看懂， 尤其是能有耐心和能
力做完其中习题的， 几乎没有； 但是不找自身问题， 而把这本书捧到一个超过作者自己定位的水平， 无助于掩盖满世界不懂行的这一事实。关键是你我承
认不承认自己根本是外行？ 还有我们"不懂行"的原因是什么。
我个人认为这就在于我们， 还有我们的老板， 我们的客户， 关心的重点变了； 没有多少人"懂行"， 世界却照样转， 那么这些知识对于这些"不懂
行"的程序员， 到底价值几许？ 比如某数据库调优的牛人 他一定是TAOCP所关心的这些方面的牛人吗？ 如果不是， 他不能把TAOCP当入门读
物， 不是理所当然的吗？ 这是我们自身的问题， 只是这个问题由于我们的工作性质， 不那么突出和重要， 所以解决的价值也不大。
那么必须关心TAOCP所涉及的方面的"牛人"呢？ 他们还停留在大学教材的水平上， 足够称的上牛人吗？
其实这些都无所谓啦， 就是辩论一下。 关键是， 真的每一个从事计算机科学领域的细分领域的人， TAOCP都是必读吗？ 真的没有存在更大优先级的
读物了吗？ 或者干脆一点， 把那些不用关心TAOCP涉及领域的计算机相关知识， 都划到"计算机科学"之外算了。
On Apr 21, 2:44 pm, "chaosong fu" <pitt...@gmail.com> wrote:
> 不敢认同这点，至少我还真没有见过能把 TAOCP 当成入门读物看的牛人。
>
> /////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////
人家自己都说了， 属于参考手册和大学教材， 咱们却非要给他人为拔高。 其实确实， 包括我自己在内， 周围能把这些全都看懂， 尤其是能有耐心和能
力做完其中习题的， 几乎没有； 但是不找自身问题， 而把这本书捧到一个超过作者自己定位的水平， 无助于掩盖满世界不懂行的这一事实。关键是你我承
认不承认自己根本是外行？ 还有我们"不懂行"的原因是什么。
我个人认为这就在于我们， 还有我们的老板， 我们的客户， 关心的重点变了； 没有多少人"懂行"， 世界却照样转， 那么这些知识对于这些"不懂
行"的程序员， 到底价值几许？ 比如某数据库调优的牛人 他一定是TAOCP所关心的这些方面的牛人吗？ 如果不是， 他不能把TAOCP当入门读
物， 不是理所当然的吗？ 这是我们自身的问题， 只是这个问题由于我们的工作性质， 不那么突出和重要， 所以解决的价值也不大。
那么必须关心TAOCP所涉及的方面的"牛人"呢？ 他们还停留在大学教材的水平上， 足够称的上牛人吗？
其实这些都无所谓啦， 就是辩论一下。 关键是， 真的每一个从事计算机科学领域的细分领域的人， TAOCP都是必读吗？ 真的没有存在更大优先级的
读物了吗？ 或者干脆一点， 把那些不用关心TAOCP涉及领域的计算机相关知识， 都划到"计算机科学"之外算了。
On Apr 21, 2:44 pm, "chaosong fu" <pitt...@gmail.com> wrote:
> 不敢认同这点，至少我还真没有见过能把 TAOCP 当成入门读物看的牛人。
>
> /////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////
> 说的在叛逆一点， 高老爷子现在的水平放在当今计算机领
> 域， 由于关注的重点不同了， 也就是大学教授的顶尖水平。 TAOCP也就是比大学教科书更好一点的水平。 真是搞相关那些方面的， TAOCP不过
> 是个入门读物， 对牛人没啥帮助
>
> 在08-4-21，Dr. Kaynes <hfev...@gmail.com> 写道：
> 域， 由于关注的重点不同了， 也就是大学教授的顶尖水平。 TAOCP也就是比大学教科书更好一点的水平。 真是搞相关那些方面的， TAOCP不过
> 是个入门读物， 对牛人没啥帮助
>
Eli
Apr 23, 2008, 4:07:59 AM4/23/08
to TopLanguage
其实我定了一打子书， 就希望全了一块买呢， 结果一等就是两个月...
Eric
Apr 23, 2008, 12:11:42 PM4/23/08
to TopLanguage
大哥 你听说过 Tarjan 读了第一卷就拿图灵奖的故事么?
图灵刘江
Apr 23, 2008, 1:37:55 PM4/23/08
to TopLanguage
还真没听说过，说来听听？
图灵刘江
Apr 23, 2008, 1:38:55 PM4/23/08
to TopLanguage
Eli同学有时间可以写个评论性的文章，我们可以公布给读者。
思考和争鸣总是有意义的。
思考和争鸣总是有意义的。
Eli
Apr 23, 2008, 2:56:51 PM4/23/08
to TopLanguage
高斯8岁还怎么怎么着了呢...， 这恐怕只能说明这位仁兄牛吧..., 而且我似乎记得这个名字和高老爷子也或多或少有点联系？ 我不否认TAOCP
是很好的教材， 也绝对会有人适合并喜欢读这样的教材， 但是你让一个天天写最平凡的那种业务逻辑的老兄读它， 真的有必要么？ 况且Tarjan和大
多数程序员， 甚至大多数顶尖程序员在从事的工作上有多少相似性呢？
我也喜欢听传奇故事， 但是Tarjan的成就恐怕更多的在于他自己的灵感，天赋(其实这也是运气)， 努力。 说实在的， 你敢保证他不读TAOCP
就拿不到奖？ 相反， TAOCP的大多数读者不但与图灵奖无缘， 甚至也不是最好的程序员。 各有各的光环嘛， 高老爷子那么牛， 可他变牛之前，
也没上帝之音传授给他一整本TAOCP吧？
是很好的教材， 也绝对会有人适合并喜欢读这样的教材， 但是你让一个天天写最平凡的那种业务逻辑的老兄读它， 真的有必要么？ 况且Tarjan和大
多数程序员， 甚至大多数顶尖程序员在从事的工作上有多少相似性呢？
我也喜欢听传奇故事， 但是Tarjan的成就恐怕更多的在于他自己的灵感，天赋(其实这也是运气)， 努力。 说实在的， 你敢保证他不读TAOCP
就拿不到奖？ 相反， TAOCP的大多数读者不但与图灵奖无缘， 甚至也不是最好的程序员。 各有各的光环嘛， 高老爷子那么牛， 可他变牛之前，
也没上帝之音传授给他一整本TAOCP吧？
Eli
Apr 23, 2008, 2:58:17 PM4/23/08
to TopLanguage
呵呵， 贫贫嘴， 不登大雅之堂~， 书还是有用滴， 只是我不喜欢神话的说法和做法～
On Apr 24, 1:38 am, 图灵刘江 <liuj.tur...@gmail.com> wrote:
> Eli同学有时间可以写个评论性的文章，我们可以公布给读者。
> 思考和争鸣总是有意义的。
On Apr 24, 1:38 am, 图灵刘江 <liuj.tur...@gmail.com> wrote:
> Eli同学有时间可以写个评论性的文章，我们可以公布给读者。
> 思考和争鸣总是有意义的。
Dr. Kaynes
Apr 23, 2008, 3:30:51 PM4/23/08
to TopLanguage
"思考和争鸣总是有意义的"。完全如此。
且不说我同意不同意Eli的观点，一开始看到Eli的评论我还是很兴奋的。
读这本书的时候我正好要修改一个旧系统，都是抱着使用的态度看这本书。由于边看边做，书中的很多方法都可以有立竿见影的效果。不过在阅读之余也感慨作者
的的很多思想是我前所未见的，有时甚至是震撼性的。草草看完了这本书后，我一直很重看本书，着重整理一下阅读新的。不过这段时间比较忙一直抽不出空，看
到Eli的评价我顿时大喜，哈哈，可以趁机整理思路了----而且我一直相信从多种角度看待一本书反才能真正的让我们理解一本书。
当然我还是不能很同意Eli的话----就像Eli不应该全盘同意Michael Feathers的话一样，但是Eli说道的"偏执"问题其实也是我一直
在思考的问题。
比如大学时第一次看《重构》的时候非常不解，很多重构方式，是不是太那个什么了，你看为了去掉临时变量居然还要抽离函数？为了代码清晰，把一个循环里可
以做完的两件事愣是分成两个函数然后分别执行循环，好吗（我以前一个舍友看到这些的时候更是破口大骂：神经啊！）？
后来做了几个项目，再看此书当时就差点泪如泉涌，讲的真TMD有道理，为什么早没看到！的确，通过避免坏味道我可以大大改善软件结构。所以我真应该应该
把自己以前那些愚蠢的想法抛弃然后按照他的方式彻底的把系统改写一遍。
结果我这样做了吗？没有，原因是我觉得作者虽然有道理（可以说《重构》真正让我体验了代码之美）但是把当前系统全部重构成那种风格似乎有点太过了。当时
说不出为什么不应该全盘重构，但是"极端"这个词肯定藏在我的潜意识里。于是，我很矛盾，全重构吧，感觉没必要，不用吧，又觉得好像做一件偷鸡摸狗的事
情。
更后来呢，我才发现这种矛盾是可以协调的。一些原则啊，方法啊你大可同意之，然后使用之，但这不代表你必须在任何情况下都贯彻之。
Prefactor里面有句话可以概括我现在的观点：情境是一切！把一个原则脱离其使用环境加以讨论是毫无意义的，对于原则，我们要问的不是这个原则好
不好，而是我们在什么条件下应该使用这条原则，什么时候不应该使用这条原则。
从此我就彻底抛弃了自己的罪恶感，只要我觉得不适合，我就理直气壮的拒绝使用原则。
不过不得不说很多原则毕竟还是久经考验的，在我决定弃用这些原则前我必须认真斟酌不使用的理由，不然很容易陷入意想不到的问题之中而很难自拔。
所以呢，尽量以实用角度看待这些原则，这本书给我的教益颇多，但是最终还是要根据我自身情况调整为我的风格。我有时觉得读书就像吸血鬼吸血一样，我们唯
一的目的就是从这些猎物中汲取我们所需的营养，其余一切都是附加的，有个吸血鬼老大说过了：不要对你的猎物动情----即使动情了，也别忘了吸他的血，边吸
血边动情.后面这句是我加的。当然了，有很多猎物的血厚着呢，多吸几次也未必能全吸干净，这种猎物，狡猾着呢。
写完突然发现有点离题了,不列提纲的后果......
且不说我同意不同意Eli的观点，一开始看到Eli的评论我还是很兴奋的。
读这本书的时候我正好要修改一个旧系统，都是抱着使用的态度看这本书。由于边看边做，书中的很多方法都可以有立竿见影的效果。不过在阅读之余也感慨作者
的的很多思想是我前所未见的，有时甚至是震撼性的。草草看完了这本书后，我一直很重看本书，着重整理一下阅读新的。不过这段时间比较忙一直抽不出空，看
到Eli的评价我顿时大喜，哈哈，可以趁机整理思路了----而且我一直相信从多种角度看待一本书反才能真正的让我们理解一本书。
当然我还是不能很同意Eli的话----就像Eli不应该全盘同意Michael Feathers的话一样，但是Eli说道的"偏执"问题其实也是我一直
在思考的问题。
比如大学时第一次看《重构》的时候非常不解，很多重构方式，是不是太那个什么了，你看为了去掉临时变量居然还要抽离函数？为了代码清晰，把一个循环里可
以做完的两件事愣是分成两个函数然后分别执行循环，好吗（我以前一个舍友看到这些的时候更是破口大骂：神经啊！）？
后来做了几个项目，再看此书当时就差点泪如泉涌，讲的真TMD有道理，为什么早没看到！的确，通过避免坏味道我可以大大改善软件结构。所以我真应该应该
把自己以前那些愚蠢的想法抛弃然后按照他的方式彻底的把系统改写一遍。
结果我这样做了吗？没有，原因是我觉得作者虽然有道理（可以说《重构》真正让我体验了代码之美）但是把当前系统全部重构成那种风格似乎有点太过了。当时
说不出为什么不应该全盘重构，但是"极端"这个词肯定藏在我的潜意识里。于是，我很矛盾，全重构吧，感觉没必要，不用吧，又觉得好像做一件偷鸡摸狗的事
情。
更后来呢，我才发现这种矛盾是可以协调的。一些原则啊，方法啊你大可同意之，然后使用之，但这不代表你必须在任何情况下都贯彻之。
Prefactor里面有句话可以概括我现在的观点：情境是一切！把一个原则脱离其使用环境加以讨论是毫无意义的，对于原则，我们要问的不是这个原则好
不好，而是我们在什么条件下应该使用这条原则，什么时候不应该使用这条原则。
从此我就彻底抛弃了自己的罪恶感，只要我觉得不适合，我就理直气壮的拒绝使用原则。
不过不得不说很多原则毕竟还是久经考验的，在我决定弃用这些原则前我必须认真斟酌不使用的理由，不然很容易陷入意想不到的问题之中而很难自拔。
所以呢，尽量以实用角度看待这些原则，这本书给我的教益颇多，但是最终还是要根据我自身情况调整为我的风格。我有时觉得读书就像吸血鬼吸血一样，我们唯
一的目的就是从这些猎物中汲取我们所需的营养，其余一切都是附加的，有个吸血鬼老大说过了：不要对你的猎物动情----即使动情了，也别忘了吸他的血，边吸
血边动情.后面这句是我加的。当然了，有很多猎物的血厚着呢，多吸几次也未必能全吸干净，这种猎物，狡猾着呢。
写完突然发现有点离题了,不列提纲的后果......
Eric
Apr 23, 2008, 10:21:37 PM4/23/08
to TopLanguage
呵呵 我写文章的初衷，倒不是让"一个天天写最平凡的那种业务逻辑的老兄"读他。人各有志，对吧。
Yiming Zhang
Apr 24, 2008, 12:48:20 PM4/24/08
to pon...@googlegroups.com
|
谁能把这个thread的上下文转发给我吗，我想看看 |
Best Regards
Zhang Yiming
Reply all
Reply to author
Forward
0 new messages