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 AltiVec
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