YP.1.3 Two Recurring Themes（双语）

from：

[1] Introduction to Computing System, from Bits and Gates to C and Beyond. Yale N. Patt and Sanjay J. Patel. McGraw-Hill Higher Education.（英）

[2] 计算系统基础_陈道蓄_第一章引言http://resource.jingpinke.com/details?uuid=ff808081-22c93527-0122-c936e141-1a96&objectId=oid:ff808081-22c93527-0122-c936e141-1a97 （中）

1.3 Two Recurring Themes

Two themes permeate this book that we have previously taken for granted, assuming that everyone recognized their value and regularly emphasized them to students of engineering and computer science. Lately, it has become clear to us that from the git-go, we need to make these points explicit. So, we state them here up front. The two themes are (a) the notion of abstraction and (b) the importance of not separating in your mind the notions of hardware and software. Their value to your development as an effective engineer or computer scientist goes well beyond your understanding of how a computer works and how to program it.

The notion of abstraction is central to all that you will learn and expect to use in practicing your craft, whether it be in mathematics, physics, any aspect of engineering, or business. It is hard to think of any body of knowledge where the notion of abstraction is not central. The misguided hardware/software separation is directly related to your continuing study of computers and your work with them. We will discuss each in turn.

1.3.1 The Notion of Abstraction

The use of abstraction is all around us. When we get in a taxi and tell the driver, "Take me to the airport," we are using abstraction. If we had to, we could probably direct the driver each step of the way: "Go down this street ten blocks, and make a left turn." And, when he got there, "Now take this street five blocks and make a right turn." And on and on. You know the details, but it is a lot quicker to just tell the driver to take you to the airport.

Even the statement "Go down this street ten blocks..." can be broken down further with instructions on using the accelerator, the steering wheel, watching out for other vehicles, pedestrians, etc.

Our ability to abstract is very much a productivity enhancer. It allows us to  deal with a situation at a higher level, focusing on the essential aspects, while keeping the component ideas in the background. It allows us to be more efficient in our use of time and brain activity. It allows us to not get bogged down in the detail when everything about the detail is working just fine. 

There is an underlying assumption to this, however: "when everything about the detail is just fine." What if everything about the detail is not just fine? Then, to be successful, our ability to abstract must be combined with our ability to un-abstract. Some people use the word deconstruct—the ability to go from the abstraction back to its component parts.

Two stories come to mind.

The first involves a trip through Arizona the first author made a long time ago in the hottest part of the summer. At the time I was living in Palo Alto, California, where the temperature tends to be mild almost always. I knew enough to take the car to a mechanic before making the trip, and I told him to check the cooling system. That was the abstraction: cooling system. What I had not mastered was that the capability of a cooling system for Palo Alto, California is not the same as the capability of a cooling system for the summer deserts of Arizona. The result: two days in Deer Lodge, Arizona (population 3), waiting for a head gasket垫圈 to be shipped in.

The second story (perhaps apocryphal杜撰) is supposed to have happened during the infancy of electric power generation. General Electric Co. was having trouble with one of its huge electric power generators and did not know what to do. On the front of the generator were lots of dials containing lots of information, and lots of screws that could be rotated clockwise or counterclockwise as the operator wished. Something on the other side of the wall of dials and screws was malfunctioning and no one knew what to do. So, as the story goes, they called in one of the early giants in the electric power industry. He looked at the dials and listened to the noises for a minute, then took a small pocket screwdriver out of his geek pack and rotated one screw 35 degrees counterclockwise. The problem immediately went away. He submitted a bill for $1,000 (a lot of money in those days) without any elaboration. The controller found the bill for two minutes' work a little unsettling, and asked for further clarification. Back came the new bill:

Turning a screw 35 degrees counterclockwise: $ 0.75

Knowing which screw to turn and by how much: 999.25

