《程序员的呐喊》读书笔记（下）

接着《程序员的呐喊》读书笔记（上），继续分享下篇，这次干货比较多哦，有静动态类型的优缺点、强弱类型系统的对抗、设计模式、程序员的数学、编译器的重要性以及保守派自由派的较量，一时消化不了的建议保存以便read it later。

---

静态类型和动态类型的优缺点

1. 静态类型的优点
   下面列出了静态类型的主要优点：
   （1）静态类型可以在程序运行之前，依赖其与生俱来的限制来及早发现一些类型错误。（或是在插入／更新记录，解析XML文档等情况下进行检测。）
   （2）静态类型有更多机会（或者说更容易）优化性能。例如只要数据模型完整丰富，那么实现智能化的数据库索引就会更容易一些。编译器在拥有更精确的变量和表达式类型信息的情况下可以做出更优的决策。
   （3）在C++和Java这样拥有复杂类型系统的语言里，你可以直接通过查看代码来确定变量、表达式、操作符和函数的静态类型。
   这种优势或许在ML和Haskell这样的类型推导语言里并不明显，他们显然认为到哪里都要带着类型标签是缺点。不过你还是可以在有助阅读理解的情况下标明类型一而这些在绝大多数动态语言里是根本做不到的。
   （4）静态类型标注可以简化特定类型的代码自动化处理。比如说自动化文档生成、语法高亮和对齐、依赖分析、风格检查等各种“让代码去解读代码”的工作。换句话说，静态类型标签让那些类似编译器的工具更容易施展拳脚：词法工具会有更多明确的语法元素，语义分析时也比较少要用猜的。
   （5）只要看到API或是数据库结构（而不用去看代码实现或数据库表）就能大致把握到它的结构和用法。
   还有其他要补充的吗？

2. 静态类型的缺点如下：
   （1）它们人为地限制了你的表达能力。
   比如，Java的类型系统里没有操作符重载、多重继承、mix-in、引用参数、函数也不是一等公民。原本利用这些技术可以做出很自然的设计，现在却不得不去迁就java的类型系统。无论是Ada还是C++，或是OCaml等任何一种静态类型系统都有这样的问题。差不多半数的设计模式（不光是Gof的那些）都是扭曲原本自然直观的设计，好将它们塞进某种静态类型系统：这根本就是方枘圆凿嘛。
   （2）它们会拖慢开发进度。
   事先要创建很多静态模型（自顶向下的设计），然后还要依据需求变化不断修改。这些类型标注还会让源代码规模膨胀导致代码难以理解，维护成本上升。（这个问题只在Java里比较严重，因为它不支持给类型取别名。）还有就是我上面已经提到过的，你得花更多的时间来调整设计，以适应静态类型系统。
   （3）