“泛”还是“专”
142 views
Skip to first unread message
Albert
Nov 18, 2008, 10:25:49 AM11/18/08
to TopLanguage, pon...@googlegroups.com
其实这个问题很早就有了，单单对于编程序而言，你是钻透一门编程语言呢？还是做个泛泛的手册派，遇到问题查一把手册，然后Luckily把问题
FIX掉。
我应该是属于MANUAL派的，因为我没有深入的学习任何编程语言，除了C，C++花的时间多一点之外。于是很多时候解决一个简单的问题，看一把
MANUAL大部分问题也就随之而去了。但是最近我开始思考这样的一个问题：对于一项新的技术例如说CUDA，我总共在上面要解决N个问题，如果我没有
仔细的去学过，记学习代价T=0，此时解决一个问题的代价MT，那么总共花掉的时间是N*MT；与此同时如果我仔细的学习CUDA，花学习代价
T=100(例如），解决每一个问题的时间就大大的缩减了记MT'，此时总共的代价就是T+N*MT'；这两者如何去权衡
当然这是简化的模型，推而广之，在仔细学习一门课程的时候搜集资料，也要花去相当一部分时间HT，还有很多很多要考虑的
FIX掉。
我应该是属于MANUAL派的，因为我没有深入的学习任何编程语言，除了C，C++花的时间多一点之外。于是很多时候解决一个简单的问题，看一把
MANUAL大部分问题也就随之而去了。但是最近我开始思考这样的一个问题：对于一项新的技术例如说CUDA，我总共在上面要解决N个问题，如果我没有
仔细的去学过，记学习代价T=0，此时解决一个问题的代价MT，那么总共花掉的时间是N*MT；与此同时如果我仔细的学习CUDA，花学习代价
T=100(例如），解决每一个问题的时间就大大的缩减了记MT'，此时总共的代价就是T+N*MT'；这两者如何去权衡
当然这是简化的模型，推而广之，在仔细学习一门课程的时候搜集资料，也要花去相当一部分时间HT，还有很多很多要考虑的
当然还可以推广，比如说，在知识爆炸的几年，如何去权衡学习什么样的知识，以及什么样的知识应该学到什么样的程度，这样的模型该怎么建，该怎么分析，
该怎么求解
欢迎大家讨论，PONGBA期待你的回复
Message has been deleted
coolspeed
Nov 18, 2008, 12:50:38 PM11/18/08
to TopLanguage
又一位pongba粉丝？呵呵。
在面积/(体积？)一定时（人的精力极限是常量，right?），广度与深度是一对矛盾。有些环境会生长出"扁平"的，有些地方长出"瘦高"的。当然还
有均匀的。深度"深"在哪儿也是各有不同的。当然偶有一些知识/技能是具有杠杆性的，比较难统计，可以不论。这是生物多样性的问题了，一些生物生存的法
宝是低耗散，有的是大体积强攻击大食量。在社会学当中关于人的社会分工的理论还是比较完整的。
我们很容易得出的结论是最需要学什么的时候学什么。也就是尽量严格贴合环境表面形态----环境对存在(Being）作用的又一体现。如果中国突然很多人开
始学起阿拉伯语了，那肯定是国际上有什么大事了，你说是吗？
在面积/(体积？)一定时（人的精力极限是常量，right?），广度与深度是一对矛盾。有些环境会生长出"扁平"的，有些地方长出"瘦高"的。当然还
有均匀的。深度"深"在哪儿也是各有不同的。当然偶有一些知识/技能是具有杠杆性的，比较难统计，可以不论。这是生物多样性的问题了，一些生物生存的法
宝是低耗散，有的是大体积强攻击大食量。在社会学当中关于人的社会分工的理论还是比较完整的。
我们很容易得出的结论是最需要学什么的时候学什么。也就是尽量严格贴合环境表面形态----环境对存在(Being）作用的又一体现。如果中国突然很多人开
始学起阿拉伯语了，那肯定是国际上有什么大事了，你说是吗？
提到知识暴炸，我总是情不自禁地要提人工智能。我想没其它方法可以扼制知识爆炸带来的结果中不良因素了。记得《黑客帝国》里面载入骑模托车的模块后那一
段经典的追车场面吗？但是人对"黑盒"的知识是排斥的，怎么解决这是个大问题呀。
战斗暴龙
Nov 18, 2008, 8:02:47 PM11/18/08
to TopLanguage
总是有一部分人需要专，也总是有一部分人需要泛。
人各有志，社会也需要各种各样的人。
人各有志，社会也需要各种各样的人。
但是对于编程这个问题，我觉得，编程思想是针对编程而言的，并非针对编程语言。
所以一门编程语言再精通，也不可能让你真正领悟编程的全部，Unix平台推荐混合编程，对于特定的问题领域，用最擅长该领域的语言来解决总不是什么坏
事。
我也是一个Manual派的人，并且在这个时代，能够快速找到解决问题的方法比其在大脑中搜索已有解并加工要好得多。
不知道这位朋友所说的深入学习编程语言是指什么，从你说得翻手册来看，似乎你所说的深入就是指熟练工，精通大多数的api调用。如果是这样的话，我觉得
你对"深入"本身考虑的就不在点上，上面提到编程思想是针对编程而不是编程语言，但是编程语言做为编程的切入点自然也有其思想的体现，这便是语言本身的
特性、优点和缺点。另一方面，精通编程还应当包含精通其所面向的领域问题，比如精通java不等于精通javaee，因为你可能没有任何企业级的开发经
验。
如果要建立模型的话，此问题涉及到的不确定因素太多，呵呵，但愿上面的话能对你有所帮助。
On 11月18日, 下午11时25分, Albert <zinki...@gmail.com> wrote:
谷祖超
Nov 18, 2008, 8:24:47 PM11/18/08
to pon...@googlegroups.com
up duan
Nov 18, 2008, 8:54:08 PM11/18/08
to pon...@googlegroups.com
居振梁
Nov 18, 2008, 9:02:16 PM11/18/08
to pon...@googlegroups.com
深度达到一定程度就会发现，它其实还是依赖于广度的，知识本身就是一个大得整体，终点是哲学，之所以广，是因为有人把深度根据其抽象层次和问题领域进行了细分。追求稳定的人，专一点没关系，但是如果只是专的话，很难有跟深的突破。相反，一味的广，却很可能使得深度的增加，思路开阔了，即便某个广度自己没有深入下去，但是实际上已经在不知不觉中领悟了它了，这是需要做的事唤醒那部分并为其他需要的领域来服务。
2008/11/19 谷祖超 <gzc...@gmail.com>
Rui
Nov 18, 2008, 9:52:47 PM11/18/08
to TopLanguage
我觉得这事关键是语言为人所用，而不是人为语言奴役。
实际上软件行业真正革命性的变化并不多，很多所谓的新东西你看到时都会感觉到似曾相识。所以我不认为专与泛有什么矛盾的地方。
当然，就实际应用而言，程序员应该先专后泛，架构师则多数是先泛后专（我不是说全部）。
实际上软件行业真正革命性的变化并不多，很多所谓的新东西你看到时都会感觉到似曾相识。所以我不认为专与泛有什么矛盾的地方。
当然，就实际应用而言，程序员应该先专后泛，架构师则多数是先泛后专（我不是说全部）。
On 11月18日, 下午11时25分, Albert <zinki...@gmail.com> wrote:
pongba
Nov 19, 2008, 12:41:13 AM11/19/08
to pon...@googlegroups.com
我总是喜欢把知识分为essential的和non-essential的。对于前者采取深入掌握牢靠的办法，对于后者采取RTM (Read the f*cking manual)方法。
如何区分essential和non-essential的知识想必绝大多数时候大家心里都有数，我举几个例子：对程序员来说，硬件体系结构是essential的，操作系统实现机制是essential的，主流编程范式（OO、FP）是为了满足什么需求出现的（出现是为了解决什么问题），是怎么解决的，自身又引入了哪些新的问题，从而适用哪些场景）。。 这些我认为都是essential的。我想补充一点的是，并不是说硬件体系结构就要了解到逻辑门、晶体管层面才行（其实要了解到这个层面代价也很小，一两本好书就行了），也并不是说就要通读《Computer Architecture: Quantitative Approach》才行。而是关键要了解那些重要的思想，以及重要的细节，如：中断、陷阱机制属于前者，而具体设备的中断控制器的缓存大小则是后者（除非是搞单片机的:)），《Computer.Systems.A.Programmers.Perspective》就是为此目的，针对程序员的需求总结出那些essential knowledge的好书。
再来说一下为什么需要预先牢靠掌握这些essential的知识，因为3点：
1. 根据Joel Spolsky同学的说法（原文），编程语言技术是对底层设备的封装，然而封装总是会出现漏洞的，于是程序员被迫下到"下水道"当中去解决问题，一旦往下走，漂亮的OO，N层抽象就不复存在了，这时候不具备坚硬的底层知识就会无法解决问题。简而言之就是这些知识会无可避免的需要用到，既然肯定会被用到那还是预先掌握的好，否则用到的时候再查是来不及的，因为essential的知识也往往正是那些需要较长时间消化掌握的东西，不像Ruby的mixin或closure这种翻一下manual就能掌握的东西。（英语也是这样的essential knowledge——上次在PyCN上看到一个招Python开发人员的帖子将英语列为必备技能，却并不将自然语言处理列为必备技能，正是因为英语不是可以临阵磨枪的东西，而且作为知识的主要载体，任何时候都少不了它）
2. 如果你不知道某个工具的存在，遇到问题的时候是很难想到需要使用这么样一个工具的，essential knowldge就是使用最为广泛的工具，编程当中遇到某些问题之后，如果缺乏底层知识，你甚至都不知道需要去补充哪些底层知识才能解决这个问题。
3. 你必须首先熟悉你的工具，才能有效地使用它。一门语言，你必须了解它的适用场景，不适用场景。你必须了解它支持的主要编程范式，此外你还必须了解它的traps和pitfalls（缺陷和陷阱），这些都是essential knowledge，如果不事先掌握，指望用的时候查manual，是很浪费时间的，而且正如第2点所说，正因为你不知道这些知识（如适用场景），从而用sub-optimal的方式使用了一门语言自己还不知道（因为人的评价标准是：只要解决了最醒目的问题（functionality）就行）；类似，如果不知道陷阱的存在，掉进去也不知道怎么掉的。注意，熟悉并非熟悉所有细节，而是那些重要的，或者无法在需要用到的时候按需查找的知识。比如我上面提到的：适用场景不适用场景，编程范式，主要语言特性，缺陷和陷阱。
还有一些我认为是essential knowledge的例子：分析问题解决问题的思维方法（这个东西很难读一两本书就掌握，需要很长时间的锻炼和反思）、判断与决策的方法（生活中需要进行判断与决策的地方远远多于我们的想象，忘了是哪个说的了：Life is Problem-Solving。而判断与决策又是其中最常见的一类Problem Solving。尽管生活中面临重大决策的时候并不多，但另一方面我们时时刻刻都在进行最重大的决策：如：决定自己的日常时间到底投入到什么地方去。如：你能想象有人宁可天天花时间剪报纸上的优惠券，却对于房价的1%的优惠无动于衷吗？（《别做正常的傻瓜》、《Predictably Irrational》）如：你知道为什么当手头股票的股价不可抑止地滑向深渊时我们却一边揪着头发一边愣是不肯撤出吗？（是的，我们适应远古时代的心理机制根本不适应金融市场。）糟糕的判断与决策令我们的生活变得糟糕，这还不是最关键的，最关键的是我们从来不会去question自己的判断，而是总是能"找到"其他理由（《错不在我（Mistakes were made, but not by me）》）又，现在是一个信息泛滥的时代，于是另一个问题也出现：如何在海洋中有效筛选"好"的信息，以及避免被不好的信息左右我们的大脑。（Critical Thinking）
写得匆忙，先写这些:)
--
刘未鹏(pongba)
Blog|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba
Twitter
http://twitter.com/pongba
Delicious
http://delicious.com/pongba
Douban
http://www.douban.com/people/pongba/
如何区分essential和non-essential的知识想必绝大多数时候大家心里都有数，我举几个例子：对程序员来说，硬件体系结构是essential的，操作系统实现机制是essential的，主流编程范式（OO、FP）是为了满足什么需求出现的（出现是为了解决什么问题），是怎么解决的，自身又引入了哪些新的问题，从而适用哪些场景）。。 这些我认为都是essential的。我想补充一点的是，并不是说硬件体系结构就要了解到逻辑门、晶体管层面才行（其实要了解到这个层面代价也很小，一两本好书就行了），也并不是说就要通读《Computer Architecture: Quantitative Approach》才行。而是关键要了解那些重要的思想，以及重要的细节，如：中断、陷阱机制属于前者，而具体设备的中断控制器的缓存大小则是后者（除非是搞单片机的:)），《Computer.Systems.A.Programmers.Perspective》就是为此目的，针对程序员的需求总结出那些essential knowledge的好书。
再来说一下为什么需要预先牢靠掌握这些essential的知识，因为3点：
1. 根据Joel Spolsky同学的说法（原文），编程语言技术是对底层设备的封装，然而封装总是会出现漏洞的，于是程序员被迫下到"下水道"当中去解决问题，一旦往下走，漂亮的OO，N层抽象就不复存在了，这时候不具备坚硬的底层知识就会无法解决问题。简而言之就是这些知识会无可避免的需要用到，既然肯定会被用到那还是预先掌握的好，否则用到的时候再查是来不及的，因为essential的知识也往往正是那些需要较长时间消化掌握的东西，不像Ruby的mixin或closure这种翻一下manual就能掌握的东西。（英语也是这样的essential knowledge——上次在PyCN上看到一个招Python开发人员的帖子将英语列为必备技能，却并不将自然语言处理列为必备技能，正是因为英语不是可以临阵磨枪的东西，而且作为知识的主要载体，任何时候都少不了它）
2. 如果你不知道某个工具的存在，遇到问题的时候是很难想到需要使用这么样一个工具的，essential knowldge就是使用最为广泛的工具，编程当中遇到某些问题之后，如果缺乏底层知识，你甚至都不知道需要去补充哪些底层知识才能解决这个问题。
3. 你必须首先熟悉你的工具，才能有效地使用它。一门语言，你必须了解它的适用场景，不适用场景。你必须了解它支持的主要编程范式，此外你还必须了解它的traps和pitfalls（缺陷和陷阱），这些都是essential knowledge，如果不事先掌握，指望用的时候查manual，是很浪费时间的，而且正如第2点所说，正因为你不知道这些知识（如适用场景），从而用sub-optimal的方式使用了一门语言自己还不知道（因为人的评价标准是：只要解决了最醒目的问题（functionality）就行）；类似，如果不知道陷阱的存在，掉进去也不知道怎么掉的。注意，熟悉并非熟悉所有细节，而是那些重要的，或者无法在需要用到的时候按需查找的知识。比如我上面提到的：适用场景不适用场景，编程范式，主要语言特性，缺陷和陷阱。
还有一些我认为是essential knowledge的例子：分析问题解决问题的思维方法（这个东西很难读一两本书就掌握，需要很长时间的锻炼和反思）、判断与决策的方法（生活中需要进行判断与决策的地方远远多于我们的想象，忘了是哪个说的了：Life is Problem-Solving。而判断与决策又是其中最常见的一类Problem Solving。尽管生活中面临重大决策的时候并不多，但另一方面我们时时刻刻都在进行最重大的决策：如：决定自己的日常时间到底投入到什么地方去。如：你能想象有人宁可天天花时间剪报纸上的优惠券，却对于房价的1%的优惠无动于衷吗？（《别做正常的傻瓜》、《Predictably Irrational》）如：你知道为什么当手头股票的股价不可抑止地滑向深渊时我们却一边揪着头发一边愣是不肯撤出吗？（是的，我们适应远古时代的心理机制根本不适应金融市场。）糟糕的判断与决策令我们的生活变得糟糕，这还不是最关键的，最关键的是我们从来不会去question自己的判断，而是总是能"找到"其他理由（《错不在我（Mistakes were made, but not by me）》）又，现在是一个信息泛滥的时代，于是另一个问题也出现：如何在海洋中有效筛选"好"的信息，以及避免被不好的信息左右我们的大脑。（Critical Thinking）
写得匆忙，先写这些:)
2008/11/18 Albert <zink...@gmail.com>
--
刘未鹏(pongba)
Blog|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba
http://twitter.com/pongba
Delicious
http://delicious.com/pongba
Douban
http://www.douban.com/people/pongba/
coolspeed
Nov 19, 2008, 9:35:02 AM11/19/08
to TopLanguage
好思路。
对于人，增加广度对增加深度有时非常有帮助，正是基于这个道理。
但有时增加深度对增加广度也有帮助。
原因是，人不是对集合元素穷举（当然形式系统也不是，根据哥德尔定理），也就没有"增加广度是增加深度的唯一办法"这一道理了。
对于人，增加广度对增加深度有时非常有帮助，正是基于这个道理。
但有时增加深度对增加广度也有帮助。
原因是，人不是对集合元素穷举（当然形式系统也不是，根据哥德尔定理），也就没有"增加广度是增加深度的唯一办法"这一道理了。
On 11月19日, 上午9时54分, "up duan" <fixo...@gmail.com> wrote:
> 在形式系统中，增加广度是增加深度的唯一办法，不知道对于人的认知来说，是不是也有类似的地方？
>
> 2008/11/19 谷祖超 <gzc9...@gmail.com>
>
> > 把视界转90度再看广度和深度？
>
> > 2008/11/19 战斗暴龙 <Yoshua.Este...@gmail.com>
lunar_lty
Nov 19, 2008, 10:33:11 AM11/19/08
to TopLanguage
> > > 优化无极限。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
楼上有位兄台说得不错，社会上的确需要求深的人，也需要求广的人。
深和广本来就是对立统一的.学得广，可以开阔眼界，将这些知识整理起来，经过自己的抽象，就变得深了。
学得深，到一定程度时，随着"深知识"的不断深入和增加，必然会向广度发展，只是这个广度被限制在你所专攻的知识上了。
up duan
Nov 19, 2008, 10:42:14 AM11/19/08
to pon...@googlegroups.com
我倒是觉得深而后广不会限制广度。只要你足够深，所谓条条大路通罗马，每一个路途最终都能到山顶【似乎有点一理通，百理通的架势：）】。
当然，上面的说法只是一个比较牵强的比喻，我承认起点不同最后走过的地面也不同，就算我们足够努力去遍历也不同，但是，深仍然是到达广的一种手段。正如同广也是到达深的一种手段一样。
很难想像一个一流的经济学家对政治的了解比普通人差。
当然，上面的说法只是一个比较牵强的比喻，我承认起点不同最后走过的地面也不同，就算我们足够努力去遍历也不同，但是，深仍然是到达广的一种手段。正如同广也是到达深的一种手段一样。
很难想像一个一流的经济学家对政治的了解比普通人差。
2008/11/19 lunar_lty <peng...@126.com>
庆亮
Nov 19, 2008, 12:50:31 PM11/19/08
to pon...@googlegroups.com
引用up duan : 只要你足够深，所谓条条大路通罗马 ...很难想像一个一流的经济学家对政治的了解比普通人差...
一个一流的经济学家的政治一般是不会比普通人差, 但是在这里, 经济学家应该和一个政治家对比,而不是普通人.这个例子是错误的.
一个优秀的软件工程师可以熟悉数门语言和相关技术,理解各种类型语言和技术的利与弊, 从这一点上来说的确是"通罗马",但是如果要求他使用一种了解但不熟悉的语言, 并不见得一定是胜任的. 诚然,中国有一通则百通的说法, 但这应该是指思维层级上, 对于诸多事物都有一个高层次的把握., 对细节依然是不能把握.
广度和深度是一种方法,一种形式,从根本上来说,学习的出发点还是是否需要,是否必要,是否想要.
是否需要:某些东西学好了可以, 学的一般也可以.那么就是一种需要.
是否必要:一个东西如果不学则无法完成任务,则属于必要.
是否想要:不一定建立在任务的基础,可以纯粹是一种兴趣.自己也不知道将来是否有用.
为什么我这样分. 因为楼主所说的学到什么程度是一个和个人相关的问题.
对于"需要的技术",你可以学也可以不学.完全取决于你做事的态度.
对于必要的,没话说,只能学.
对于"想要的",那么就不存在到什么程度的问题,并非学每样东西一定要有目的,并非学每样东西一定要有用途.这样情况下的学习,唯心而已.
居振梁
Nov 19, 2008, 7:23:17 PM11/19/08
to pon...@googlegroups.com
逻辑性太强的思维反而容易被条条框框束缚，又是确实需要一些天马行空的尝试
up duan
Nov 19, 2008, 8:25:27 PM11/19/08
to pon...@googlegroups.com
逻辑跟思维限制没有任何关系。逻辑研究思维的形式，所以不会牵扯到太强就对思维的实质产生某种影响云云……
相反，我觉得逻辑性会导致我们能够相对全方位的看一件事物，因为形式全备，只需要代换其中的变量就可以尝试不同的思考事理。
相反，我觉得逻辑性会导致我们能够相对全方位的看一件事物，因为形式全备，只需要代换其中的变量就可以尝试不同的思考事理。
2008/11/20 居振梁 <yoshua....@gmail.com>
战斗暴龙
Nov 19, 2008, 8:59:17 PM11/19/08
to pon...@googlegroups.com
庆亮
Nov 20, 2008, 2:00:15 AM11/20/08
to pon...@googlegroups.com
这本身就是一个无法解决的问题,所以也就不存在一个完美的答案.
每个人对同一事物,同一思想等等的理解都是不同的, 和他本身的性格,周围的环境以及成长过程都有密切的关系. 所以思维和逻辑是否有影响还是看个人, 众多的科学施加的对象是多样的人类, 所以并不存在一种绝对的说法或理论.
有句话:成功不可学. 所以一切都应作为参考, 自己根据实际去判断自己如何去行动. 那么如何"根据实际"又是一个思维的过程.从而我们所有的一切问题都最终归结为不断的思维和从现实中反思的过程.
不知道自己学到什么程度为好, 可以周期性的进行反思, 结合其他作为参考, 最终形成自己的判断.
--
生命的意义在于不断的追求与学习.
Blog:www.nd21.com
Reply all
Reply to author
Forward
0 new messages