Seibel Peter. Coders at Work
Подождите немного. Документ загружается.
Joe Armstrong
235
any more—at this point it is beautiful. Where every change that you could
conceivably make, makes it a worse algorithm, at that point it becomes
beautiful.
Seibel: You mentioned that when you and Robert Virding were passing the
code back and forth how each of you changed the low-level details of
formatting, stuff that programmers argue endlessly about.
Armstrong: That’s not affecting the beauty of the algorithm.
Seibel: But it’s part of the aesthetic. It’s people’s taste.
Armstrong: Yeah. But I wouldn’t say, “This is ugly code because there’s a
blank after the comma.” Ugly is when it’s done with a linear search and it
could have been done with a binary interval halving. Or it could have done
logarithmically and it’s done linearly. For the wrong reasons. Sure do it
linearly if we know we’re searching through a list of ten elements, who
cares? But if it’s a big data structure then it should have been done with a
binary search. And so it’s really not very pretty to do it in a linear form.The
mathematical algorithms—that’s like Platonic beauty. This is more like
architecture. You admire a fine building—it’s not a mathematical object. Not
a solid or a sphere or a prism—it’s a skyscraper. It looks nice.
Seibel: What makes a good programmer? If you are hiring programmers—
what do you look for?
Armstrong: Choice of problem, I think. Are you driven by the problems
or by the solutions? I tend to favor the people who say, “I’ve got this really
interesting problem.” Then you ask, “What was the most fun project you
ever wrote; show me the code for this stuff. How would you solve this
problem?” I’m not so hung up on what they know about language X or Y.
From what I’ve seen of programmers, they’re either good at all languages or
good at none. The guy who’s a good C programmer will be good at
Erlang—it’s an incredibly good predictor. I have seen exceptions to that but
the mental skills necessary to be good at one language seem to convert to
other languages.
Seibel: Some companies are famous for using logic puzzles during
interviews. Do you ask people that kind of question in interviews?
Download at Boykma.Com
Joe Armstrong
236
Armstrong: No. Some very good programmers are kind of slow at that
kind of stuff. One of the guys who worked on Erlang, he got a PhD in math,
and the only analogy I have of him, it’s like a diamond drill drilling a hole
through granite. I remember he had the flu so he took the Erlang listings
home. And then he came in and he wrote an atom in an Erlang program and
he said, “This will put the emulator into an infinite loop.” He found the
initial hash value of this atom was exactly zero and we took something mod
something to get the next value which also turned out to be zero. So he
reverse engineered the hash algorithm for a pathological case. He didn’t
even execute the programs to see if they were going to work; he read the
programs. But he didn’t do it quickly. He read them rather slowly. I don’t
know how good he would have been at these quick mental things.
Seibel: Are there any other characteristics of good programmers?
Armstrong: I read somewhere, that you have to have a good memory to
be a reasonable programmer. I believe that to be true.
Seibel: Bill Gates once claimed that he could still go to a blackboard and
write out big chunks of the code to the BASIC that he written for the
Altair, a decade or so after he had originally written it. Do you think you
can remember your old code that way?
Armstrong: Yeah. Well, I could reconstruct something. Sometimes I’ve
just completely lost some old code and it doesn’t worry me in the slightest.
I haven’t got a listing or anything; just type it in again. It would be logically
equivalent. Some of the variable names would change and the ordering of
the functions in the file would change and the names of the functions would
change. But it would be almost isomorphic. Or what I would type in would
be an improved version because my brain had worked at it.
Take the pattern matching in the compiler which I wrote ten years ago. I
could sit down and type that in. It would be different to the original version
but it’d be an improved version if I did it from memory. Because it sort of
improves itself while you’re not doing anything. But it’d probably have a
pretty similar structure.
I’m not worried about losing code or anything like that. It’s these patterns in
your head that you remember. Well, I can’t even say you remember them.
Download at Boykma.Com
Joe Armstrong
237
You can do it again. It’s not so much remembering. When I say you can
remember a program exactly, I don’t think that it’s actually remembering.
But you can do it again. If Bill could remember the actual text, I can’t do
that. But I can certainly remember the structure for quite a long time.
Seibel: Is Erlang-style message passing a silver bullet for slaying the problem
of concurrent programming?
Armstrong: Oh, it’s not. It’s an improvement. It’s a lot better than shared
memory programming. I think that’s the one thing Erlang has done—it has
actually demonstrated that. When we first did Erlang and we went to
conferences and said, “You should copy all your data.” And I think they
accepted the arguments over fault tolerance—the reason you copy all your
data is to make the system fault tolerant. They said, “It’ll be terribly
inefficient if you do that,” and we said, “Yeah, it will but it’ll be fault
tolerant.”
The thing that is surprising is that it’s more efficient in certain
circumstances. What we did for the reasons of fault tolerance, turned out
to be, in many circumstances, just as efficient or even more efficient than
sharing.
Then we asked the question, “Why is that?” Because it increased the
concurrency. When you’re sharing, you’ve got to lock your data when you
access it. And you’ve forgotten about the cost of the locks. And maybe the
amount of data you’re copying isn’t that big. If the amount of data you’re
copying is pretty small and if you’re doing lots of updates and accesses and
lots of locks, suddenly it’s not so bad to copy everything. And then on the
multicores, if you’ve got the old sharing model, the locks can stop all the
cores. You’ve got a thousand-core CPU and one program does a global
lock—all the thousand cores have got to stop.
I’m also very skeptical about implicit parallelism. Your programming
language can have parallel constructs but if it doesn’t map into hardware
that’s parallel, if it’s just being emulated by your programming system, it’s
not a benefit. So there are three types of hardware parallelism.
There’s pipeline parallelism—so you make a deeper pipeline in the chip so
you can do things in parallel. Well, that’s once and for all when you design
Download at Boykma.Com
Joe Armstrong
238
the chip. A normal programmer can’t do anything about the instruction-
level parallelism.
There’s data parallelism, which is not really parallelism but it has to do with
cache behavior. If you want to make a C program go efficiently, if
*p is on a
16-byte boundary, if you access
*p, then the access to *(p + 1) is free,
basically, because the cache line pulls it in. Then you need to worry about
how wide the cache lines are—how many bytes do you pull in in one cache
transfer? That’s data parallelism, which the programmer can use by being
very careful about their structures and knowing exactly how it’s laid out in
memory. Messy stuff—you don’t really want to do that.
The other source of real concurrency in the chip are multicores. There’ll be
32 cores by the end of the decade and a million cores by 2019 or whatever.
So you have to take the granules of concurrency in your program and map
them onto the cores of the computer. Of course that’s quite a heavyweight
operation. Starting a computation on a different core and getting the answer
back is itself something that takes time. So if you’re just adding two numbers
together, it’s just not worth the effort—you’re spending more effort in
moving it to another core and doing it and getting the answer back than you
are in doing it in place.
Erlang’s quite well suited there because the programmer has said, “I want a
process, I want another process, I want another process.” Then we just put
them on the cores. And maybe we should be thinking about actually
physically placing them on cores. Probably a process that spawns another
process talks to that process. So if we put it on a core that’s physically near,
that’s a good place to put it, not on one that’s a long way away. And maybe
if we know it’s not going to talk to it a lot maybe we can put it a long way
away. And maybe processes that do I/O should be near the edge of the
chip—the ones that talk to the I/O processes. As the chips get bigger we’re
going to have to think about how getting data to the middle of the chip is
going to cost more than getting it to the edge of the chip. Maybe you’ve got
two or three servers and a database and maybe you’re going to map this
onto the cores so we’ll put the database in the middle of the chip and these
ones talk to the client so we’ll put them near the edge of the chip. I don’t
know—this is research.
Download at Boykma.Com
Joe Armstrong
239
Seibel: You care a lot about the idea of Erlang’s way of doing concurrency.
Do you care more about that idea—the message-passing shared-nothing
concurrency—or Erlang the language?
Armstrong: The idea—absolutely. People keep on asking me, “What will
happen to Erlang? Will it be a popular language?” I don’t know. I think it’s
already been influential. It might end up like Smalltalk. I think Smalltalk’s
very, very influential and loved by an enthusiastic band of people but never
really very widely adopted. And I think Erlang might be like that. It might
need Microsoft to take some of its ideas and put some curly braces here
and there and shove it out in the Common Language Runtime to hit a mass
market.
Download at Boykma.Com
Download at Boykma.Com
C H A P T E R
7
Simon Peyton
Jones
One of the instigators, back in 1987, of the project that led to the definition of the
programming language Haskell, Simon Peyton Jones is a Principal Researcher at
Microsoft Research’s lab in Cambridge, England. He edited the Haskell 98
Revised Report, the current stable definition of the language; he is the architect
and lead developer of the Glasgow Haskell Compiler (GHC), the “de facto
standard compiler” according to haskell.org; and he gave Haskell its widely cited
unofficial motto: “Avoid success at all costs.”
A high-powered researcher and former professor who never got a PhD, Peyton
Jones values both the practical and the theoretically beautiful. He learned to
program on a machine with no permanent storage and only 100 memory
locations, and in college he worked on both writing high-level compilers for the
school’s big iron and building his own primitive computers out of parts he could
afford on a student’s budget. But he was drawn to functional programming by a
professor’s demonstration of how to build doubly linked lists without using
mutation and the beauty of the idea of lazy evaluation. Peyton Jones saw the ideas
of functional programming “as a radical and elegant attack on the whole
enterprise of writing programs”: a way, rather than “just putting one more brick in
the wall,” to “build a whole new wall.” In 2004 the Association for Computing
Download at Boykma.Com
Simon Peyton Jones
242
Machinery elected him a Fellow, citing his “contributions to functional
programming languages.”
Among the topics we covered in this interview are why he thinks functional
programming shows increasing promise of changing the way software is written,
why Software Transactional Memory is a much better way of writing concurrent
software than locks and condition variables, and why it is so difficult, even at a
place like Microsoft Research, to do real studies of whether different programming
languages make programmers more or less productive.
Seibel: When did you learn to program?
Peyton Jones: When I was at school. Intel had just about produced the
4004—the world’s first microprocessor. We didn’t have a 4004 or anything
like it—it was really a chip that hobbyists could barely get at that stage. The
only computer they had available was an IBM schools computer, which was
a strange machine built out of spare parts from mainframes. It had no
permanent storage whatsoever so you had to type in your program every
time you ran it.
It had 100 storage locations, total, which would each store, I think, eight-
digit decimal numbers. And this stored both your program and your data.
So the name of the game of programming that was to simply to fit the
program into 100 storage locations. I can’t quite remember how I got to
write my first program. I think I and one other enthusiast at the school
spent a lot of time on the schools computer. This would have been when I
was about 15, 1974, ’73—that kind of era.
Then after we’d been programming this machine for a little bit we
discovered there was a computer at the technical college in Swindon. So we
spent an hour on a very slow bus one afternoon a week and went to
Swindon where there was this enormous machine—an Elliot 803—which
lived in half a dozen large, white, fridge-sized cabinets in a room all its own
with a white-coated operator.
After a bit the white-coated operator learned that we could figure out how
to use the machine so she went away while we played with this vast engine.
Download at Boykma.Com
Simon Peyton Jones
243
It worked with paper tape and teletype so you had your program on a
paper tape. We wrote in Algol, so that was my first high-level language. You
wrote your program on the tape, you edited on the tape. You wanted to
change it, you had to run the tape through the teletype, make it print out a
new tape, stop it at the right place, type the new bit—an extremely
laborious way to edit your program. A kind of line editor with physical
medium. So that was my first experience of programming. It was very
motivating.
Seibel: That wasn’t a course at school though.
Peyton Jones: Oh, no! Zero, absolutely no teaching about computers at
school.
Seibel: So it was just—“Hey kids, here’s a computer, knock yourself out.”
Peyton Jones: Absolutely. It was there in a large locked cupboard and you
could borrow the key and there it was with a screen and it just displayed a
fixed display of what was in the registers and these decimal numbers of
what was in memory locations. You could set the program and press Go.
You could single-step it. That was really it. So it wasn’t even assembly
language programming because there was no ASCII characters at all. It was
literally the machine code, displayed in decimal, not even in hexadecimal.
Seibel: But it had a screen?
Peyton Jones: It did have a television screen. That was its sole output
medium.
Seibel: And what was the input?
Peyton Jones: It was a kind of touch keyboard. You touched these buttons
and they sensed that your finger touched. So that was rather
sophisticated—no mechanical keys. It was some kind of capacitive thing—
you touched the key and there it was. There were a total of about 20
buttons.
Seibel: So these buttons were just for numbers?
Download at Boykma.Com
Simon Peyton Jones
244
Peyton Jones: Numbers and Go and Step. And “show me this memory
location.” It was really extremely primitive. And all the more exciting for
that.
Seibel: I assume you had to plan your program, probably in excruciating
detail, before you get up to this machine and start keying stuff in.
Peyton Jones: First of all you draw a flow diagram. Then you’d break it
down into instructions. Then you’d encode the instructions into this strange
digital format. And then you type in the numbers. You type in essentially an
800-digit number, which is your program. And then you press Go. If you
were lucky you hadn’t mistyped one of those 800 digits and you were in
good shape. So we spent a lot of time just looking down the thing with one
guy looking at the screen and checking and the other guy saying, “Go to the
next location.”
Then when I went to university at Cambridge, microprocessors were just
beginning to take off. So there was a university computing club. There was a
big university computing mainframe kind of machine, called Phoenix, with an
extremely elaborate accounting system.
The time at which you used it was very significant. You were given a certain
amount of units of the machine’s currency and the more memory your
program took, the more units you consumed; the longer your program
took, the more units you consumed. But the lower the load was, the fewer
units your program consumed. So as a result, us undergraduates, who didn’t
get a very large allocation, simply spent our nights there because from about
9:00 at night it became rather cheap to run your program.
So we would be there 9:00 to 3:00 a.m., writing our programs. And what
did we write in mainly? BCPL, I think. So this again was completely hobbyist
stuff. I was doing a maths degree at the time. So zero formal teaching in
computer science.
There wasn’t a whole undergraduate degree at that time either. That was
1976 to ’79. There was a final year course so you could graduate in
computer science. But you couldn’t do three years of computer science—
you had to do something else like maths or natural sciences beforehand. In
fact I did maths and finished up with a year of electrical sciences. Mainly
Download at Boykma.Com