Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2311723
  • 博文数量: 527
  • 博客积分: 10343
  • 博客等级: 上将
  • 技术积分: 5565
  • 用 户 组: 普通用户
  • 注册时间: 2005-07-26 23:05
文章分类

全部博文(527)

文章存档

2014年(4)

2012年(13)

2011年(19)

2010年(91)

2009年(136)

2008年(142)

2007年(80)

2006年(29)

2005年(13)

我的朋友

分类: C/C++

2006-05-27 12:57:57

Herbert Schildt不知道怎么搞的, 他的书在C语言社团中广为人诟病. 我看过不少的C/C++推荐书籍列表上, 赫然写着应该避免的书籍, 往往只有一条: 所有Herbert Schildt的书. 客气点的给了一个原因:
It's not that we hate Herb, the problem is that his prose is easy to read but his knowledge of C is limited and inaccurate.
[ 我们不是讨厌Herb, 问题是他的散文很容易读但他关于C的知识却很有限并且不精确. ]

谁都知道C/C++领域烂书和平庸的作者太多了, 很多人的水平还不如Herb, 为什么是Herb而不是别人被点名批评, 我想原因可能有二:

1. Herb 不是普通C程序员, 他是ANSI/ISO组织C语言标准化委员会的委员. 这样的人犯下错误被认为是不可原谅的, 牛人当然也会犯错, 但牛人第一不能犯错太多太频繁, 第二犯低级的错误. 因为牛人的名声已经起来了, 人们对他的期望值很高, 他也很可能给别人以自我感觉良好甚至优秀的印象. 此时再犯错, 人们的心理落差太大. 受不了. 会觉得他徒有虚名. Herb之在C社区被诟病, 正如谭XX之在中国计算机教育界之被诟病, 也正如邱XX之在计算机书籍中译界之被诟病.

2. 他的书一定曾经被广为推荐, 或者曾经十分畅销, 如果一本烂书根本没什么市场, 那它造成的危害也十分有限, 没有必要特别点名告诫大家去避免, 一告诫可能反而提醒大家注意了, 也就是说他曾经被广泛误解或对这个圈子造成了大范围的负面影响, 所以提及他是为了纠正大家的错误印象, 已经上当的要检视以前从他的书中获得的知识, 还没上当的要避免买他的书.

我手里买了一本他的<>, 幸亏我不是在缺少足够C知识的保护下看它, 也幸亏我其实没看多少.

不过, 抛开主观的感情因素, 一个这样的人, 他犯错误归犯错误, 但整体的错误比例应该还是远远小于正确的部分, 问题就在于人们读一本书不是为了从中分辨正确与错误, 如果有这样的水准大概也不需要去看这本书了.

顺便列出广为推荐并且确实是经典, 我也已经精读过的:
1. The C Programming language.
我后悔自己是在2006年才抽出时间看这本书. 我学习C语言主要是通过一个自认为彻底的方法: 通过阅读编译器生成的汇编码, 这个方法确实不错, 它使我从一开始就从书中解脱出来, 得以绕过教科书中各种术语引起的各种概念尤其是一些劣质的中译版. 以直接体验的方式探究底层的实现, 回过头再来看书里面的术语, 就十分容易知识它所指何物.

但是, 这个方法却并不如我想象的好, 它提供给你的印象是一种特殊实现的做法, 所以它的弊端就是我不知不觉中把一些具体实现的部分当作是标准了. 底层的知识有底层知识的好处, 但它并不足心好到可以让你忽略其它的任何方面. 比如一个顶级的汇编语言程序员并不能保证他有软件工程方面的足够知识, 根据我的经验有这种底层倾向的人往往轻视或不屑于这方面的知识, 当单个的程序员投身于一个稍具规模的项目并开始与人合作时, 缺乏软件工程方面的原则和训练会同样让你隐身于混乱和复杂, 不管你的C语言知识, 乃至机器底层的知识是多丰富和准确.

在这种过分的自信下, 我相信自己不需要看C语言的书. 所以我有相当一段时间不看C语言的书, 买书也是送给别人.

这种错觉一直维持到我看了<>一书. 其作者是SUN编译器小组的成员, 中文版叫<> 徐波翻译, 我一字一句认真看完. 开始反省自己对ANSI C是否真正达到了一个精确和自大到拒绝任何经典的程度.

