编程之魂：与27位编程先驱的深度对话（英文原版）

4星 · 超过85%的资源需积分: 13 73 浏览量更新于2024-07-25 3 收藏 4.34MB PDF 举报

"编程之魂英文原版 pdf - 与27位编程语言创始人对话" 本书《编程之魂》是一本独特的访谈集，由Federico Biancuzzi和Shane Warden编辑，旨在深入探讨编程语言的设计理念和背后的故事。书中收录了对27位编程语言创始人的深度访谈，涵盖了C、C++、Java、C#等广泛使用的编程语言。作者们通过这些访谈，揭示了编程语言如何塑造了现代软件开发，并提供了关于编程语言设计和演进的深刻见解。这本书对于那些对编程语言历史和设计原理感兴趣的读者来说，是一份宝贵的资源。通过英文原版，读者可以避免翻译可能带来的理解和语境上的偏差，更准确地理解编程大师们的思考和观点。书中涵盖的话题不仅包括编程语言的语法和特性，还可能涉及编译器设计、类型系统、内存管理、性能优化、以及编程语言在特定领域如系统编程、Web开发、科学计算中的应用。例如，C语言的创始人Dennis Ritchie可能会讨论C的简洁性和效率，以及它对后来语言的影响；Bjarne Stroustrup，C++的创造者，可能会分享他如何在C的基础上引入面向对象编程的概念；James Gosling，Java的设计师，可能会阐述他为何选择垃圾回收机制以及平台无关性的设计理念；至于C#，其创始人Anders Hejlsberg可能会解释微软是如何打造一种既支持面向对象又具有.NET框架集成的语言的。在阅读这本书的过程中，读者不仅可以了解到编程语言的诞生背景，还可以学习到如何分析和评估编程语言的优缺点，从而提升自己的编程素养。此外，这些创始人的经验和智慧对于软件工程师、教育工作者以及对编程有热情的任何人都具有启发性。《编程之魂》是一本揭示编程世界核心的著作，它邀请读者跟随编程语言的创造者们一同探索编程的奥秘，让我们的思维和技能与编程的步伐保持同步。通过英文原版，读者可以直接接触这些大师的思想，体验到编程语言设计的艺术和科学。

2 CHAPTER ONE

Design Decisions

Why did you choose to extend an existing language instead of creating a new one?

Bjarne Stroustrup: When I started—in 1979—my purpose was to help programmers

build systems. It still is. To provide genuine help in solving a problem, rather than being

just an academic exercise, a language must be complete for the application domain. That

is, a non-research language exists to solve a problem. The problems I was addressing

related to operating system design, networking, and simulation. I—and my colleagues—

needed a language that could express program organization as could be done in Simula

(that’s what people tend to call object-oriented programming), but also write efficient

low-level code, as could be done in C. No language that could do both existed in 1979, or

I would have used it. I didn’t particularly want to design a new programming language; I

just wanted to help solve a few problems.

Given that, building on an existing language makes a lot of sense. From the base language,

you get a basic syntactic and semantic structure, you get useful libraries, and you become

part of a culture. Had I not built on C, I would have based C++ on some other language.

Why C? I had Dennis Ritchie, Brian Kernighan, and other Unix greats just down (or

across) the hall from me in Bell Labs’ Computer Science Research Center, so the question

may seem redundant. But it was a question I took seriously.

In particular, C’s type system was informal and weakly enforced (as Dennis Ritchie said,

“C is a strongly typed, weakly checked language”). The “weakly checked” part worried me

and causes problems for C++ programmers to this day. Also, C wasn’t the widely used lan-

guage it is today. Basing C++ on C was an expression of faith in the model of computation

that underlies C (the “strongly typed” part) and an expression of trust in my colleagues.

The choice was made based on knowledge of most higher-level programming languages

used for systems programming at the time (both as a user and as an implementer). It is

worth remembering that this was a time when most work “close to the hardware” and

