上限

最近,我可能开始写一系列以知识为话题的东西,这些东西大而空泛,说起来也听没劲的。不过反正我的博客也没有读者,或者说是几乎没有,所以就这样吧,看能写一点是一点。这些内容可能从我写程序方面写写,可能从设计领域的东西写写,因为只有这么两个方面我自认为还不算特别特别的差,可以作为个不完全对照的分析吧。这些东西很多是不满的吐槽,也没怎么经过整理,也许以后有机会会整理成一个系列吧。

我很喜欢有上限的事情,尤其喜欢有上限的学习。

什么叫有上限的学习呢?这就是说,学到够用就好。像我们在实践当中的学习就属于是有上限的学习。譬如我造一点小程序,我比较喜欢使用已有的库,这样的话,我能很容易就理清自己要完成的东西的脉络。这也就意味着,我只要完成这一部分的东西就足够了,完成这一部分就能基本实现自己最初的想法。

要想能够「有上限地学习」大概首要条件是能够有需求。这样的需求,比如前面说的写程序就是一个,还有就是做实验,做实验的话我能搞清楚自己要做什么,能得到什么样的结果。这么个需求首先要让我自己相信我能够实现,第二呢,我也能比较容易根据现有知识理清自己的路径将会是怎么样的,剩下的就是自己学习,然后根据自己学习的东西实践出来就行了。

当然,做到这些还有一个条件,就是有足够好的技术资料。比如说吧,看一些东西,我比较希望能够有相对完善的中文或英文的 PDF 资料,最好还要是 LaTeX 编译成的,这是最顶上的层次;其次,如果网上的网页索引足够方便的话,也是可以的,比如 Python 的资料我都是直接利用网上的文档。文档内容的话,首先应该有个综合性的介绍(introduction),也就是讲讲这个东西是解决什么问题的,和前后的段落有什么样的关联,让我相信这个东西有用、而且能够搞清楚我需要关注的点在哪里,紧接着教程(tutorial)可以是解决一个大问题的一步,并说明白是哪一步,然后在读完教程之后,又有参考(reference)可以读,也就是说是可以快速翻阅的材料,这里电子材料就比较方便,因为这些内容是可搜索的,而一个关键字在一本书里面也出现不了几次。如果上面的那些条件不能得到满足,我就会在寻找参考材料上面兜圈子——要么是自己看着不爽看不下去了,要么就是自己不断找能够满足自己要求的材料,即使在计算机上这种情况我自己也是经常发生。1

另外一个条件就是足够便捷的纠错(debug)方法,即除错方法。像 Python 的交互终端(REPL, interactive shell)命令提示也是个好办法,出了问题他会自杀然后抛出错误类型,告诉你跑到什么地方了,然后给出调用堆栈,这方面 C/C++ 就不那么友好。经常是动不动就 Segment Fault,或者像前两天在 Windows 下调试程序,程序就在那儿挂着,很不方便,不过也可能是我具体的参数配置得不对,或者标准不太清楚的问题。

还有,我比较希望有足够的时间宽容度。不要总要求在什么时候把事情做完,这么个搞法不靠谱。一定的时间宽容度就意味着我能有机会真正地喜欢去做它,而不把它做成一个任务,后者我会特别抵触。

现在学校学习就上面几条条件一条都不占。

继续阅读“上限”


  1. 这一部分的分类方法,即 introduction – tutorial – reference 三步属于是我的理解,但后来想象,可能跟前两天在爆栈网站(Stack Overflow)上看到的一个 C++ 书籍终极推荐有关,感觉这种分类方法和我的想法非常统一的样子。