接着《程序员的呐喊》读书笔记（上），继续分享下篇，这次干货比较多哦，有静动态类型的优缺点、强弱类型系统的对抗、设计模式、程序员的数学、编译器的重要性以及保守派自由派的较量，一时消化不了的建议保存以便read it later。
静态类型的优点
下面列出了静态类型的主要优点：
（1）静态类型可以在程序运行之前，依赖其与生俱来的限制来及早发现一些类型错误。（或是在插入／更新记录，解析XML文档等情况下进行检测。）
（2）静态类型有更多机会（或者说更容易）优化性能。例如只要数据模型完整丰富，那么实现智能化的数据库索引就会更容易一些。编译器在拥有更精确的变量和表达式类型信息的情况下可以做出更优的决策。
（3）在C++和Java这样拥有复杂类型系统的语言里，你可以直接通过查看代码来确定变量、表达式、操作符和函数的静态类型。
这种优势或许在ML和Haskell这样的类型推导语言里并不明显，他们显然认为到哪里都要带着类型标签是缺点。不过你还是可以在有助阅读理解的情况下标明类型一而这些在绝大多数动态语言里是根本做不到的。
（4）静态类型标注可以简化特定类型的代码自动化处理。比如说自动化文档生成、语法高亮和对齐、依赖分析、风格检查等各种“让代码去解读代码”的工作。换句话说，静态类型标签让那些类似编译器的工具更容易施展拳脚：词法工具会有更多明确的语法元素，语义分析时也比较少要用猜的。
（5）只要看到API或是数据库结构（而不用去看代码实现或数据库表）就能大致把握到它的结构和用法。
还有其他要补充的吗？
静态类型的缺点如下：
（1）它们人为地限制了你的表达能力。
比如，Java的类型系统里没有操作符重载、多重继承、mix-in、引用参数、函数也不是一等公民。原本利用这些技术可以做出很自然的设计，现在却不得不去迁就java的类型系统。无论是Ada还是C++，或是OCaml等任何一种静态类型系统都有这样的问题。差不多半数的设计模式（不光是Gof的那些）都是扭曲原本自然直观的设计，好将它们塞进某种静态类型系统：这根本就是方枘圆凿嘛。
（2）它们会拖慢开发进度。
事先要创建很多静态模型（自顶向下的设计），然后还要依据需求变化不断修改。这些类型标注还会让源代码规模膨胀导致代码难以理解，维护成本上升。（这个问题只在Java里比较严重，因为它不支持给类型取别名。）还有就是我上面已经提到过的，你得花更多的时间来调整设计，以适应静态类型系统。
（3）学习曲线比较陡。
动态类型语言比较好学。静态类型系统则相对挑剔，你必须花很多时间去学它们建模的方式，外加静态类型的语法规则。另外，静态类型错误（也可以叫编译器错误）对于初学者来说很难懂，因为那时程序根本还没跑起来呢。你连用printf来调试的机会都没有，只能撞大运似的调整代码，祈求能让编译器满意。因此学习C++比C和Smalltalk难，OCaml比Lisp难，Nice语言比Java难。而Perl所具备的一系列静态复杂性—各种诡异的规则，怎么用，什么时候用等—让它的难度比Ruby和Python都要高。我从来没见过有哪门静态类型语是很好学的。
（4）它们会带来虚幻的安全感。
静态类型系统确实能减少运行时的错误，提升数据的完整性，所以很容易误导人们觉得只要能通过编译让程序跑起来，那它基本上就没什么bug了。人们在用强静态类型系统的语言写程序时似乎很少依赖单元测试，当然这也可能只是我的想像罢了。
（5）它们会导致文档质量下滑。
很多人觉得自动生成的javadoc就足够了，哪怕不注释代码也没关系， Sourceforge 上充斥着这样的项目，甚至连Sun JDK也常常有这个问题。（比如，Sun很多时候都没有给static final常量添加javadoc注释。）
（6）很难用它们写出兼具高度动态和反射特点的系统。
绝大多数静态类型语言（大概）都出于追求性能的目的，在运行时丢弃了几乎所有编译器生成的元数据。可是这样一来这些系统通常也就很难在运行时作出修改（甚至连内省都做不到）比如，若要想给模块加一个新函数，或是在类里加个方法，除了重新编译，关闭程序然后重启之外别无他法。受此影响的不单是开发流程整个设计理念也难逃波及。你可能需要搭建个复杂的架构来支持动态功能而这些东西会无可避免地和你的业务代码混在一起。
动态类型的优缺点：
只要把上面的列表对调一下，你基本上就可以列出动态类型语言的优缺点了。动态语言的表达能力更强，设计灵活度也更大；易学易用，开发速度快；通常运行时的灵活性也更高。相对地，动态语言无法及时给出类型错误（至少编译器做不到），性能调优的难度也比较高，很难做自动化静态分析，另外，变量和表达式的类型在代码里很不直观，没办法一眼看出来。
静态语言最终会向用户屈服开始添加一些动态特性，而动态语言常常也会尝试引入一下可选的静态类型系统（或是静态分析工具），此外它们还会设法改善性能增加错误检测，以便及早发现问题。很遗憾，除非一开始设计语言的时候就考虑到可选的静态类型，否则强扭的瓜怎么也不会甜的。
下面我会以稍微有点戏谑的方式解释这两种理念（指的是强类型和弱类型）的工作流程，尽可能将它们本质区别展现出来。
强类型阵营基本是这样工作的：首先是按照当前的需求进行设计；制定出文档哪怕只是初稿也没关系；然后定义接口和数据模型。假设系统要承受巨大流量，因此每个地方都要考虑性能。避免采用垃圾收集和正则表达式这类抽象。（注意：即便是Java程序员，通常也会努力避免触发垃圾收集，他们总是在开始写程序之讨论对象池的问题。）
他们只有在无计可施的情况下才会考虑动态类型。例如，一支采用Corba的团队只有在极端情况下才会在每个接口调用上添加一个XML字符串参数，这样他们就能绕开当初选择的死板的类型系统了。
第二个阵营基本是这样工作的：先搭建原型。只要你写代码的速度比写同等详细程度的文档快，你就可以更早地从用户那里获得反馈。按照当下的需求定义合理的接口和数据模型，但是别在上面浪费太多时间。一切以能跑起来为准，怎么方便怎么来。假设自己肯定要面对大量的需求变化，所以每个地方首先考虑的是尽快让系统运行起来。能用抽象的地方就尽量用（比如如每次都去收集数据而先不考虑缓冲，能用正则的地方就先不用字符串比较）就算明明知是牛刀也没关系，因为你换回的是更大的灵活性。代码量比较少，通常bug的数量也会更少。
他们只有在被逼无奈的情况下才会进行性能调优以及禁止修改接口和数据定义。例如，一支Perl团队可能会将一些关键的核心模块用C重写，然后创建XS绑定。时间—长，这些抽象就渐渐变成了既定标准，它们被包裹在数据定义和细致的OO接口里，再也无法修改。（就算是Perl程序员也常常会忍不住祭出银弹，为常用的抽象编写OO接口）
那你觉得最终采用这些策略的结果会怎么样？
me：现在Java程序员相信都知道依赖注入了，因为它太重要了，用在各大框架里，比如spring，依赖注入使得能够在文件里配置类及其各种关系，当然使得Java更灵活更强大了。
me：程序员所要解决的数学问题一般都是离散数学，其中最有用的课程应该就是组合数学和概率论统计。
me：作者强烈要求程序员学编译器原理，你还记得吗？
me：保守派，尽量修复所有bug，回避错误，学不会新语法，通过编译器安全检查，数据必须遵循事先定义好的格式，公共接口必须严格建模，生产系统里绝不允许存在危险过有风险的后门，安全性有疑虑就不能上线，快比慢好，注重性能。自由派则相反。
各大语言的分派：（作者自己使用语言的经验，仅供参考）
难以言喻的自由：汇编语言
极端自由：Perl、Ruby、PHP、脚本
非常自由：Javascript、VB、Lua
自由：Python、Common Lisp、Smalltalk/Sqeak
温和自由：C、Object-C、Schema
温和保守：C++、Java、C#、D、Go
保守：Clojure、Erlang、Pascal
非常保守：Scala、Ada、Ocaml、Eiffel
极端保守：Haskell、SML
（1）Facebook是极端自由的。他们主要用的是C++和PHP，他们的数据都放在memcached里：只有键值对，没有数据库结构。他们把数据导出来放到一个后台Hⅳe数据仓库里，然后用Hadoop来进行离线数据分析。每两个星期左右他们仍然会举办通宵黑客马拉松，反正他们的程序员大多都是单身男青年（至少我上次去参观的时候还是如此），股票的估值也还很高（我上次查价格的时候好像已经没那么好了）。作为一家公司，Facebook是非常紧密的，具有很强的执行力，十分注重程序员在网站上发布新功能的单兵能力，没有什么官僚主义。这对一家规模这么大、用户那么多多的公司来讲是难能可贵的。保守派毫无疑问会厌恶蔑视他们。但是Facebook证明了不管具有什么世界观的程序员，只要联合起来，就能解决很多问题。
（2）Amazon是自由的。
（3）Google是保守的。开始是有点自由的 ，然后就变得越来越保守了。只有在刚刚开始的时候才是软件自由的，那时候的搜索引擎是用Python写的。随着公司不断壮大，他们很快就转向了软件保守主义，而这完全是由工程师自己主导的。他们写了很多宣言警告太多语言所带来的危险，而仅有的几门语言里，也里，也有严格的风格指南，限制使用那些端保守，险”或者“难以阅读”的语言特性。
（4）微软是难以言喻的保守。
版权声明：本文为博主原创文章，未经博主允许不得转载。
原文地址：http://blog.csdn.net/lanxuezaipiao/article/details/47386965