requiring serious performance was still done in assembler. Unix was a major breakthrough in

many ways, including its use of C for even the most demanding systems programming tasks.

So, I chose C’s basic model of the machine over better-checked type systems. What I really

wanted as the framework for programs was Simula’s classes, so I mapped those into the C

model of memory and computation. The result was something that was extremely expres-

sive and flexible, yet ran at a speed that challenged assembler without a massive runtime

support system.

Why did you choose to support multiple paradigms?

Bjarne: Because a combination of programming styles often leads to the best code, where

“best” means code that most directly expresses the design, runs faster, is most maintain-

able, etc. When people challenge that statement, they usually do so by either defining their

favorite programming style to include every useful construct (e.g., “generic programming is

simply a form of OO”) or excluding application areas (e.g., “everybody has a 1GHz, 1GB

machine”).

Download at Boykma.Com

C++ 3

Java focuses solely on object-oriented programming. Does this make Java code more

complex in some cases where C++ can instead take advantage of generic programming?

Bjarne: Well, the Java designers—and probably the Java marketers even more so—

emphasized OO to the point where it became absurd. When Java first appeared, claiming

purity and simplicity, I predicted that if it succeeded Java would grow significantly in size

and complexity. It did.

For example, using casts to convert from

Object when getting a value out of a container

(e.g.,

(Apple)c.get(i)) is an absurd consequence of not being able to state what type the

objects in the container is supposed have. It’s verbose and inefficient. Now Java has gener-

ics, so it’s just a bit slow. Other examples of increased language complexity (helping the

programmer) are enumerations, reflection, and inner classes.

The simple fact is that complexity will emerge somewhere, if not in the language defini-

tion, then in thousands of applications and libraries. Similarly, Java’s obsession with put-

ting every algorithm (operation) into a class leads to absurdities like classes with no data

consisting exclusively of static functions. There are reasons why math uses

f(x) and f(x,y)

rather than x.f( ), x.f(y), and (x,y).f( )—the latter is an attempt to express the idea of a

“truly object-oriented method” of two arguments and to avoid the inherent asymmetry of

x.f(y).

C++ addresses many of the logical as well as the notational problems with object orienta-

tion through a combination of data abstraction and generic programming techniques. A

classical example is

vector<T> where T can be any type that can be copied—including built-

in types, pointers to OO hierarchies, and user-defined types, such as strings and complex

numbers. This is all done without adding runtime overheads, placing restrictions on data

layouts, or having special rules for standard library components. Another example that

does not fit the classical single-dispatch hierarchy model of OO is an operation that

requires access to two classes, such as

operator*(Matrix,Vector), which is not naturally a

“method” of either class.

One fundamental difference between C++ and Java is the way pointers are implemented.

In some ways, you could say that Java doesn’t have real pointers. What differences are

there between the two approaches?

Bjarne: Well, of course Java has pointers. In fact, just about everything in Java is implic-

itly a pointer. They just call them references. There are advantages to having pointers

implicit as well as disadvantages. Separately, there are advantages to having true local

objects (as in C++) as well as disadvantages.

C++’s choice to support stack-allocated local variables and true member variables of every

type gives nice uniform semantics, supports the notion of value semantics well, gives com-

pact layout and minimal access costs, and is the basis for C++’s support for general

resource management. That’s major, and Java’s pervasive and implicit use of pointers (aka

references) closes the door to all that.

Download at Boykma.Com

4 CHAPTER ONE

Consider the layout tradeoff: in C++ a vector<complex>(10) is represented as a handle to an

array of 10 complex numbers on the free store. In all, that’s 25 words: 3 words for the vec-

tor, plus 20 words for the complex numbers, plus a 2-word header for the array on the

free store (heap). The equivalent in Java (for a user-defined container of objects of user-

defined types) would be 56 words: 1 for the reference to the container, plus 3 for the con-

tainer, plus 10 for the references to the objects, plus 20 for the objects, plus 24 for the free

