Seibel Peter. Coders at Work
Подождите немного. Документ загружается.
L Peter Deutsch
435
of reuse that we were talking about when we were promoting objects was
classes and groups of classes. Except in situations where you have a
collection of classes that embody some kind of real domain knowledge, I
don’t see that happening much.
What I see getting reused is either very small things—individual icons,
individual web page designs—or very big things like entire languages or large
applications with extension architectures like Apache or Mozilla.
Seibel: So you don’t believe the original object-reuse pitch quite as strongly
now. Was there something wrong with the theory, or has it just not
worked out for historical reasons?
Deutsch: Well, part of the reason that I don’t call myself a computer
scientist any more is that I’ve seen software practice over a period of just
about 50 years and it basically hasn’t improved tremendously in about the
last 30 years.
If you look at programming languages I would make a strong case that
programming languages have not improved qualitatively in the last 40 years.
There is no programming language in use today that is qualitatively better
than Simula-67. I know that sounds kind of funny, but I really mean it. Java is
not that much better than Simula-67.
Seibel: Smalltalk?
Deutsch: Smalltalk is somewhat better than Simula-67. But Smalltalk as it
exists today essentially existed in 1976. I’m not saying that today’s languages
aren’t better than the languages that existed 30 years ago. The language that
I do all of my programming in today, Python, is, I think, a lot better than
anything that was available 30 years ago. I like it better than Smalltalk.
I use the word qualitatively very deliberately. Every programming language
today that I can think of, that’s in substantial use, has the concept of pointer.
I don’t know of any way to make software built using that fundamental
concept qualitatively better.
Seibel: And you’re counting Python- and Java-style references as pointers?
Download at Boykma.Com
L Peter Deutsch
436
Deutsch: Absolutely. Yes. Programs built in Python and Java—once you get
past a certain fairly small scale—have all the same problems except for
storage corruption that you have in C or C++.
The essence of the problem is that there is no linguistic mechanism for
understanding or stating or controlling or reasoning about patterns of
information sharing and information access in the system. Passing a pointer
and storing a pointer are localized operations, but their consequences are
to implicitly create this graph. I’m not even going to talk about
multithreaded applications—even in single-threaded applications you have
data that’s flowing between different parts of the program. You have
references that are being propagated to different parts of the program. And
even in the best-designed programs, you have these two or three or four
different complex patterns of things that are going on and no way to
describe or reason about or characterize large units in a way that actually
constrains what happens in the small.People have taken runs at this
problem. But I don’t think there have been any breakthroughs and I don’t
think there have been any sort of widely accepted or widely used solutions.
Seibel: They aren’t, perhaps, widely used, but what about pure functional
languages?
Deutsch: Yes, pure functional languages have a different set of problems,
but they certainly cut through that Gordian knot.
Every now and then I feel a temptation to design a programming language
but then I just lie down until it goes away. But if I were to give in to that
temptation, it would have a pretty fundamental cleavage between a
functional part that talked only about values and had no concept of pointer
and a different sphere of some kind that talked about patterns of sharing
and reference and control.
Being a compiler and interpreter guy, I can think of lots of ways of
implementing a language like that that doesn’t involve copying around big
arrays all the time. But the functional people are way ahead of me on that.
There are a lot of smart people who’ve been working on Haskell and similar
languages.
Download at Boykma.Com
L Peter Deutsch
437
Seibel: Wouldn’t the Haskell guys come back and say, “Yes, that’s our
monads and the way that it’s clearly differentiated is in the type system?”
Deutsch: You know, I have never understood Haskell monads. I think I
stopped tracking functional languages at ML.
If you look at E—this is not a language that anyone knows about to speak
of—it’s this language which is based on a very strong notion of capability.
It’s related to Hewitt’s actor languages and it’s related to capability-based
operating systems. It has ports, or communication channels, as the
fundamental connection between two objects, the idea being that neither
end of the connection knows what the other end of the connection is. So
this is very different from a pointer, which is uni-directional and where the
entity that holds the pointer has a pretty strong idea what’s at the other end
of it. It’s based on very strong opacity.
My sort of fuzzy first-order idea is that you have a language in which you
have functional computations and you do not have sharing of objects. What
you have is some form of serialized ports. Whenever you want to talk to
something that you only know by reference, it’s part of the basic nature of
the language that you are aware that whatever that thing out there is, it’s
something that’s going to be dealing with multiple sources of
communications and therefore it has to be expected to serialize or arbitrate
or something. There’s no concept of attribute access and certainly no
concept of storing into an attribute.
There are languages in which you have opaque APIs so the implementations
can maintain invariants; it still doesn’t tell you anything about the larger
patterns of communication. For example, one common pattern is, you have
an object, you hand it off to some third party, you tell that third party to do
certain things to it, and then at some point you ask for that object back.
That’s a pattern of sharing. You, the caller, may never have actually given up
all pointers to the object that you handed off. But you agree with yourself
not to make any references through that pointer until that third party has
done whatever you asked them to.
This is a very simple example of a pattern of structuring a program that, if
there were a way to express it linguistically, would help people ensure that
their code was conformant with their intentions.
Download at Boykma.Com
L Peter Deutsch
438
Maybe the biggest reason why I haven’t actually undertaken this effort to
design a language is that I don’t think I have enough insight to know how to
describe patterns of sharing and patterns of communication at a high enough
level and in a composable enough way to pull it off. But I think that is why
constructing software today is so little better than it was 30 years ago.
My PhD thesis was about proofs of program correctness. I don’t use that term
anymore. What I say is you want to have your development system do as
much work as possible towards giving you confidence that the code does
what you intend it to do.
The old idea of program correctness was that there were these assertions
that were your expressions of what you intend the code to do in a way that
was mechanically checkable against the code itself. There were lots of
problems with that approach. I now think that the path to software that’s
more likely to do what we intend it to do lies not through assertions, or
inductive assertions, but lies through better, more powerful, deeper
declarative notations.
Jim Morris, who’s one of my favorite originators of computer epigrams,
once said that a type checker is just a Neanderthal correctness-prover. If
there’s going to be a breakthrough, that’s where I see it coming from—from
more powerful ways of talking declaratively about how our programs are
intended to be structured and what our programs are intended to do.
Seibel: So, for instance, you could somehow express the notion, “I’m
passing a reference to this object over to this other subsystem, which is
going to frob it for a while and I’m not going to do anything with it until I get
it back.”
Deutsch: Yes. There was some experimental work being done at Sun when
I was there in the early ’90s on a language that had a concept similar to that
in it. And there was a bunch of research done at MIT by Dave Gifford on a
language called FX that also tried to be more explicit about the distinction
between functional and nonfunctional parts of a computation and to be
more explicit about what it meant when a pointer went from somewhere to
somewhere.
Download at Boykma.Com
L Peter Deutsch
439
But I feel like all of this is looking at the issue from a fairly low level. If there
are going to be breakthroughs that make it either impossible or unnecessary
to build catastrophes like Windows Vista, we will just need new ways of
thinking about what programs are and how to put them together.
Seibel: So, despite it not being qualitatively better than Smalltalk, you still
like Python better.
Deutsch: I do. There are several reasons. With Python there’s a very clear
story of what is a program and what it means to run a program and what it
means to be part of a program. There’s a concept of module, and modules
declare basically what information they need from other modules. So it’s
possible to develop a module or a group of modules and share them with
other people and those other people can come along and look at those
modules and know pretty much exactly what they depend on and know
what their boundaries are.
In Smalltalk it is awkward to do this—if you develop in Smalltalk in the
image mode, there never is such a thing as the program as an entity in itself.
VisualWorks, which is the ParcPlace Smalltalk, has three or four different
concepts of how to make things larger than a single class, and they’ve
changed over time and they’re not supported all that well by the
development tools, at least not in a very visual way. There’s little machinery
for making it clear and explicit and machine-processable what depends on
what. So if you’re developing in the image mode, you can’t share anything
with anybody other than the whole image.
If you do what’s called filing out—you write out the program in a textual
form—you have absolutely no way of knowing whether you can read that
program back in again and have it come back and do the same thing that it
does because the state of the image is not necessarily one that was
produced, or that can be produced, by reading in a set of source code. You
might have done arbitrary things in a workspace; you might have static
variables whose values have been modified over time. You just don’t know.
You can’t reliably draw lines around anything.
I’m on the VisualWorks developers’ list and the stuff that I see coming up
over and over again is stuff that cannot happen in languages that don’t use
the image concept. The image concept is like a number of other things in
Download at Boykma.Com
L Peter Deutsch
440
the rapid-prototyping, rapid-development world. It’s wonderful for single-
person projects that never go outside that person’s hands. It’s awful if you
want software to become an asset; if you want to share software with other
people. So I think that’s the real weakness of the Smalltalk development
approach and a serious one.
The second reason I like Python is that—and maybe this is just the way my
brain has changed over the years—I can’t keep as much stuff in my head as I
used to. It’s more important for me to have stuff in front of my face. So the
fact that in Smalltalk you effectively cannot put more than one method on
the screen at a time drives me nuts. As far as I’m concerned the fact that I
edit Python programs with Emacs is an advantage because I can see more
than ten lines’ worth at a time.
I’ve talked with the few of my buddies that are still working at VisualWorks
about open-sourcing the object engine, the just-in-time code generator,
which, even though I wrote it, I still think is better than a lot of what’s out
there. Gosh, here we have Smalltalk, which has this really great code-
generation machinery, which is now very mature—it’s about 20 years old
and it’s extremely reliable. It’s a relatively simple, relatively retargetable,
quite efficient just-in-time code generator that’s designed to work really
well with non type-declared languages. On the other hand, here’s Python,
which is this wonderful language with these wonderful libraries and a slow-
as-mud implementation. Wouldn’t it be nice if we could bring the two
together?
Seibel: Wasn’t that sort of the idea behind your pycore project, to
reimplement Python in Smalltalk?
Deutsch: It was. I got it to the point where I realized it would be a lot
more work than I thought to actually make it work. The mismatches
between the Python object model and the Smalltalk object model were bad
enough that there were things that could not be simply mapped one-for-one
but had to be done through extra levels of method calls and this, that, and
the other.
Even at that, Smalltalk with just-in-time code generation was, for code that
was just written in Python, still in the same range as the C-coded
interpreter. So the idea that I had in mind was that if it had been possible to
Download at Boykma.Com
L Peter Deutsch
441
open-source the Smalltalk code generator, taking that code generator and
adapting it to work well with the Python object model and the Python data
representation would not have been a huge deal.
But it can’t be done. Eliot Miranda, who’s probably the most radical of my
buddies associated with VisualWorks, tried, and Cincom said, “Nope, it’s a
strategic asset, we can’t open-source it.”
Seibel: Well, you’re the guy who says software should be treated as a
capital asset.
Deutsch: But that doesn’t necessarily mean that it’s always your best
strategy to prevent other people from using it.
Seibel: So in addition to being a Smalltalker from way back, you were also
an early Lisp hacker. But you’re not using it any more either.
Deutsch: My PhD thesis was a 600-page Lisp program. I’m a very heavy-
duty Lisp hacker from PDP-1 Lisp, Alto Lisp, Byte Lisp, and Interlisp. The
reason I don’t program in Lisp anymore: I can’t stand the syntax. It’s just a
fact of life that syntax matters.
Language systems stand on a tripod. There’s the language, there’s the
libraries, and there are the tools. And how successful a language is depends
on a complex interaction between those three things. Python has a great
language, great libraries, and hardly any tools.
Seibel: Where “tools” includes the actual implementation of the language?
Deutsch: Sure, let’s put them there. Lisp as a language has fabulous
properties of flexibility but really poor user values in terms of its readability.
I don’t know what the status is of Common Lisp libraries is these days, but I
think syntax matters a lot.
Seibel: Some people love Lisp syntax and some can’t stand it. Why is that?
Deutsch: Well, I can’t speak for anyone else. But I can tell you why I don’t
want to work with Lisp syntax anymore. There are two reasons. Number
one, and I alluded to this earlier, is that the older I’ve gotten, the more
important it is to me that the density of information per square inch in front
Download at Boykma.Com
L Peter Deutsch
442
of my face is high. The density of information per square inch in infix
languages is higher than in Lisp.
Seibel: But almost all languages are, in fact, prefix, except for a small
handful of arithmetic operators.
Deutsch: That’s not actually true. In Python, for example, it’s not true for
list, tuple, and dictionary construction. That’s done with bracketing. String
formatting is done infix.
Seibel: As it is in Common Lisp with
FORMAT.
Deutsch: OK, right. But the things that aren’t done infix; the common
ones, being loops and conditionals, are not prefix. They’re done by
alternating keywords and what it is they apply to. In that respect they are
actually more verbose than Lisp. But that brings me to the other half, the
other reason why I like Python syntax better, which is that Lisp is lexically
pretty monotonous.
Seibel: I think Larry Wall described it as a bowl of oatmeal with fingernail
clippings in it.
Deutsch: Well, my description of Perl is something that looks like it came
out of the wrong end of a dog. I think Larry Wall has a lot of nerve talking
about language design—Perl is an abomination as a language. But let’s not go
there.
If you look at a piece of Lisp code, in order to extract its meaning there are
two things that you have to do that you don’t have to do in a language like
Python.
First you have to filter out all those damn parentheses. It’s not intellectual
work but your brain does understanding at multiple levels and I think the
first thing it does is symbol recognition. So it’s going to recognize all those
parenthesis symbols and then you have to filter them out at a higher level.
So you’re making the brain symbol-recognition mechanism do extra work.
These days it may be that the arithmetic functions in Lisp are actually spelled
with their common names, I mean, you write plus sign and multiply sign and
so forth.
Download at Boykma.Com
L Peter Deutsch
443
Seibel: Yes.
Deutsch: Alright, so the second thing I was going to say you have to do,
you don’t actually have to do anymore, which is understanding those things
using token recognition rather than symbol recognition, which also happens
at a higher level in your brain.
Then there’s a third thing, which may seem like a small thing but I don’t
think it is. Which is that in an infix world, every operator is next to both of
its operands. In a prefix world it isn’t. You have to do more work to see the
other operand. You know, these all sound like small things. But to me the
biggest one is the density of information per square inch.
Seibel: But the fact that Lisp’s basic syntax, the lexical syntax, is pretty
close to the abstract syntax tree of the program does permit the language
to support macros. And macros allow you to create syntactic abstraction,
which is the best way to compress what you’re looking at.
Deutsch: Yes, it is.
Seibel: In my Lisp book I wrote a chapter about parsing binary files, using
ID3 tags in MP3 files as an example. And the nice thing about that is you can
use this style of programming where you take the specification—in this case
the ID3 spec—put parentheses around it, and then make that be the code
you want.
Deutsch: Right.
Seibel: So my description of how to parse an ID3 header is essentially
exactly as many tokens as the specification for an ID3 header.
Deutsch: Well, the interesting thing is I did almost exactly the same thing
in Python. I had a situation where I had to parse really quite a complex file
format. It was one of the more complex music file formats. So in Python I
wrote a set of classes that provided both parsing and pretty printing.
The correspondence between the class construction and the method name
is all done in a common superclass. So this is all done object-oriented; you
don’t need a macro facility. It doesn’t look quite as nice as some other way
you might do it, but what you get is something that is approximately as
Download at Boykma.Com
L Peter Deutsch
444
readable as the corresponding Lisp macros. There are some things that you
can do in a cleaner and more general way in Lisp. I don’t disagree with that.
If you look at the code for Ghostscript, Ghostscript is all written in C. But
it’s C augmented with hundreds of preprocessor macros. So in effect, in
order to write code that’s going to become part of Ghostscript, you have to
learn not only C, but you have to learn what amounts to an extended
language. So you can do things like that in C; you do them when you have
to. It happens in every language.
In Python I have my own what amount to little extensions to Python.
They’re not syntactic extensions; they’re classes, they’re mixins—many of
them are mixins that augment what most people think of as the semantics of
the language. You get one set of facilities for doing that in Python, you get a
different set in Lisp. Some people like one better, some people like the
other better.
Seibel: What was it that made you move from programming to composing?
Deutsch: I basically burned out on Ghostscript. Ghostscript was one of my
primary technical interests starting in 1986 and it was pretty much my only
major technical project starting somewhere around 1992–’93. By 1998,
roughly, I was starting to feel burned out because I was not only doing all
the technical work; I was also doing all the support, all the administration. I
was a one-person business, and it had gotten to be too much. I hired
someone to basically build up a business, and he started hiring engineers.
Then it took another two years to find the right person to replace me. And
then it took another two years after that to get everything really handed
over. By 2002, I had had it. I didn’t want to ever see Ghostscript again.
So I said, “OK, I’ll take six months to decompress and look around for what
I want to do next.” At that point I was 55; I didn’t feel particularly old. I
figured I had one more major project left in me, if I wanted to do one. So, I
started looking around.
The one project that kind of interested me was an old buddy of mine from
the Xerox days, J. Strother Moore II, is, or was, the head of the computer-
science department at the University of Texas at Austin. His great career
Download at Boykma.Com