[原创]我们如何构建软件-编译篇.pdf

我的全部共享资源 谈到构建软件，最常听到的一个词是“编译” ，所以我们从编译开始。 编译的本质 用最简练的语言描述编译器的故事，那就是：翻译。 (from /wiki/Compiler) A compiler is a computer program (or set of programs) that transforms source code written in a programming language(the source language) into another computer language (the target language, often having a binary form known as object code). The most common reason for wanting to transform source code is to create an executable program. 两个对象要沟通，一定要有沟通的媒介。把这个媒介抽象出来，就是语言。在语言不通的情况下，要沟通就需要翻译。编 译过程正是这样一个翻译的过程。宽泛地定义“编译” ，我们可以讲程序员“说”着各种不同的编程语言(诸如 Java ，C# ，C ，C++ ，汇编语言等) ，不同硬件架构不同操作系统的计算机“说”着不同的机器语言，而编译器负责把这些程 序员说的源语言(source code)转化为目标机器上运行的本地可执行程序(native executable) 。一个典型的C 语言程序的编 译过程如下图所示： 计算机世界的语言像人类世界的自然语言一样丰富多彩，因此承担翻译工作的编译器种类也不少，并且这些编译器所工作 的领域和层面也不尽相同。如果从程序员书写的源语言到机器能够“读懂”的机器语言可以经过多次中转的翻译过程，那么 沟通的灵活性便可以增强。因为沟通对象选择语言的自由度将更大，只需要掌握与任务相关的“领域特定语言”便可完成“沟 通”任务。例如we 前端程序员可以只掌握运行在浏览器端的交互语言(javascript/AS, XHTML/CSS 等)便可胜任工作，而 不必了解操作系统运行机理，c/c++等系统编程语言。编程世界的这种分工可以大大提高软件的开发效率。为开发效率的提 高付出的代价通常是执行效率的降低。然而，正如没有完美的人一样，语言也不曾完美。要善解“人”意，就要为机器做更 多的翻译工作；选择亲近机器，对人类则显的冰冷无情。每一种语言都会在两者之间权衡轻重，做出取舍。没有最好的语 言，只有最合适的语言。 如果翻译过程的最终语言是特定机器的本地语言(native language) ，那么任务可以通过机器直接执行(准确的说，是由操作 系统直接调度执行) 。这种翻译过程的源语言被称为编译型语言，例如c/c++, pascal, Ada 等。有的源语言经过翻译过程后 (或者干脆不翻译)不能由操作系统直接理解，需要通过一个“代理”来代替操作系统理解并执行程序，这样的源语言被称为解 释型语言，相应的“代理”被称为解释器，例如Shell, python, ruby, javascript 等。还有的源语言在最终运行之前可能经过了 若干次编译和解释的过程。人们对于一些语言是编译型还是解释型尚未达成共识，例如Java on Sun JVM(先编译为字节码 再由JVM 解释执行) ，C# on .NET Framework(先编译为CLI 中间代码，运行时由JIT 编译为本地代码加载到内存中运行) 。 个人观点 ，太过纯粹的东西或许会是高贵的，但是张力不足 ；唯有做出适当的妥协才可以兼容并包。 作为“代理”部分运作的机构，有各种不同的名字，比如浏览器(html, javascript), bash(Shell), 解释器, Java 虚拟机, CLR 等 ， 并且各自的职能与运作层面不完全相同。但是 就它们作为解释器的功能来说，这些东西本质上属于一类角色。 编程语言与平台的关系 有人说过，语言体现的是一种思考方式 。思考方式不是凭空产生的，依附于一定的实体 ，可以是一个人，一群人，一个社 区乃至整个生态圈。比如，了解C 语言历史的人应该知道 ，C 语言是随着Unix 的流行逐渐被人们认识和喜爱的。Eric S. Raymond 在The Art of Unix Programming一书中说过，C 与Unix/开源软件是一对共生体 ，它们相互扶持 ，相互成就，共