What I am talking about tomorrow is Elephant and Elephant is based on two slogans, one is that an elephant never forgets and the other is "I meant what I said and I said what I meant" an Elephant's faithful 100%. Elephant programs have two characteristics that are described: one of them is that they can refer directly to the past without in the program itself defining a data structure and second that they can make promises and are correct if they keep their promises. So those are the basic aspects of Elephants. My original plan was that Elephant 2000 should be a programming language that would be ready by the year 2005 , but it's not and it seems to me that there still aren't enough ideas to completely define a new programming language, so it's occurred to me that the basic ideas of Elephant are things that can be used to extend a variety of present programming languages if their implementers want to do that, so such languages called Fortran, COBOL, Java, etc.
2. Could you describe these ideas and how they could be implemented in future programming languages?
First the idea of referring to the past and as I said the example was a passenger has a reservation if he's made one and it hasn't been canceled. Now we would like to put that into a programming language so that it would be defining a predicate "has passenger reservation" so you might have a statement or some input/output "has John reservation on Air Canada flight 761 from Montreal to San Francisco". So now the question is how does this get implemented and there are two ways they can be implemented, one is by compiler and one is by an interpreter and in order to do it with a compiler the compiler would have to invent the data structure for saving current reservations and maybe it would have to be smart enough so that reservations that were canceled did not have to be remembered.
On the other hand an interpreter might simply maintain a journal of the events that occurred and evaluate a predicate of "has John reservation" or a function "John's reservation" by doing calculations involving this journal of events that have occurred. So that would be the basic idea of implementation of reference to the past. Now in principle one can also have reference to the future, namely a statement that the baggage handler should be ready a half hour before the flight arrives. In principle this is different from the idea that the baggage handler should be ready a half hour before the plane is scheduled to arrive. What you would like to achieve as much as possible is that they are ready before the plane does arrive and therefore the implementation of such a statement might in its simplest form merely refer to the schedule, in a more elaborate form might refer to other information that becomes available as to when the airplane will actually arrive.
If you allow reference to the future then you can get contradictory programs that have the contradictions like those of time travel, namely you can say: "Well if I am going to do something, then don't do it", but that is just a bad program, possible to write bad programs in any programming language. So these are the main aspects, that I know of, of implementing reference to the past. I think that anyone who actually decides to add it to his programming language that is for example to make a version of C that has reference to the past, would find further complications.
As far as I understand current programming languages it could be added to any of them, maybe some of the ideological constraints in programming languages like Dijkstra's bad idea of eliminating gotos completely, might offer some interference, but I am not even sure of that.
I suppose by that you mean a framework of some structures that are implemented within the language and you could certainly do it that way, but it's clear if you want to do it in the language. Now the reason for referring directly to the past is to save the programmer the necessity of himself inventing data structures, compiler will do it for him and this is particularly important for languages that are to be used by children or by generals.
The other major thing has to do with the speech acts idea. Speech acts were invented by some English ordinary philosophers who didn't like logic because they didn't want to learn it, but anyway the logicians discuss the truth value of sentences, so they were interested in sentences whose content was not necessarily a truth value like: "I now pronounce you man and wife" or the very similar thing "I now sentence you to be hanged by the neck until dead" and a key one is promises and a couple of philosophers, J.L. Austin, an English man, and John Searle, a philosopher from UC Berkeley wrote books on these things.
Their formulations do not exactly suit me, for example Searle in his definition of a promise wanted it to be a requirement that the promiser think that the recipient of the promise will get some good out of it and I don't want to include that so someone promises you a table at the restaurant because it's his job to do so even thought he knows that on that particular the good cook is sick.
So in any case we are interested in promises. Computer programs will and do increasingly operate in a social context or a business context where they buy and sell, and therefore make commitments on behalf of their owners or the people who have paid to use them so they should make only the promises they are authorized to make and in so far as it involves them they should keep the promises. So in particular the airline reservations program that has promised to let you on to this flight should make sure that the people at the gate have the information that you indeed have a reservation. So this has to do with promises.
There are questions and answer to questions and the answer to the question should be truthful and they should also be responsive. So if you ask me "What's Vladimirs's telephone number?" and I were to give an answer that "Vladimir's telephone number is Vladimir's wife's husband's telephone number." that would be an answer that was truthful but not responsive and it's a little problematical to define what a responsive answer is but at least in this case it's that he should in some sense know the telephone number after the question has been answered.
I don't like to specify a timeframe because I've done that in the past unsuccessfully, so I thought that if I defined Elephant 2000 then it would be reasonable that it should be ready by 2005, but here it is 2007 and it's not. From time to time people have talked to me about implementing it and I encouraged them and they ran away and never came back, so I guess they found either difficulties or in the current situation it wasn't very useful to them, but I do think that the two major advantages of Elephant, one of being able to refer to the past conveniently and the other being able to define the correct performance of speech acts will eventually be important and whoever successfully implements them will have an advantage.
Well of course one could just partly related to just natural turnover. If you want a new programming language then it has to be different in some way and one of the ways is making things different from its immediate predecessors is to go back to more different, distant paths and this happens in lots of fields, not merely programming languages. I don't know enough for example about Ruby to know in what way it's related to Lisp. Does it use, for example, list structures as data. So if you want to compute with sums and products, you have to parse every time? So, in that respect Ruby still isn't up to where Lisp was in 1960.
8. So what do you think of the good choices that the software industry has taken the last few decades?
I would say the biggest thing that has been done is to make them more interactive to make it more convenient to write programs that interact with people and also programs that interact with other programs, including programs that were not written to interact together. So the standardization of remote procedure calling for example has been an important thing that needs to be carried further and the speech act idea of programs communicating in speech acts is an extension and of course the object oriented programming was an extension.
9. So what would you think are the bad routes that software industry has taken the last few decades?
Of course things becoming more proprietary is a bad business idea. In particular that fact that the major operating systems, both Windows and the Macintosh operating system are proprietary and even secret because I remember back in the good old days one could make modifications to the operating system freely. So Linux has been a substantial improvement in that respect, but so far as I know in many respects it's not up to the level of things like XEmacs in terms of permitting the user to add their own operating features to the system. Now of course Emacs is merely and editor but nevertheless is does permit significant user modifications and the modern operating systems do not. Let me give an example: one thing that I have done is to add a feature where you can put in a file, the name of another file and even also a location in that file. And then with a single key press it will search forward till it finds its file name and go to that filename in place. And I use it for putting references to email messages in my calendar file. That's just one of the uses of it and I asked about the new Google calendar file. Can you put a reference to email messages in there? And the answer is not only can't the user do it, but even the implementers can't do it, but to me anyway it's very useful. When I receive email about a meeting or a seminar, or something like that, to be able to put a link to the email itself into the calendar file and Emacs permitted me to do that myself, without my even having to become a real expert in the inners of it, and I think this will be important.
If I look back to just before the introduction of personal computers then my ideas for operating systems were focused on time sharing systems and what I'd have done was wanted to make them grandeur and also to make them more user modifiable and then I'd have been startled by the invention of personal computers or at least I was surprised by that it was something that I expected to be, become so cheap. So probably like everyone else I'd have reacted not entirely appropriately, but now what I will say is that when they started with personal computers they said: "We can throw away all that time sharing junk and all those facilities for time sharing and settle for a locating service programs at fixed locations and memory and so forth and this rapidly turned out to have enormous disadvantages and they had to put the time sharing features back in again even in single user systems, since the user wanted to time share his printing and other tasks with his computation and as far as I can tell Microsoft still has bugs that are consequences of not using memory relocation and protection and the way they were used in systems of 30 and 40 years ago.