store headers for the 12 independently allocated objects. Obviously, these numbers are

approximate because the free store (heap) overhead is implementation defined in both

languages. However, the conclusion is clear: by making references ubiquitous and implicit,

Java may have simplified the programming model and the garbage collector implementa-

tion, but it has increased the memory overhead dramatically—and increased the memory

access cost (requiring more indirect accesses) and allocation overheads proportionally.

What Java doesn’t have—and good for Java for that—is C and C++’s ability to misuse

pointers through pointer arithmetic. Well-written C++ doesn’t suffer from that problem

either: people use higher-level abstractions, such as iostreams, containers, and algorithms,

rather than fiddling with pointers. Essentially all arrays and most pointers belong deep in

implementations that most programmers don’t have to see. Unfortunately, there is also

lots of poorly written and unnecessarily low-level C++ around.

There is, however, an important place where pointers—and pointer manipulation—is a

boon: the direct and efficient expression of data structures. Java’s references are lacking

here; for example, you can’t express a

swap operation in Java. Another example is simply

the use of pointers for low-level direct access to (real) memory; for every system, some

language has to do that, and often that language is C++.

The “dark side” of having pointers (and C-style arrays) is of course the potential for mis-

use: buffer overruns, pointers into deleted memory, uninitialized pointers, etc. However,

in well-written C++ that is not a major problem. You simply don’t get those problems with

pointers and arrays used within abstractions (such as

vector, string, map, etc.). Scoped

resource management takes care of most needs; smart pointers and specialized handles

can be used to deal with most of the rest. People whose experience is primarily C or old-

style C++ find this hard to believe, but scope-based resource management is an immensely

powerful tool and user-defined with suitable operations can address classical problems

with less code than the old insecure hacks. For example, this is the simplest form of the

classical buffer overrun and security problem:

char buf[MAX_BUF];

gets(buf); // Yuck!

Use a standard library string and the problem goes away:

string s;

cin >> s; // read whitespace separated characters

These are obviously trivial examples, but suitable “strings” and “containers” can be crafted

to meet essentially all needs, and the standard library provides a good set to start with.

Download at Boykma.Com

C++ 5

What do you mean by “value semantics” and “general resource management”?

Bjarne: “Value semantics” is commonly used to refer to classes where the objects have the

property that when you copy one, you get two independent copies (with the same value).

For example:

X x1 = a;

X x2 = x1; // now x1==x2

x1 = b; // changes x1 but not x2

// now x1!=x2 ( provided X(a)!=X(b) )

This is of course what we have for usual numeric types, such as ints, doubles, complex

numbers, and mathematical abstractions, such as vectors. This is a most useful notion,

which C++ supports for built-in types and for any user-defined type for which we want it.

This contrast to Java where built-in types such and

char and int follow it, but user-defined

types do not, and indeed cannot. As in Simula, all user-defined types in Java have refer-

ence semantics. In C++, a programmer can support either, as the desired semantics of a

type requires. C# (incompletely) follows C++ in supporting user-defined types with value

semantics.

“General resource management” refers to the popular technique of having a resource (e.g.,

a file handle or a lock) owned by an object. If that object is a scoped variable, the lifetime

of the variable puts a maximum limit on the time the resource is held. Typically, a con-

structor acquires the resource and the destructor releases it. This is often called RAII

(Resource Acquisition Is Initialization) and integrates beautifully with error handling

using exceptions. Obviously, not every resource can be handled in this way, but many

can, and for those, resource management becomes implicit and efficient.

“Close to the hardware” seems to be a guiding principle in designing C++. Is it fair to say

that C++ was designed more bottom-up than many languages, which are designed top-

down, in the sense that they try to provide abstractly rational constructs and force the

compiler to fit these constructs to the available computing environment?

Bjarne: I think top-down and bottom-up are the wrong way to characterize those design

decisions. In the context of C++ and other languages, “close to the hardware” means that

the model of computation is that of the computer—sequences of objects in memory and