顺便点评一下中译版, 2001年机械工业出版社出了一个中译, 是徐宝文翻译的, 我看了K&R写的中文版序言, 其中说[ We are delighted that Professor Xu has made this Chinese translation of "The C Programming Language" available so that C will be more readily accessible to our colleagues in the People's Republic of China. ], 看到这我深以为信, 觉得主教已经首肯的译者, 肯定没问题. 但是我认真读完全书后感觉翻译并不到位, 我不是在说翻译中"雅"的那种要求, "信"都有问题, 有些翻译的词句明显反映出作者对英文原文的要传达的意思并不真正了解. 每次读到这种地方, 我都会对照英文原版, 弄明白咋回事. 所幸, 这样的地方并不多. 但是我仍然感到遗憾, 因为正如K&R的前言中所说, C不是一个大的语言, 一个程序员有望掌握整个语言. 如果翻译的教授都没有掌握, 你能期望其它的程序员能掌握么?

同样是徐宝文教授, 在2004年出版了这本书的新的译版, 这次由上海教大的尤晋元审校, 序文中说不是简单的照抄上版, 而是重译. 作者在序中说"无时无刻不感觉如履薄冰, 惟恐因为才疏学浅, 无法正确再现原着的风貌". 有这样的态度我决定再相信他一次, 很多国内的教授挂名让手下那些半瓶水都没有的学生翻译出来的东西, 连态度都不端正. 我猜想徐教授自己也对第一个译版不满意.

2. <>
是提醒我反思自己在C语言问题上的过于自大的第一本书. 作者不光技术好, 文笔也好, 书中很多小故事也是其他地方难得一见的. 有时候, 一个谦虚或淡泊的人想把自己的光芒隐藏起来, 但这样的努力往往会归于失败, 我并不是一看作者的名字就知道他在SUN编译器小组工作, 我是在书中看到太多的闪光点之后开始觉得作者的非比寻常, 然后在用google来发掘英雄的出处.
中文版是徐波翻译的, 翻译质量很好, 除了开头把lint译为长整数的那处败笔.

3. <>
我看的是0.94版的中译. 似乎任何一个主题都有一个FAQ, 但FAQ却往往被忽略, 或者被认为只涉及关于某个主题过于普通和简单的问题. 我又错了, 至少对C的这份FAQ而言, 它里面的问题不仅常见, 而且十分重要, 最关键的是它纠正了很多已经在工作中的C程序员容易形成的普遍误解. 在对整个语言有了一个了解之后, 看这种基于单个条款进行讨论的书非常容易直指核心. 我高度推荐.

4. <>
又是徐波翻译的一本好书, 书本身好, 翻译也很好, 我甚至没能再挑出一个象在<>中类似lint翻成长整数那样的误译.

名字有点误导, 基本上, 书名的误导有两种效果, 让你认为书非常好非常超值但实际并非如此的, 以及书实际非常好非常超值但却只是平淡地告诉你: 这本书是关于某个主题的, 甚至只提及某个主题的一个方面. 前一种情况非常常见, 书名中放上 complete reference, 强调其完整性, 放上art, 强调其修炼的层次, 放上bible, 强调其独一无二的权威. 一个例子是<>就是上面被批评的可怜的哥们Herb的, 很长, 但却不必要地长. 而<>极为平实, 但实际上却是极为精确和完备的参考手册. 当然并不是每一本有art字眼的书都名不符实, 因为有<>的存在我永远都不敢下这样的结论. 本书的误导是第二种情况, 这种情况极为罕见. 作者的意图是对指针的强调, 所以牺牲了书名对其内容的准确性概括. 当然书中对指针以及对指针和数组的关系的讨论极为经典.

这本书写得非常流畅, 非常适合作为C语言的教材, 作者并不仅仅是个教师而已, 书中的内容明确地显示他也是有丰富一手经验的程序员. 有一种作者似乎非常善于把一个问题以读者最小的脑力代价讲述得清楚明白, 我相信这本书的作者就是这种人. 我在2005年春节假期把这本书认真看完, 很受用.

下面(据说)是经典/好书但我还没读完的:
1. <>                (买了纸版英文)
2. <>                         (超星中文电子版)
3. <>    这本还没搞到电子版
4. <>      (买了纸版中译)
5. <>              (djvu格式英文版)
6. <>                (PDF中文电子版)
7. << The C Puzzle Book>>                  还没搞到电子版

生也有涯, 只应该去读好书. 一个人在烂书中也能学到好的知识, 但你耗不起时间. 我强烈推荐所以的C/C++程序员都去看一看上面我提到的经典好书.


阅读(1960) | 评论(2) | 转发(0) |
给主人留下些什么吧!~~