Seibel Peter. Coders at Work
Подождите немного. Документ загружается.
Simon Peyton Jones
245
because I thought computing was my hobby—it’d be a bit like cheating to do
it as your degree as well; degrees should be hard.
But maths turned out to be a bit too hard because Cambridge is stuffed
with extremely brainy mathematicians so I switched to electrical sciences.
Seibel: And electrical sciences—that’s what we’d call electrical engineering
in the U.S.?
Peyton Jones: That’s right. At that stage my same friend that I was at
school with, Thomas Clarke, was also here at Cambridge. So Thomas and I
built various computers. You would buy yourself a microprocessor and lots
of 7400 series TTL and wire it up. Our biggest problem, I remember, was
printers. Printers and screens. Those were the hard bits.
Seibel: Because they’re expensive.
Peyton Jones: They’re so expensive—yes. You could get the electrical
parts for the kind of money students could afford but printers were typically
big, fridge-sized line printer things. They had a lot of mechanics in them that
made them completely out of our price bracket. That and storage devices—
any kind of permanent storage device tended to be tricky. So we tended to
have computers with a keyboard, a screen, and not much else. And some
kind of primitive tape mechanism.
Seibel: You guys were building these computers from scratch in ’76 to ’79.
Isn’t that about the same time the Altair was coming out?
Peyton Jones: That’s right. Hobbyist computers were definitely starting to
come out. But we considered those to be rather cheating.
The thing about this machine that we built ourselves was that software was
the problem. I think my most advanced program for this machine was
Conway’s Game of Life. That worked very nicely. But writing any kind of
serious program, like a programming language, was just too much work
because it had very limited permanent storage medium. And it was all typing
in hexadecimal stuff—no assembler.
Seibel: So more raw machine code.
Download at Boykma.Com
Simon Peyton Jones
246
Peyton Jones: Of course the Cambridge mainframe understood BCPL so
we were writing lots of BCPL programs. We were actually writing a
compiler then for a programming language that we’d invented. We never
completed this compiler—it was very elaborate. There were these two
completely divorced worlds. Writing compilers in a high-level language for a
mainframe and diddling with hardware on the other end.
Seibel: What was the first interesting program you remember writing?
Peyton Jones: A program to extract 24-digit square roots on this schools
computer and fit it into 99 memory locations.
Seibel: So you had one spare!
Peyton Jones: That’s right. It was some kind of Newton-Raphson
approximation to do square roots. I was terribly proud of it. What after
that? I suppose the next scale up must have been this compiler that we
never completed. It was written in BCPL and it was extremely elaborate.
We were extremely ambitious with it. There was no type system so we just
had enormous sheets of printout with pictures, diagrams of structures and
arrows between them.
Seibel: You mean in BCPL there was no type system.
Peyton Jones: Yeah, that’s right. So essentially we wrote out our types by
drawing them on large sheets of papers with arrows. That was our type
system. That was a pretty large program—in fact it was over ambitious; we
never completed it.
Seibel: Do you think you learned any lessons from that failure?
Peyton Jones: That was probably when I first became aware that writing a
really big program you could end up with problems of scale—you couldn’t
keep enough of it in your head at the same time. Previously all the things I
had written, you could keep the whole thing in your head without any
trouble. So it was probably the first time I’d done any serious attempt at
long-standing documentation.
Seibel: But even that wasn’t enough, in this case?
Download at Boykma.Com
Simon Peyton Jones
247
Peyton Jones: Well, we had a lot of other things to do, like get degrees.
This was all between 9:00 p.m. and 3:00 a.m.
Seibel: And is there anything you wish you had done differently about
learning to program?
Peyton Jones: Well, nobody every taught me to program. I’m not sure I
ever really missed that. Today I feel as if my main programming blank spot is
that I don’t have a deep, visceral feel for object-oriented programming. Of
course I know how to write object-oriented programs and all that. But
something different happens when you do something at scale. When you
build big programs that last for a long time and you use class hierarchies in a
complex way and you build frameworks—that’s what I mean by a deep,
visceral understanding. Not the kind of stuff that you’d learn immediately
from a book.
I feel that as a lack because I don’t feel I can really be authoritative about
what you can and can’t do with object-oriented programming. I’m always
very careful in what I say, particularly not to be negative about imperative
programming because it’s an incredibly sophisticated and rich programming
paradigm. But somehow because of the way my life developed, I never really
spent several years writing big C++ programs. That’s how you get some
kind of deep, visceral feel and I never have.
Seibel: I think that feeling is usually revulsion.
Peyton Jones: That’s right—but it’s a well-informed revulsion rather than
a superficial, “Oh, that sucks” kind of revulsion.
Seibel: So you finished your three years at Cambridge, then what?
Peyton Jones: Then I thought, “Alright, better do a little bit of work on
computing.” So I spent one year doing a postgraduate diploma in computer
science—my sole formal education in computer science.
Seibel: Is that kind of like a master’s degree?
Peyton Jones: Kind of like a master’s degree. I had a great year. I suspect it
was very similar to the computer science tripos, the undergraduate degree.
Download at Boykma.Com
Simon Peyton Jones
248
But it was intended for students who hadn’t done any other computer
science.
Seibel: Then you spent a couple years in industry before getting back into
research. What were you doing then?
Peyton Jones: That was a very small process control and monitoring
company. We built hardware and software that sat in microprocessor-based
computers that were physically sitting in weigh scale controllers for
conveyor belts. One thing I built watched a load cell on a conveyor belt that
carried coal; it controlled the speed of the belt and listened to what the
load cell was saying and adjusted the speed to make the flow rate what it
should be. It was a little real-time operating system, which I wrote in a
language called PL/Z. It was a little bit like Algol. I wrote it on a Z80
machine that ran a sort of cut-down Unix called Chromix.
It was a very small company—it was like half a dozen people. Varied up to
15 at times. But because it was small everything was quite volatile.
Sometimes we had plenty of money, other times we had none. After two
years I’d decided that the entrepreneurial life was not for me. This was my
main insight about small companies: to be an entrepreneur you need to get
energy from stressful situations involving money, whereas my energy is
sapped by stressful situations involving money. My boss was the managing
director of this company. The worse things got, the more energetic he
would be. He’d come bouncing around and he’d have new technical ideas
for software. He was just as happy as a bee. And I realized, that’s what you
need, because if it saps your energy, you spend your whole time in a slump.
So I decided that was all much too hard work and looked around for a job
and ended up getting a job as a lecturer at University College London. And
when I was there I had no PhD, I had no research training. So my head of
department gave me time off to do research. Gave me a light teaching load
so I could get my research gig started. But I hadn’t the faintest idea what to
do. So I would sit in my office with a blank sheet of paper and a sharpened
pencil and wait for great ideas. And there was this sort of silence while I
would sort of stare around the room waiting for great ideas to come. And
nothing much would happen.
Download at Boykma.Com
Simon Peyton Jones
249
John Washbrook, who was himself a senior academic in the department,
took me under his wing and he told me something that was very important.
He said, “Just start something, no matter how humble.” This is not really
about programming, this is about research. But no matter how humble and
unoriginal and unimportant it may seem, start something and write a paper
about it. So that’s what I did. It turned out to be a very significant piece of
advice.
I’ve told that to every research student I’ve ever had since. Because it’s how
you get started. Once you start the mill turning then computer science is
very fractal—almost everything turns out to be interesting, because the
subject grows ahead of you. It’s not like a fixed thing that’s there that you’ve
got to discover. It just expands.
Seibel: So you came back into academia but you never did get a PhD. How
was that possible?
Peyton Jones: These days getting a faculty post without a PhD would be
very hard. This must have been 1982, 1983. I applied to UCL because my
sister was studying computer science there and she said, “Oh, there are a
couple of lectureships at UCL, why don’t you apply?” Much to my
astonishment, I was appointed. I can only assume that at the time there
must have been a desperate shortage and that anyone that could give a
plausible account of himself, in a computing sense, could get hired. Because
otherwise, how did they manage to hire somebody without a PhD?
After seven years at UCL I began to think maybe I should get a PhD. But it
was a big hassle writing a thesis, really. But, it turns out at Cambridge you
can get a PhD by special regulation, which means that you just submit your
published work and, with luck, they say, “You are a fine person who should
have a PhD.” So I was just getting geared up to do that when I got
appointed as a professor at Glasgow. Full professor. So by that time I was
called “Professor” so nobody would know whether I had a PhD or not so I
dropped the idea. Robin Milner doesn’t have a PhD; it must be a
distinguished company. I’ve stuck like that every since.
Seibel: These days, is getting a PhD valuable? Someone once told me a PhD
is really a vocational degree—if you want to be a professor, you’ve got to
Download at Boykma.Com
Simon Peyton Jones
250
get one but if you don’t want to be a professor, there’s no point. Do you
think that analysis applies to computer science?
Peyton Jones: That part is certainly true. It’s necessary but not sufficient if
you want to stick with research as a career—either academic or at
somewhere like Microsoft Research or Google’s research labs—a serious
industrial research lab. You really need a PhD to get past the starting post.
If you don’t want to pursue a career in research, then I think it becomes a
follow-your-heart kind of thing. You’re five times as productive if you’re
working on something that makes you enthusiastic. So if you find yourself
thinking, “I just love this and I’d just like to have some time to dig into it
some more,” a PhD is a fantastic opportunity to spend three years in
Britain, or rather longer in the States, just studying something. It’s an
incredible freedom really because you’re sort of a parasite on society. If you
know you don’t want to do full-time research as a career then the reason to
do a PhD is because you’re just enthusiastic and inquisitive and interested.
But PhDs are rather strange anyway. They force you to work on your own
and produce a substantial thesis that most people won’t read—they’ll read
your papers. So it’s an unusual research mode.
Once you’ve finished a PhD you start working much more collaboratively
with lots of other people on typically smaller, more bite-sized pieces of
work. I think in some ways a PhD is an odd preparation, even for research.
Odder in Britain because of its compressed timescale. I think in the States
you can be more collaborative for a while until you zero in on your own
research program.
Seibel: Speaking of research and academics, functional programming is
quite popular within the research community but I think a lot of people
outside that community see functional programming as being driven by ideas
that, while neat, can be very mathematical and divorced from day-to-day
programming. Is that a fair characterization?
Peyton Jones: I think it’s about half fair. I characterize functional
programming—that is, purely functional programming, where side effects
are somehow really relegated to a world of their own—as a radical and
elegant attack on the whole enterprise of writing programs. Things that are
Download at Boykma.Com
Simon Peyton Jones
251
radical are by definition not evolutionary from the state of where things are
at.
Today “where things are at” is that big companies are pouring immense
resources into ecosystems and editors and profilers and tools and
programmers and skills and all that kind of stuff. The mainstream is, by
definition, deeply practical. Meanwhile this radical and elegant stuff of
functional programming has much less of that deep, infrastructural support.
But at the same time that doesn’t necessarily make it self-indulgent to
pursue it. Because, after all, unless some people are working on radical and
elegant things you’re going to end up in a local optimum, incrementally
optimizing the mainstream but stuck on a low hill.
So I think that one of the good things about the whole business of academic
research is that professors can go off and do sort of loopy things without
being asked how it’s benefiting the bottom line. Some will do things that
turn out to be fantastically important, and some less so; but you can’t tell
which is which in advance! So my big-picture justification for why it’s worth
some people, like me, spending a lot of time on purely functional
programming, is that it shows promise. I don’t want to claim that it’s exactly
the way that everyone will be writing programs in the future, but it shows
promise. And actually I’ll make the case that it shows increasing promise. I
see it as, when the limestone of imperative programming is worn away, the
granite of functional programming will be observed.
That said, I think purely functional programming started quite geeky and
academic and mathematical. The story of the last, really, 20 years—all the
time I’ve been working on it—has been a story of becoming increasingly
practical, focusing not just on abstract ideas but trying to overcome, one by
one, the obstacles that prevent real-life programmers using functional
programming languages for real applications. The development of Haskell
itself is an example of that.
It’s good that there are a bunch of people out here, maybe slightly
impractical, who are heading towards the mainstream and maybe the
perspectives you learn over here in the purely functional world can inform
and illuminate the mainstream. That, you can see, has happened. Lots of
stuff about type systems and generics were originally developed in the
context of functional programming languages. It was a kind of laboratory in
Download at Boykma.Com
Simon Peyton Jones
252
which some of those ideas were developed. Generators and lazy streams
are another example. Python has list comprehensions at the syntactic level.
There are lots of individual things. Usually they’ve been rebranded and
sometimes, to fit the mainstream context, they’ve been changed quite a bit.
I don’t want to claim a kind of exclusive genealogy but I do think a lot of
ideas have nevertheless percolated across. So it’s been useful.
Seibel: For you, what about the relation between research and actually
programming?
Peyton Jones: Oh, they interact a lot. My area of study is programming
languages. What are programming languages for in the end? They’re to make
it easier to program. They’re the user interface of programming, in effect.
So programming and programming language research are deeply related.
One thing we’re not good about is this: the proof of the pudding is in the
eating, so you should watch programmers eating. That is, you should do
proper, formalized studies of programmers programming and see what they
do. And that’s jolly expensive. And it’s also more “squishy.” It’s harder to
come up with unequivocal results.
So the culture of the programming-language community is much more,
“prove that your type system is sound and complete,” kind of stuff. We
dodge, probably, the more important but much harder to answer questions
about whether, in practice, they make people more productive. But they are
questions that are really hard to give convincing answers to. Are you more
productive writing a functional program or an object-oriented program to
do the same thing? Even if you could spend a lot of money on doing serious
experiments, I’m not sure you’d come up with results which people would
actually buy.
Seibel: Do you guys do any, even small-scale experiments? You’re working
for Microsoft, who has plenty of cash, so why not get a team of experienced
Haskellites and a team of experienced C# people and give them the same
task and see what happens? That’s the kind of test you would need, right?
Peyton Jones: Yeah, yeah, that’s right. It’s partly a question of money. But
it’s not just a question of money. It’s also sort of time and attention. To do
that kind of experiment your whole methodology is different. And you need
to shift culturally as well. And, while Microsoft, from the outside, appears to
Download at Boykma.Com
Simon Peyton Jones
253
have plenty of cash, in fact the story here is largely one researcher and his
workstation. We can’t just turn on money for any particular thing. Be nice if
we could. Nearer the coalface, as it were, there are big usability labs in
Redmond where they do perform experiments on things that are proto
products. New versions of Visual Studio are extensively usability tested.
Seibel: Presumably that’s more for the total user interaction, rather than
for programming language issues.
Peyton Jones: Well, they also do some interesting work on testing APIs.
Steven Clarke and his colleagues at Redmond have made systematic
attempts to watch programmers, given a new API, talk through what they’re
trying to do. And they get the people who designed the API to sit behind a
glass screen and watch them.
And the guys sitting there behind the glass screen say, “No, no, don’t do
that! That’s not the right way!” But it’s soundproof. That turns out often to
be very instructive. They go and change their API. To be honest,
programming language research is weak on that score. But it is partly
because these are difficult questions to answer. And culturally we’re not
well adapted to do it. I regard it as a weakness. But not one that I personally
feel terribly well equipped to address.
Seibel: So if researchers are coming up with interesting ideas about how to
improve programming, are the best of those good ideas from research labs
and universities percolating into practice fast enough?
Peyton Jones: Well, fast enough. I don’t know. Whenever I talk to people
who are actually involved in building products that customers want and are
therefore prepared to pay for, I’m very conscious that many of the things
that bother me just aren’t on their radar at all.
They have to do something this week that their customers are going to
value; they just don’t have time to mess about with something that might
work or that might even work in some ways but in total isn’t yet ready for
prime time.
There’s a bit of a disconnect—it’s sort of a chicken-and-egg problem there.
Sometimes the ideas that are developed in research need quite a bit of
Download at Boykma.Com
Simon Peyton Jones
254
engineering effort around the edges that isn’t fundamental research in order
to be directly useful.
I wouldn’t like to imply that developers on the ground are being dopey
about this, just not taking up good ideas that would benefit their lives.
They’re doing what they’re doing for quite good reasons. There is
sometimes a bit of a gap between research prototypes and stuff that you
can build in reality. And I think that Microsoft is actually doing quite well
here because Microsoft Research does fill that gap a bit and does have quite
a bit of mechanism—incubation groups and so forth—whose aim is to put
researchers and developers in closer touch with each other and perhaps to
help provide some extra effort to lift things across the boundary. So MSR is
kind of as good as it gets, I think, as far as crossing that boundary is
concerned.
There are layers to this kind of onion. For a mainstream developer shop
that’s stuffed with Java, not only is functional programming a radically
different way of thinking about programming but also there are lots of
interop questions. And have you got enough books and are there enough
libraries? So there’s this whole ecosystem that goes with programming,
people and skills and libraries and frameworks and tools and so forth.
If you have enough of those blockers you get sort of stuck. So I think
different pieces of research technology in programming language live on
different points on a spectrum. Some are more evolutionary from where we
are. You can say, “It just plugs right into your existing framework, it works
on unmodified Java, it’s a static analysis that points you to bugs in your code
and yipee!” That’s much easier to absorb than, “Here’s a whole new way of
thinking about programming.”
That said, I think that if we’re specifically discussing functional programming
then I do think that we have seen a qualitative sea change in people’s
attitude. Many more people have heard about functional programming than
ever used to. Suddenly rather than always having to explain what Haskell is,
sometimes people say, “Oh, I’ve heard about that. In fact I was reading
about it on Slashdot the other week and I gather it’s rather cool.” That just
didn’t happen a few years ago.
Download at Boykma.Com