但软件工业中的很多思想领袖对上述努力却并不认可。尤其是SW EBOK草案的公布,引发了软件开发社区内部的激烈争论。软件方法论专家,IEEE Software杂志顾问和专栏作者Martin Fowler犀利地说:“制订这些课程/知识体系的大多是学院人士,他们至多承接过几个政府项目罢了。”言下之意是,缺乏工业背景的计算机教材/知识体系只是教授们的纸上谈兵。说到这儿,Fowler顺手举了个例子:瞧,面向对象开发的经典著作《设计模式》居然不在SW EBOK给出的“推荐教材”之列。
作为一个热心的教材读者,我能够充分体会Fowler作出非议的缘由。计算机教材的潜在读者更多地应该是未来的工程师,而不是“计算机科学家”,可现今很多教材的作用却好像是一座座奇怪的瀑布,水花欢快地在学院的岩石间嬉戏,却不再成为合理的导航工具,永远不会流入实际工业应用中。缺乏对应用、对实践的关注,任何教材都只能造就纸上谈兵式的开发者。Ken Auer,另一位软件方法论专家,就描述过这么一个教材的牺牲品:这是一个新毕业的CS(计算机系)学生,花了整整一周时间去“优化”软件系统的一个局部;当他得意地展示战果时,Auer才发现他把这一周用在了将一个“顺序表”转化成“二叉树”上——这能提高检索效率呀!“可是,”Auer冷冷地评论说,“那个表中最多包括7条数据,并且很少会检索。”那个检索天才从教材中学会了“顺序表”、“二叉树”,但没有人教过他何时才该用上这几件法宝。
工业是计算机教材服务的终极目标,但很多教材恰恰是在这一点上有所脱节,所以很多从业者(比如我本人)都会觉得,自己的专业能力完全是在毕业后从工业实践中获得的。计算机科学发展中的一些文化变迁也许要为这种脱节负责。早些年间,北美大学的计算机系和大公司之间互动密切,因而一度有“北美计算机教育偏重工程”的说法,不少名著作者走的是从企业到学院的路线(比如写了《人月神话》的Brooks和写了《程序开发心理学》的Weinberg都是IBM工程师出身转而任教的)。但随着学科自身的完善成熟,学院中的工业底色也渐渐褪去。前不久曾来京访问的Purdue大学教授,计算机网络权威Comer就抱怨:“很多聪明、有抱负的美国工程师,曾经尝试过去大学施展才华,可现在也都回到工业界了。”教育界失去了来自工业的源头活水,教材的质量下降怕也在所难免。
但从另一个角度说,计算机科学教育也不完全是职业教育,计算机教材又应该和具体应用保持适当距离。在技术飞速发展的今天,学生和普通读者们并不指望从教材中攫取大量具体技能和技术细节——这些都不太保值,容易过时。换言之,教材的意义就在于其相对的概括和恒常,它提供了学术研究和工业应用之间的一个折冲点;据此,学习者才能把它当成整个职业生涯的起点,而不仅仅是单纯的知识集合。
现有不少计算机教材的弊端,就是它们太容易在“理论灌输”和“职业教育”这两极之间振荡,太注重“知识”的传授而忽略了“智慧”的培育。刚才的例子里,那个职场新人之所以误解了自己的任务,并非出于知识的缺乏,而是因为不具备基本的应用知识解决问题的“智慧”。而教材的使命,就不仅在于赋予学习者具体知识、技能,更在于让学习者懂得如何与该项知识相处,如何在适当的场合、以适当的方式应用知识——这需要特别的“智慧”。起步很晚的计算机科学教育究竟需要怎样的蝶网,才能捕捉这种蝴蝶般轻灵迅捷的智慧,这恐怕还要求整个产业(而不仅仅是学院)更多的摸索和实践。
物理学家、诺贝尔奖得主Richard Feynman讲过一个故事:在南太平洋诸岛的土著人中存在一种“货机崇拜”。二战期间,他们看到飞机运载着很多物资着陆。战后,他们也希望有同样的事情出现,所以他们修出了跑道,沿跑道两旁放了火堆,还造了一个小木屋,里面坐着一个人,头上戴着两个木片作为耳机,再架上竹棍当天线——这就好像是一个地面引航员了。从形式上说,他们做了所有该做的事,但飞机还是没有来。Feynman总结说,“货机崇拜”之所以行不通,是因为土著们忽略了“某种根本的东西(something essential)”。从一个普通读者的角度考虑,上面提到的“智慧”对于教材来说似乎就是这个“根本的东西”。无论是工业应用的智慧,还是学术研究的智慧,如果被教材作者所忽视,那么即使参照了最前沿的“知识体系”,这部教材大概也还是和一座配备了木片儿、竹棍儿的木屋差不多吧?