operations as defined on objects of fixed size—rather than some mathematical abstraction.

This is true for both C++ and Java, but not for functional languages. C++ differs from Java

in that its underlying machine is the real machine rather than a single abstract machine.

The real problem is how to get from the human conception of problems and solutions to

the machine’s limited world. You can “ignore” the human concerns and end up with

machine code (or the glorified machine code that is bad C code). You can ignore the

machine and come up with a beautiful abstraction that can do anything at extraordinary

cost and/or lack of intellectual rigor. C++ is an attempt to give a very direct access to hard-

ware when you need it (e.g., pointers and arrays) while providing extensive abstraction

mechanisms to allow high-level ideas to be expressed (e.g., class hierarchies and templates).

Download at Boykma.Com

6 CHAPTER ONE

That said, there has been a consistent concern for runtime and space performance

throughout the development of C++ and its libraries. This pervades both the basic lan-

guage facilities and the abstraction facilities in ways that are not shared by all languages.

Using the Language

How do you debug? Do you have any suggestion for C++ developers?

Bjarne: By introspection. I study the program for so long and poke at it more or less sys-

tematically for so long that I have sufficient understanding to provide an educated guess

where the bug is.

Testing is something else, and so is design to minimize errors. I intensely dislike debugging

and will go a long way to avoid it. If I am the designer of a piece of software, I build it

around interfaces and invariants so that it is hard to get seriously bad code to compile and

run incorrectly. Then, I try hard to make it testable. Testing is the systematic search for

errors. It is hard to systematically test badly structured systems, so I again recommend a

clean structure of the code. Testing can be automated and is repeatable in a way that

debugging is not. Having flocks of pigeons randomly peck at the screen to see if they can

break a GUI-based application is no way to ensure quality systems.

Advice? It is hard to give general advice because the best techniques often depend on

what is feasible for a given system in a given development environment. However: iden-

tify key interfaces that can be systematically tested and write test scripts that exercise

those. Automate as much as you can and run those automated tests often. And do keep

regression tests and run them frequently. Make sure that every entry point into the sys-

tem and every output can be systematically tested. Compose your system out of quality

components: monolithic programs are unnecessarily hard to understand and test.

At what level is it necessary to improve the security of software?

Bjarne: First of all: security is a systems issue. No localized or partial remedy will by itself

succeed. Remember, even if all of your code was perfect, I could probably still gain access

to your stored secrets if I could steal your computer or the storage device holding your

backup. Secondly, security is a cost/benefit game: perfect security is probably beyond the

reach for most of us, but I can probably protect my system sufficiently that “bad guys” will

consider their time better spent trying to break into someone else’s system. Actually, I pre-

fer not to keep important secrets online and leave serious security to the experts.

But what about programming languages and programming techniques? There is a danger-

ous tendency to assume that every line of code has to be “secure” (whatever that means),

even assuming that someone with bad intentions messes with some other part of the sys-

tem. This is a most dangerous notion that leaves the code littered with unsystematic tests

guarding against ill-formulated imagined threats. It also makes code ugly, large, and slow.

“Ugly” leaves places for bugs to hide, “large” ensures incomplete testing, and “slow”

encourages the use of shortcuts and dirty tricks that are among the most fertile sources of

security holes.

Download at Boykma.Com

剩余495页未读，继续阅读

langxiaojunzi

粉丝: 0
资源: 3

编程之魂：与27位编程先驱的深度对话（英文原版）

编程之魂：与27位编程语言创始人对话

编程之魂，各位大师的讲述

STM32F3与F4系列Cortex M4内核编程手册（英文原版）.pdf

Windows 核心编程第五版（英文原版） pdf

c++编程思想（英文原版）

Android4高级编程（第3版）英文原版.pdf

C++编程思想：英文原版PDF

Delphi 5编程规范：英文原版PDF

《简易Java编程教程》英文原版PDF下载

树莓派编程英文原版教程PDF文件

最新资源