《Unix编程艺术》读书笔记

        一直想看Unix编程艺术这本书，现在终于看完了，一直想看完书之后做点笔记，现在终于写完了

       Unix/Linux一直很受牛人们的追捧，但是我就一直对它没什么兴趣，一来用起来不方便，很多软件都没有Unix/Linux版本；二来界面也有点丑。这个假期玩了一下OpenSolaris，突然有点喜欢Unix了，于是也就有更大的兴趣去看这本书了。正如这本书上“Unix之失”所说的那样，Unix的传统风格使它失去了不少非技术用户。

Unix之失：
Unix哲学的特性：(Xwindows作者提出的）X致力于提供一套“机制，而不是策略”，以支持一套极端通用的图形操作。行为的最终逻辑被尽可能推后到使用端。
Unix的遗风：原本是为技术人员设计的操作系统；同时也表明设计的信念：最终用户永远比操作系统设计人员更清楚他们究竟需要什么。

        假定每个程序的输出都会成为另一个程序的输入，哪怕那个程序还是未知的。输出中不要有无关的信息干扰。避免使用严格的分栏格式和二进制格式输入。不要坚持使用交互式输入。
                                                                                                                                        ——Unix管道发明人Doug McIlroy

数据压倒一切。如果已经选择了正确的数据结构并且把一切都组织得井井有条，正确的算法也就不言自明。编程的核心是数据结构，而不是算法。
                                                                           ——最伟大的C语言大师之一Rob Pike《Notes on C Programming》

Unix哲学一言以蔽之
K.I.S.S.
Keep It Simple, Stupid!

SPOT（Single Point of Truth）原则/Don't Repeat Yourself：
任何一个知识点在系统内部都应当有一个唯一、明确、权威的表述。

        透明性和可显性：透明性是一种被动品质，可显性是一种主动品质。如果没有阴暗的角落和隐藏的深度，软件系统就是透明的，可以砍头及其究竟在做什么。如果软件系统所包含的功能是为了帮助人们对软件建立正确的“做什么、怎么做”的心理模型而设计的，这个软件就是可显的。

        优雅的代码既透明又可显，优雅的代码不仅正确，而且显然正确。

Unix中进程之间的协作方式
1 把任务转给专门程序，最简单的形式就是一个程序调用另一个程序完成任务。
2 管道、重定向和过滤器。
3 包装器。
4 安全性包装器和Bernstein链
5 从进程
6 对等进程间通信：临时文件、信号系统守护程序和常规信号、套接字、共享内存

数据驱动编程
        把代码和代码作用的数据结构划分清楚，在改变程序的逻辑时，只要编辑数据结构而不是代码。它不同于以数据组织为中心的面向对象编程：在数据驱动编程中，数据不仅仅是某个对象的状态，实际上还定义了程序的控制流；OO首先考虑的是封装，而数据驱动编程看重的是编写尽可能少的固定代码。数据驱动编程重要的是把程序逻辑从硬编定的控制结构转移到数据中。

什么是不可配置的
Unix总是尝试使一切都可配置，以最大程度的提高灵活性。
配置的指导原则：
1 对于能够可靠的进行自动检测的东西，就不要提供配置开关。尽量用自动检测来减少配置开关的数量，或者在运行时不断尝试其他方法直到成功。
2 用户不应该看到优化开关。与提高界面复杂度成本相比，让用户从优化开关来获取的那点儿性能收益，换来界面复杂度的提升，往往得不偿失。
3 能用脚本包装器或简单管道实现的任务，就不要用配置开关实现。能简单利用其他程序来完成的任务，就不要增加本程序的复杂度。

Unix配置存放的地方
1 /etc下的运行控制文件（或者系统中其他固有位置）
2 由系统设置的环境变量
3 用户主目录中的运行控制文件（或“点文件”）
4 由用户设置的环境变量
5 启动程序的命令行所传递的开关和参数

程序员工具箱中最强大的优化技术就是不做优化。
摩尔定律的指数效应——最聪明、最便宜、常常也是最迅速的性能提升方法，就是等上几个月，期望硬件性能更好。

Everything should be made as simple as possible, but no simpler.                                     --Albert Einstein

Zawinski定律（“软件信封定律”）：每个程序都试图扩展直到能够阅读邮件。不能如此扩展者，将被能者取代。

最简原则：选择需要管理的上下文环境，并且按照边界所允许的最小化方式构建程序。

各种各样的语言：
C：C能够帮助我们学会在硬件体系层次上考虑问题。他的最佳之处是资源效率和接近机器语言。而最糟糕的地方是其编程简直是资源管理的炼狱。
实例：fetchmail

C++：最佳之处是编译效率以及面向对象和泛型编程的结合。最糟之处是它非常怪异复杂，往往鼓励过分复杂的设计。
实例：Qt工具包

shell：最佳之处在于书写小型脚本非常自然快捷。最糟之处在于大型shell脚本必须依靠大量辅助命令，而这些辅助命令不一定在所有目标机器上都表现一致甚至不一定存在。
实例：xmlto
           Sorcery Linux

Perl：增强了的shell。最佳之处是作为强力工具以供大量涉及正则表达式匹配的小型胶合脚本使用。最糟之处在于当程序很大时Perl会变得非常丑陋、刻板，几乎无法维护。
实例：blq（小型），keeper（大型）

Tcl（工具命令语言）：一个设计来连入C编译库德小型语言解释器，提供C代码的脚本控制（扩展脚本）。它的最佳之处在于节俭、紧凑的设计和Tcl解释器的可扩展性。最糟之处在于其古怪的位置分析器和孱弱的数据结构及命名空间控制。
实例：TkMan
      Moodss

Python：最佳之处在于鼓励清晰、易读的代码，易学易用，又能够扩展到大型项目。最糟之处在于，不仅相对于编译语言，而且相对于其他脚本语言，它也是效率低下，速度缓慢的。
实例：imgsizer
            fetchmailconf
            PIL

Java：最佳之处在于它非常接近“一次编写、到处运行”的目标，作为一个独立于操作系统的环境非常有用。最糟之处在于Java1/Java2的分裂令人沮丧的损害了这个目标的实现。
实例：FreeNet

Emacs Lisp：最佳之处在于结合了非常优秀的基础语言Lisp，其域原语对文本操作非常有效。最糟之处在于性能较差，难以和其他程序通讯。