Seibel: Wouldn’t the Haskell guys come back and say, “Yes, that’s ourmonads and the way that it’s clearly differentiated is in the type system?”

Deutsch: You know, I have never understood Haskell monads. I think Istopped tracking functional languages at ML.

If you look at E—this is not a language that anyone knows about to speakof—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-basedoperating systems. It has ports, or communication channels, as thefundamental connection between two objects, the idea being that neitherend of the connection knows what the other end of the connection is. Sothis is very different from a pointer, which is uni-directional and where theentity that holds the pointer has a pretty strong idea what’s at the other endof it. It’s based on very strong opacity.

My sort of fuzzy first-order idea is that you have a language in which youhave functional computations and you do not have sharing of objects. Whatyou have is some form of serialized ports. Whenever you want to talk tosomething that you only know by reference, it’s part of the basic nature ofthe language that you are aware that whatever that thing out there is, it’ssomething that’s going to be dealing with multiple sources ofcommunications and therefore it has to be expected to serialize or arbitrateor something. There’s no concept of attribute access and certainly noconcept of storing into an attribute.

There are languages in which you have opaque APIs so the implementationscan maintain invariants; it still doesn’t tell you anything about the largerpatterns of communication. For example, one common pattern is, you havean object, you hand it off to some third party, you tell that third party to docertain 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 upall pointers to the object that you handed off. But you agree with yourselfnot to make any references through that pointer until that third party hasdone whatever you asked them to.

This is a very simple example of a pattern of structuring a program that, ifthere were a way to express it linguistically, would help people ensure thattheir code was conformant with their intentions.

Maybe the biggest reason why I haven’t actually undertaken this effort todesign a language is that I don’t think I have enough insight to know how todescribe patterns of sharing and patterns of communication at a high enoughlevel and in a composable enough way to pull it off. But I think that is whyconstructing 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 termanymore. What I say is you want to have your development system do asmuch work as possible towards giving you confidence that the code doeswhat you intend it to do.

The old idea of program correctness was that there were these assertionsthat were your expressions of what you intend the code to do in a way thatwas mechanically checkable against the code itself. There were lots ofproblems with that approach. I now think that the path to software that’smore likely to do what we intend it to do lies not through assertions, orinductive assertions, but lies through better, more powerful, deeperdeclarative 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. Ifthere’s going to be a breakthrough, that’s where I see it coming from—frommore powerful ways of talking declaratively about how our programs areintended to be structured and what our programs are intended to do.

Seibel: So, for instance, you could somehow express the notion, “I’mpassing a reference to this object over to this other subsystem, which isgoing to frob it for a while and I’m not going to do anything with it until I getit back.”

Deutsch: Yes. There was some experimental work being done at Sun whenI was there in the early ’90s on a language that had a concept similar to thatin it. And there was a bunch of research done at MIT by Dave Gifford on alanguage called FX that also tried to be more explicit about the distinctionbetween functional and nonfunctional parts of a computation and to bemore explicit about what it meant when a pointer went from somewhere tosomewhere.

But I feel like all of this is looking at the issue from a fairly low level. If thereare going to be breakthroughs that make it either impossible or unnecessaryto build catastrophes like Windows Vista, we will just need new ways ofthinking about what programs are and how to put them together.

Seibel: So, despite it not being qualitatively better than Smalltalk, you stilllike Python better.

Deutsch: I do. There are several reasons. With Python there’s a very clearstory of what is a program and what it means to run a program and what itmeans to be part of a program. There’s a concept of module, and modulesdeclare basically what information they need from other modules. So it’spossible to develop a module or a group of modules and share them withother people and those other people can come along and look at thosemodules and know pretty much exactly what they depend on and knowwhat their boundaries are.

In Smalltalk it is awkward to do this—if you develop in Smalltalk in theimage 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 differentconcepts of how to make things larger than a single class, and they’vechanged over time and they’re not supported all that well by thedevelopment tools, at least not in a very visual way. There’s little machineryfor making it clear and explicit and machine-processable what depends onwhat. So if you’re developing in the image mode, you can’t share anythingwith anybody other than the whole image.

If you do what’s called filing out—you write out the program in a textualform—you have absolutely no way of knowing whether you can read thatprogram back in again and have it come back and do the same thing that itdoes because the state of the image is not necessarily one that wasproduced, or that can be produced, by reading in a set of source code. Youmight have done arbitrary things in a workspace; you might have staticvariables 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 upover and over again is stuff that cannot happen in languages that don’t usethe image concept. The image concept is like a number of other things inthe rapid-prototyping, rapid-development world. It’s wonderful for singlepersonprojects that never go outside that person’s hands. It’s awful if youwant software to become an asset; if you want to share software with otherpeople. So I think that’s the real weakness of the Smalltalk developmentapproach and a serious one.

The second reason I like Python is that—and maybe this is just the way mybrain has changed over the years—I can’t keep as much stuff in my head as Iused to. It’s more important for me to have stuff in front of my face. So thefact that in Smalltalk you effectively cannot put more than one method onthe screen at a time drives me nuts. As far as I’m concerned the fact that Iedit Python programs with Emacs is an advantage because I can see morethan ten lines’ worth at a time.

I’ve talked with the few of my buddies that are still working at VisualWorksabout 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 codegenerationmachinery, which is now very mature—it’s about 20 years old and it’s extremelyreliable. It’s a relatively simple, relatively retargetable, quite efficientjust-in-time code generator that’s designed to work really well with nontype-declared languages. On the other hand, here’s Python, which is thiswonderful language with these wonderful libraries and a slow-as-mudimplementation. Wouldn’t it be nice if we could bring the two together?