K.I.S.S

自己也翻译过这篇，因为这篇基本把主流的编程语言都拿出来喷了一遍。当然，尤其是 c++。缺点基本也没说错，或许有其他的缺点和优点，但是准确率是够的，只要不考虑召回率。

作者整本书里对Python的发展形式貌似都出现了误判。现在Python基本是脚本语言里面用的最多了，从我看来原因很主要的就是”胶水语言“的角色扮演的非常好，想要封装一个脚本库，想到的第一个基本就是Python，当然，本身的库资源也很丰富，脏活杂活都能做。

主要是针对Java及其过于强调OOP的问题。起码这些批评都可以用到C#上。看看别人写的C#的代码，不少也都是文中提到的Java风格。当然， 如果使用C++也一直往Java这样的风格上靠, 也会是一个结果。

OOP这块代码的过度设计，追求一些设计模式, 其实也是被迫使用一些设计模式. 因为为了程序的灵活重用容易扩展等等要求, 到最后基本也就这些选择了. 如此看来, 由于语言的具有的特性, 造成了使用这个语言的代码所具有的一些特征. 书中用类似的风格写的故事深刻揭示了使用Java或者类似风格语言的大量的冗余特征.

当然, 各个语言都有各自的优缺点. 但是Java这个特点真的是实在太明显了. 而且容易造成整个程序的逻辑散布在各处, 这其实是反直觉的, 虽然区分逻辑是没有问题的.

把软件工程划分成保守派和自由派. 保守派基本就是大学课程里软件工程的那一套, 分析/设计/类型定义, 自上而下的开发流程. 自由派基本属于各种创业公司爱做的事情, 快速实现, 快速迭代,(但是这也不是说你就可以毫无设计, 瞎JB写).

按照标准划分我自己的话, 我也不知道. 我反对自上而下的开发流程(软件工程方面), 因为这种工程方法需要历史经验, 如果你之前实现过一样或者类似的, 自上而下一般没什么问题. 否则, 一个新事物用这个工程流程, 最后只能等着到处都是的无底坑. 建筑行业或许可以总是这样, 因为:

1. 建房子只要不是超级创新的样式, 那都是被建过一万遍了.
2. 评价指标/安全标准可量化, 即使你玩创新, 大量内容都是可量化的, 计算机模拟可以解决大部分问题.
3. 你也改不起, 虽然作为工程师我敢说, 任何房子建起来肯定都有没完全符合之前设计的, 肯定有各种坑, 可是房子没法让你拆了重新盖, 只能打打补丁.

实现过程(程序实现方面), 我又支持自上而下, 否则太容易陷入细节, 代码规模一大, 肯定就会失控. 不过这和前面的的反对也不矛盾. 自上而下可以帮助抽象思考, 符合直觉, 容易避免小变动造成大量代码改动的情况.

我喜欢编译器严格检查, 包括类型检查. 当然, 这确实是因为我懒, 有些低级错误交给编译器要方便很多. 动态语言容易造成隐藏的不容易发现的弱智错误, 即使理想情况下也要到测试阶段才能暴露, 当然, 不理想的情况下是, 后面的日子里面随机暴露, 不过错误倒是也容易排查, 一般都会有调用栈. 当然, 如果有自动类型推断最好了.

按照里面的语言划分, 我是喜欢温和偏自由. 当然, 我对Ruby很有好感, 这貌似和技术无关. 我就是有好感. 当然, 我反对一切"XX建模".

对计算机体系结构和计算模型的讨论. 当然, 没有什么太实质的. 也没法太实质. 基本的思想就是现在的计算机对并行支持的问题. 计算模型这种问题在我看来不是一个可以在计算机领域内可以解决的问题, 只能交给基础科学的发展还有数学和物理学家们的贡献了. 文中顺便偏题说了下每个人都应该保持学习, 了解新技术的发展.

讨论的是代码重构的问题. 我也得承认, 重构这本书我也是跳的很快的. 但是重构本身是十分重要的. 因为, 任何人都不可能一次就把事情完成的很漂亮. 代码本身也存在一个进化和雕琢的过程. 不过, 话说回来, 重构只能是锦上添花. 如果程序本身就是一坨屎, 你再怎么弄, 它也是臭的. 就像一个物种, 基因没一个适应环境的, 那就应该去死, 反正你挣扎挣扎的结果也是死, 何苦挣扎呢.

写代码就如同去创造一个雕塑作品, 重构是大体完工后的精雕细琢(当然, 代码的精雕细琢动作可以大点), 但是, 你要是把一个人的雕塑的脑袋弄在了腿上, 或者整体比例完全失去了, 你需要的不是精雕细琢, 而是, 重新找块石头.

这标题一看就知道也是个火药桶主题. 作者本身支持弱类型, 不过貌似我看来应该支持动态语言的特性.

强类型会限制开发的灵活性. 而且弱类型性能上也可以用(不过目前来看, 也有公司是从动态语言回归的. 而且要解决的问题也是性能问题. 可见这个也不是个定论).

第一章说的就是各种编程语言的特点, 在我看来, 主要批评的点是:

1. 语法过于复杂的(cpp).
2. 语言表达过于冗余的(Java).
3. 容易造成过度设计的(Java).

强调的是:

1. 灵活的语言.
2. 重构

其他还有一些内容比如, 计算模型的讨论(其实也没什么讨论), 应该保持学习.

讨论技术宗教狂热的主题. 主要内容是程序员本身对语言的狂热, 这是个普遍现象, 比如我, 异常的厌恶js, 我没有什么狂热的, 但是我异常厌恶js, 是的, 没有理由的厌恶, 哪怕其实我的js代码写的很少.

也顺便说了作者对Lisp的一些质疑. 里面提到的一个值得一提, 就是, 当你改变信仰的次数多了后, 下一个信仰对你的影响就越来越少. 这句话我当然是非常赞同的, 之前我也有对一些语言稍微狂热的时候, 不过, 随着我接触的语言越来越多, 我基本已经提不起狂热了, 当然, 对js的厌恶另算(我也不怎么讨厌nodejs, 只是单纯的讨厌js). 当然我似乎对Ruby和Scheme有亲近的好感, 可能是因为这两个我用的不多(可是js我用的也不多啊…).

大部分的偏见, 都源于无知. 这句话的适用范围是很大的(当然, 我本人宁可保持对js的无知).

代码的天敌是什么? 就是规模. 随着规模的增加, 最终整个项目都会失控, 超出维护者的能力.

然后继续是Java背锅. 比如, 设计模式会增加Java代码的规模(说句实话, 这个结论也可以应用在C#/C++上, 如果你滥用设计模式的话).

好了, 这次是Python. 批评Python社区不够积极. 后一篇先以Smalltalk死亡的讨论(被Java天时地利给弄死了)开始. 然后是程序员为什么会出现语言之争(你用的多然后爱上这门语言, 外加个人利益这个因素). 然后是Python和Perl的讨论(作者对Pyhon是误判的, 现在Python对Perl已经是完胜了). 之后是讨论文化(语言的社区带来的不同文化, 进一步造成的差别, 作者承认改变文化基本不可能). 然后Ruby特点和文化的讨论(易学易用, 有Rails)

作者希望Python社区能够有所改变, 这样才能让这个语言发扬光大. 后一篇我看着感觉有点散, 没有太明晰的逻辑, 不过书里的文章貌似都有那么点散.

要学, 离散/概率/线性代数/信息论/微积分. 其他内容不说了. 基本思想: 多看多练, 性趣为主.

就一句话: 编译原理很重要.