弄清楚抽象的层次是很重要的。如果不事先搞清楚抽象的层次,就会问出这种无厘头的问题:
- golang需要依赖操作系统吗?底层调用了库的api吗?
(golang实现的跟操作系统对接的部分当然需要依赖操作系统了,要不然它跟什么东西对接?但是其他部分(e.g. Featherweight Go)理论上来说是可以不依赖于任何东西而存在的。) - 为什么windows是用c语言编写的,却对文件大小写不敏感?
(注意这跟FAT文件系统没有关系——起码跟FAT12以及之后的FAT没有关系。这些文件系统的文件名是可以支持小写的。windows文件名大小写不敏感应该是某种从DOS甚至CP/M时代流传下来的convention。然而即便如此,这也跟windows用什么语言编写没有关系。)
现在有一种声音是,前人已经开发了许多不同的IDE,现在初学者学习编程的时候已经没有必要从最基本的工具学起,直接用IDE即可。有些人甚至会认为,「初学者需要脱离IDE从命令行的工具学起」这种观点只是旧时代遗留下来的迂腐规则,或者只是用于在初学者面前耍威风(「我可是经过磨练的!」之类)的胡扯。我个人认为,无论是完全摒弃专门定制的IDE(有些人甚至会建议初学者先学习vi或者emacs;这种就颇为不妥,至少是跟最开始的目的没有什么关系)还是直接拥抱IDE而对命令行工具不管不顾,都是有失偏颇的;CS的初学者,应该先被教授「整个编程的活动由许多不同的层次组成」这一事实,然后再被带着将活动整体分解,理解它由什么部分组成,其中的什么部分具体有什么作用。在这个“IDE vs 命令行”的例子里,初学者应该要明白代码从文本变成程序中间所经历的过程(「这个工具编译」「那个工具链接」等),以及其他参与的部分具体在这个过程中起到什么作用(「这个东西做包管理」「这个东西将多个文件的编译过程自动化」等),然后再去了解前人将这些部分全部整合起来形成IDE的方式。(这里还有一点,就是「意图」本身和「意图的实现形式」的混淆:比如说,本意是要让初学者明白编程活动的过程,这一意图通过教授命令行工具的使用方式这一方式来实现,但是这个实现方式反客为主流变成了意图本身,因此有人才会认为没有办法替从命令行工具教起的做法辩护:他们也没能想起来最开始采用这种方式的意图。)
比较可惜的是,现在大陆的985211以下的CS教育(至少从我自身所经历的情况来看)似乎都没能成功教授「抽象的层次」这一概念(这一部分原本应该计入所谓“计算机导论”里)。不是说他们不会将整个计算机系统切开讲,而是说「切开」这一操作、不同「切片」以「不同的切片」的形式存在的这一事实、「某些东西从属于某个切片而某些东西则从属于另外一个切片」这一概念、以及「在不同的切片考虑问题」这种技能在他们的教学活动似乎是哪里都不存在的:教师因为已经(无论是显式地还是在无意之中)内化了这一点,因此不会特意提及;而学生则因为教师没有提及,只能——也许只能这么说——仰靠自身的悟性去明白这一点。无论是学生还是教师,为了不错误地浪费时间和精力,都应该对此加以注意。
2021.2.10
Back