In both stories the message is the same. It is more efficient to think of entities as abstractions. One does not want to get bogged down in details unnecessarily. And as long as nothing untoward happens, we are OK. If I had never tried to make the trip to Arizona, the abstraction "cooling system" would have been sufficient. If the electric power generator never malfunctioned, there would have been no need for the power engineering guru's deeper understanding.

When one designs a logic circuit out of gates, it is much more efficient to not have to think about the internals of each gate. To do so would slow down the process of designing the logic circuit. One wants to think of the gate as a component. But if there is a problem with getting the logic circuit to work, it is often helpful to look at the internal structure of the gate and see if something about its functioning is causing the problem.

When one designs a sophisticated computer application program, whether it be a new spreadsheet program, word processing system, or computer game, one wants to think of each of the components one is using as an abstraction. If one spent time thinking about the details of a component when it is not necessary, the distraction could easily prevent the total job from ever getting finished. But when there is a problem putting the components together, it is often useful to examine carefully the details of each component in order to uncover the problem. 

The ability to abstract is a most important skill. In our view, one should try to keep the level of abstraction as high as possible, consistent with getting everything to work effectively. Our approach in this book is to continually raise the level of abstraction. We describe logic gates in terms of transistors. Once we understand the abstraction of gates, we no longer think in terms of transistors. Then we build larger structures out of gates. Once we understand these larger abstractions, we no longer think in terms of gates.

The Bottom Line

Abstractions allow us to be much more efficient in dealing with all kinds of situations. It is also true that one can be effective without understanding what is below the abstraction as long as everything behaves nicely. So, one should not pooh-pooh the notion of abstraction. On the contrary, one should celebrate it since it allows us to be more efficient.

In fact, if we never have to combine a component with anything else into a larger system, and if nothing can go wrong with the component, then it is perfectly fine to understand this component only at the level of its abstraction.

But if we have to combine multiple components into a larger system, we should be careful not to allow their abstractions to be the deepest level of our understanding. If we don't know the components below the level of their abstractions, then we are at the mercy of them working together without our intervention介入. If they don't work together, and we are unable to go below the level of abstraction, we are stuck. And that is the state we should take care not to find ourselves in.

1.3.2 Hardware versus Software

Many computer scientists and engineers refer to themselves as hardware people or software people. By hardware, they generally mean the physical computer and all the specifications associated with it. By software, they generally mean the programs, whether operating systems like UNIX or Windows, or database systems like Oracle or DB-terrific, or application programs like Excel or Word. The implication is that the person knows a whole lot about one of these two things and precious little about the other. Usually, there is the further implication that it is OK to be an expert at one of these (hardware OR software) and clueless about the other. It is as if there were a big wall between the hardware (the computer and how it actually works) and the software (the programs that direct the computer's bidding), and that one should be content to remain on one side of that wall or the other.

As you approach your study and practice of computing, we urge you to take the opposite approach—that hardware and software are names for components of two parts of a computing system that work best when they are designed by someone who took into account the capabilities and limitations of both.

Microprocessor designers who understand the needs of the programs that will execute on that microprocessor they are designing can design much more effective microprocessors than those who don't. For example, Intel, Motorola, and other major producers of microprocessors recognized a few years ago that a large fraction of future programs would contain video clips as part of e-mail, video games, and full-length movies. They recognized that it would be important for such programs to execute efficiently. The result: most microprocessors today contain special hardware capability to process these video clips. Intel defined additional instructions, collectively called their MMX instruction set, and developed special hardware for it. Motorola, IBM, and Apple did essentially the same thing, resulting in the AltaVec instruction set and special hardware to support it.

A similar story can be told about software designers. The designer of a large computer program who understands the capabilities and limitations of the hardware that will carry out the tasks of that program can design the program more efficiently than the designer who does not understand the nature of the hardware. One important task that almost all large software systems have to carry out is called sorting, where a number of items have to be arranged in some order. The words in a dictionary are arranged in alphabetical order. Students in a class are often arranged in numeric order, according to their scores on the final exam. There are a huge number of fundamentally different programs one can write to arrange a collection of items in order. Donald Knuth devoted 391 pages to the task in The Art of Computer Programming, vol. 3. Which sorting program works best is often very dependent on how much the software designer is aware of the characteristics of the hardware.

The Bottom Line

We believe that whether your inclinations are in the direction of a computer hardware career or a computer software career, you will be much more capable if you master both. This book is about getting you started on the path to mastering both hardware and software. Although we sometimes ignore making the point explicitly when we are in the trenches of working through a concept, it really is the case that each sheds light on the other.

When you study data types, a software concept (in C, Chapter 12), you will understand how the finite word length of the computer, a hardware concept, affects our notion of data types.

When you study functions (in C, Chapter 14), you will be able to tie the rules of calling a function with the hardware implementation that makes those rules necessary.

When you study recursion (a powerful algorithmic device, in Chapter 16), you will be able to tie it to the hardware. If you take the time to do that, you will better understand when the additional time to execute a procedure recursively is worth it.

When you study pointer variables (in C, in Chapter 17), your knowledge of computer memory will provide a deeper understanding of what pointers provide, when they should be used, and when they should be avoided.

When you study data structures (in C, in Chapter 19), your knowledge of computer memory will help you better understand what must be done to manipulate the actual structures in memory efficiently.

We understand that most of the terms in the preceding five short paragraphs are not familiar to you yet. That is OK; you can reread this page at the end of the semester. What is important to know right now is that there are important topics in the software that are very deeply interwoven with topics in the hardware. Our contention is that mastering either is easier if you pay attention to both. 

Most importantly, most computing problems yield better solutions when the problem solver has the capability of both at his or her disposal.

1.3 两个反复强调的主题

有两个主题渗透在本书之中，这两点从一开始就必须明确。这两个主题是：(a)抽象的概念，和(b)在你的思想中不要将硬件和软件区分开的重要性。这两个主题对于你作为计算机科学家或工程师的发展，其价值远远超过理解计算机如何工作、如何编程。

1.3.1抽象的概念

抽象的使用无处不在。当我们坐上一辆出租车，告诉司机“带我去机场” 时，我们就使用了抽象。一般来说，我们无需告诉司机每一步的具体路线，如“向前，左转弯……”。你可能清楚这些细节，但是只需要告诉司机带你去机场就可以了。

即便是“向前，左转弯……”也可以被进一步分解成使用加速器、方向盘、当心其他车辆、行人等指令。

有了抽象的能力，就可以大大提高生产力。它允许我们以更高的层次来处理问题，让我们集中考虑问题的本质，而不必陷入到细节之中。它允许我们更高效的利用时间，更有效的进行思维。只要与细节有关的每件事都运行良好，一切都会保持正常状态。

然而对此存在一个潜在的假设：“当与细节有关的每件事都运行良好时”。要是与细节有关的事情出了问题呢？所以，我们的抽象能力还必须和非抽象能力相结合。可以使用“析构”来表示从抽象到达其组成部分。

在利用门电路设计逻辑电路时，不必考虑每个门电路的内部结构，把门电路看作为组件即可。这一点就是“抽象”的能力。但是如果逻辑电路在工作时出现了问题，通常需要考虑一下门电路的内部结构，看看是否是由于某些机能造成的问题。这一点就是“非抽象”能力。

在设计一个复杂的计算机应用程序时，例如设计电子表格、字处理系统，或者计算机游戏，都可以使用“组件”这一抽象思想来实现。如果同时考虑组件的每一处细节，就不能集中考虑问题的本质，从而阻碍整个工作的完成。但是把组件集成在一起后出现问题时，为了揭示这个问题，就需要仔细检查每一个组件的细节。

抽象的能力是一项最重要的技能。本书的结构就是逐渐提高抽象的层次，从而提高我们进行抽象思维的能力。我们使用晶体管构建逻辑门，一旦我们理解了逻辑门的抽象，我们就不再用晶体管进行思考。然后我们用逻辑门构建更大的结构，一旦我们理解了这些更大的抽象，我们就不再用门来思考。

小结：

抽象允许我们在处理各种问题时更加有效。只要每件事都正常运行，即使不理解在抽象的下面是什么机制，也没有问题。当我们将一个组件与其他组件组合成一个更大的系统时，如果组件没有发生问题，只在抽象的层次上理解组件就足够了。

但是如果我们对这些组件的抽象层之下不了解，当它们不能正常工作时，我们就无法解决问题。这一点也是我们应该关注的状况。

1.3.2 硬件与软件

许多计算机科学家和工程师被称为硬件专家或软件专家。硬件通常指物理上的计算机。软件通常指程序，可以是操作系统像UNIX或Windows，或是数据库系统像Oracle或DB-terrific，或应用程序像Excel或Word。精通于其中之一（硬件或软件）的专家往往对另一方面知之甚少。就像在硬件和软件之间有一堵墙，人们满足于位于这堵墙的一面或另一面。

但是当你进行计算机学习和实践时，我们希望你采取相反的方法——硬件和软件是计算机系统的两个组件，当它们被设计时，如果二者的能力和限制都被给予考虑，计算机系统将进入最佳工作状态。

微处理器设计者理解了将要在他们设计的微处理器上执行的程序的需要，他们就可以比那些不理解的人设计出更高效的微处理器。例如，Intel，Motorola和其他主要的微处理器厂商几年前就认识到未来的很多程序都会将视频作为e-mail、计算机游戏、电影的一部分。他们认识到对于那些程序，高效执行很重要。结果，今天的大多数微处理器都包括特殊的可以处理这些视频的硬件。Intel定义了额外的指令，被称为MMX的指令集，为其开发了特殊的硬件。Motorola, IBM和Apple做了本质上相同的事情，导致AltiVec指令集以及支持它的特殊硬件的出现。

这一点对于软件设计师也是一样的。理解执行程序任务的硬件的能力和限制的计算机程序设计师，比起那些不理解硬件本质的设计者，能设计出更高效的程序。几乎所有的软件系统必须要执行的一个重要的任务是排序，即一定数量的项目按照一定顺序被排列。字典中的字以字母顺序排列。班级的学生根据他们期末考试的成绩顺序排列。为了按顺序排列这些项目，我们可以写出许多不同的程序。Donald Knuth在《计算机编程艺术第三卷》中，将391页用于这项任务。哪一个排序程序工作得最好，就取决于软件设计师对硬件特征的了解有多少。

小结：

我们相信无论你是倾向于从事计算机硬件职业还是软件职业，如果对于二者，你都能够掌握，你的解决问题的能力就会更强。本书让你从既要掌握硬件也要掌握软件开始进入计算世界的学习。

当我们学习数据类型这一软件概念（在C语言里，12章）时，你会理解计算机字长（硬件的概念）的有限性如何影响数据类型。

当你学习函数（在C语言里，14章）时，你会将函数调用的规则与必须制定这些规则的硬件实现联系起来。

当你学习递归（一种强大的算法策略，17章）时，你会将它与硬件联系起来。如果你花些时间去掌握这一点，你就能更好的理解执行一个递归程序花费的额外时间是有价值的。

当你学习指针（在C语言里，16章）时，关于计算机的存储器的知识会让你更深刻的理解指针提供了什么，何时应使用指针，何时应避免使用指针。

当你学习数据结构（在C语言里，19章）时，关于计算机的存储器的知识会有助于你更好的理解为了更有效的处理存储器里真实的结构，必须做什么。

我们知道前面这5段中的大多数术语，你现在还不熟悉。那不是问题，在阅读完本书，你可以重读这一页。

重要的是如果你同时关注二者，对于掌握其中任何一个都将更加容易。更重要的是，当解决问题的人同时拥有这二者的能力时，大多数计算问题都可以被更好的解决。