Transcript

So welcome Dick to the show.

Glad to be here.

Thank you and first of all thanks for organizing this conference. I have found it really nice. So thanks for all the work you've put in.

Yeah, it's a lot more work than the general chair is led to believe at the beginning. I have been working on it for 128 weeks.

Wow, sounds really like a lot of work. So you are also the person who made these rooms available to us. So thanks again for that.

Okay. Good I am glad you could use them.

Yeah absolutely. So why don't you introduce yourself to our listeners a little bit?

So my name is Dick Gabriel. My background is some degrees in mathematics, then Artificial Intelligence at Stanford University. I worked with John McCarthy at Stanford for a few years. I started my own company after that. It was a Lisp company called Lucid and it existed from 1984 to 1994. After that I went to ParcPlace Systems where I did more management stuff by sort of accident. I originally went there to write a book with Adele Goldberg and then they had some development issues and sort of to see whether, the reason that I felt that I was fairly effective at Lucid was that I was the person who hired everyone. I wanted to see whether that was true or false. So I helped them out and after that I went back to school and got an MFA in poetry.

Alright, I will talk about that later a bit.

Yeah and since then I've been at Sun Microsystems and now IBM Research.

Okay cool. So you've already mentioned the topic we are going to focus mainly on in this episode, that is Lisp.

Yeah.

So why don't you give us a little introduction of Lisp in three minutes, what is it all about?

So Lisp has a couple of interesting features. It's one of the earliest languages that was developed; this is its 49th birthday this year.

Cool.

The core of Lisp is a functional language, which means that everything in the language is a function, which means it takes arguments and returns a value and then the way computation is done is by nesting functions. So you call a function with some arguments. It returns a value and that value is the argument to other function calls etcetera, etcetera. It's interesting because the data structure, the primary data structure, but not the only one, the list is also the data structure that encodes the programs and so programs and data are the same. So you can construct Lisp programs, using Lisp programs and execute them at the same time and that was thought to be how artificial intelligence would work. You would have a program that was artificially smart. It would construct programs on the fly and execute them thereby learn or be told things. Since then that's from the early 1960s, since then it's developed into a full fledged kind of a systems programming language. So it had early implantations of threads. There is a built in complier within the runtime, memory managers and operating system interfaces. So typically Lisp programmers feel like they live inside of the language. They live inside a running execution as much as Smalltalk people do.

Right, Yeah... So in addition to having lists and functions as the main abstractions other aspects that are important probably are side effect freeness, right?

As for the functional core yes, but for the non functional core it's an imperative language. So you do have sequencing and so you can do things. So there's a function called PROG, which stands for program, and what the function does is it takes no arguments and then what it does, is it defines some local variables. It then executes a sequence of functions one after the other. All of which probably have some sort of side effect and then it returns the value of the last. You can put labels in there and GoTos and stuff like that it's called the program feature. There is an assignment operator. Now, Lisp is very famous for not using obvious names of things. So the assignment operator is called 'setq' so 'set quote' the reason that it's setq, set quote is that because it's fundamentally a functional language everything is evaluated. So you need something that says, don't evaluate this. So in Lisp if the Lisp interpreter sees a list, it interprets that as a function call where the first thing is the function, everything else is an argument. If you want that thing to be treated as a list you have to quote it. Okay. So there are side effects. There are object oriented extensions. There are arrays and complex numbers and you name it, it's got hash tables on and on and on and on.

So you already mentioned that Lisp has come out of the AI community, can you talk a little bit about the mindset of how things were back then why Lisp became the way it was in addition to just being able to construct itself? What was the grand goal? What was the context?

So the grand goal --and this is probably more my opinion than the accepted opinion-- was that the artificial intelligence people were endeavoring to write programs that no one knew how to write. So it was the idea that you could sort of sit down and say well, here is my problem, here are the requirements. Let me come up with the specification and now code that up completely crazy, as far as the AI people are concerned. They want to sit down and write a program that demonstrates some version of human intelligence, a human behavior. There is no idea and so the only way to do it was to experiment. Well let me try this, let me add that. Let me try to add this fuzzy concept, let me try to add site scheduling, let me add agendas, let me add resources, let me add resource limitations; and so the idea is that you are --always- constructing a system that you hope one day will show some intelligence, but you are not constructing it like making a ton of source code and compiling it periodically. You are constructing it the way you construct a city, you build some of it and it's running all of the time. So it's kind of like a live programming language. I think that's because the task or the work of writing artificial intelligence programs is considered too far away from what people knew how to do

So let's look a little bit more closely at some of the interesting features and one thing that I am particularly interested in is this thing; that is programs as data and data as programs. So that was basically the first, let's say implementation of Metaprogramming.

Yes.

So can you talk a little bit about how this thing works? How do you do this? How do you make a list to become a program?

There are several ways. I'll tell you the classical way and the other ways are refinements to make it work faster. So one of the things --John McCarthy was the guy who was sort of responsible for Lisp, he had the original ideas and he had a team of some grad students. I think six grad students and a couple of other folks who were implementing it back in the late 1950s or early 1960s at MIT at Cambridge, Massachusetts. At that time there was sort of a debate among logicians and mathematicians and computer scientists --but there weren't called computer scientists then-- as to computability. So at that time people were talking about Turing Machines, Von Neumann Architecture and one of the concerns was universal computation: was there a function, was there some mechanism that could compute anything that could be computed. So the Turing Machine was considered that. Now, it was considered that but with the program that the Turing Machine ran which was the Universal Turing Machine which would take description of any other Turing Machine and execute it and it was a big complicated piece of code, basically. So what John McCarthy did was he said, "Well using list structure and this functional kind of idea, the Universal Machine for Lisp is quite short. In fact it fits on about 15 lines of code and it relies on the fact that it's interpreting list structure." So when it sees a list it looks at the first thing. If it looks like it's a function it applies it otherwise it uses a rule. So if it's a conditional, it does the logic of that. It was a very short piece of code and one day Steve Russell said, "Well, you know if I took that piece of code and hand compiled it, then that could be an interpreter for Lisp." So he did that and it surprised John McCarthy and overnight they had a running implementation of Lisp. When he thought it was going to be many, many, many months took one night to implement --this interpreter. So when they saw that they realized that they could use this Universal Machine, which they called Eval, to evaluate a piece of list structure or anything that Lisp has as a program. You could then construct any list you want and then hand that as an argument to Eval and then that would execute it. So that was the beginning of it. It just really surprised people that they could do that so easily.

So that's also this notion of the Meta-circular interpreter, which is I think a really great geeky word. So it's basically a program that --I shouldn't say interpret itself-- but the interpreter is written with the same tools and language as the thing it interprets.

Right. It took a lot of people a long time to understand the concept of the Meta-circular interpreter as kind of first introduced --or first explained by Brian Cantwell Smith in the -- I think mid to late 1970s. So I mentioned that this universal function Eval is written in Lisp. So what Steve Russell did was he hand compiled it. So you would think well okay, so Eval is written in Lisp. So that means that when Eval is executing, it's actually executing itself. So there's this concept of you have a base level program, which is what Eval is interpreting and then Eval is up one level and it sort of looks at the list structure and interprets it. Now, Eval is in Lisp so you can imagine that it's at another base level and that there is another copy of Eval above and it's like that all the way to the top. So that's the Meta part. It's circular in that the language that's implemented in is the language it's interpreting and the trick though is at the top --you don't go all the way up forever. At the top you need something like, what Steve Russell did, which is a compiled version of it. So what that is --it's a process that's exactly like what Eval does-- but it isn't Eval itself it's in something that the physical world can interpret.

A, C program.

It could be a C program, it could be machine language. Now, one of the tricks the people use, and you can confuse people --who are extremely Smart-- with this the way that a lot of interpreters are actually written is they write a Lisp compiler and then they write the classical Eval which is like a page or so of code and then you compile it. So consider the definition of car. So remember I said that Lisp uses interesting names for things. So if you have a list --the first element is-- you can access it with the Lisp function whose name is car. So if I have the list 1 2 3 then car of that list, car of 1 2 3 is 1. So that has to do with contents of the address register as the original machine and cdr means give me the rest of the list and that's contents of the decrement register. So it's using registers--

It's 'c' 'd' 'd' 'r' right? --

Well 'c' 'd' 'r'.

'c' 'd' 'r'. Oh yeah.

So that gives you the rest of the list, it strips off the first element. If you want to strip off the second element: cddr, if you want to strip off the first three -- CDD's(inaudible) so you can have any number of these. So you can sit in front of a Lisp system and type in what's called S-expressions, these lists that are interpreted as code. You type them in and they get Evaled, evaluated right away. So you can type in car of quote 1 2 3, the list 1 2 3 and it works. So that means the function car has a definition, someone wrote the code for it. So the definition that is actually used is defun. So defun is how you define a function, defun car --it's the name of the function-- then you say it takes one argument X and then its definition is car of X; and you go "but wait, how can that work?" because it's recursive. So you are defining the function car and how do you do car, you call car so if you keep on doing that it's going to loop forever. However what happens is the compiler sees this definition, it opens code that is to say it emits machine instructions when it sees car. It doesn't care that the name of the functions it's compiling is car. So when you define the compiler, you define a few things like car, how that compiles, how conditionals etcetera, etcetera and so these sort of Meta-circular looking definitions look ridiculous because they all look like they are infinite recursive --

But they are resolved by the compiler.

And they resolved by the compiler which sort of bottoms out this or tops out this tower of Meta circularity.

One thing that has always -- well that some people consider a criticism of Lisp, others say that's really its essence, it's that it basically has no syntax. I mean you more or less literally write the syntax stream, form of lists.

Right.

So that also makes it possible that a user defined function looks exactly the same as built in stuff, which gets to this concept of growing a language that Guy Steele had in one of his famous talks that's online on Goggle Video we will put a link to it.

Yeah, you should all listen to that.

Yeah. We will put a link to it in the show notes. So can you talk a little bit about the idea of growing a language and how that plays into Lisp?

Yeah. So that was another extraordinarily important thing, which I believe was an accident. In that as you mentioned any function that is in Lisp, the syntax for using it is identical to as if a user did it and then you needed some special other forms as well so, conditionals. So the way that Lisp interpretation normally works is you get a list; it looks at the first thing and says, "aha, it's a function". Then it evaluates its arguments then it passes those things as arguments to the function that is the first one. So now if you have a conditional, so if you say left parentheses if then some predicate and then if it's true and if it's false, two separate things. We can't do that that way because that would say, "Okay I got If, so I evaluate all three things, the predicate, the true part and the false part," but you didn't want to do the false part. So we need some sort of a special form. So in Lisp there are special forms that are interpreted specially and users can define those using macros. So what this meant is again this endeavor of trying to write programs that people can't write --artificially intelligent programs. One idea that quickly came to the fore was: Lisp is the wrong language for writing that program. I need a special program to play chess. I need a special program to understand mushrooms, if you wanted a system to classify... I need a special programming language to understand surfaces and so many AI researchers would start their research in some area trying to make a program smart there by defining the language first --that they could express their concepts in-- and so they would immediately extend Lisp. So that it would be easier to write the programs. So a lot of artificial intelligence research in 1960s, 70s and early 80s was: figure out roughly what you want to do, design the language for it, implement it in Lisp --which means that it's an extension to Lisp so it's just defining functions in the special forms-- and then write your great program. But then people would invent these great languages as grad students and their advisers would say, well that was a lot of work and that language you devised was really interesting, why don't you write that up as your dissertation and so people would write -- would start in some AI project for their Ph.D. and they would end up publishing a language definition instead.

And the funny thing was that-- well today you would say maybe that isn't really a different language it's basically, we will call it a framework because it defines functions and procedures. So it's a bit different from what people today consider language and DSL development because there is no notion of adapting the syntax because everything looks like trees

Right. So the other nice thing is when you are a normal --let's say-- language designer you have to worry about the syntax and though there are tools to make it really easy you still have to worry about parsing. Well you don't have to worry about parsing. So Lisp has this uniform thing: the first thing is either a special form or a function and blah, blah, blah just 15 lines of code. So you don't have to worry about that you just worry about the expressiveness of your stuff.

What you write.

Yeah.

I mean if I were a critic or a cynic I would say: you could do this with XML today and everybody would say wow that's ugly you can't use that because it's basically --literally-- a tree. So the limited set of primitives and doing everything the same way is very elegant, but it's not necessarily user friendly. If you consider a user to be some non programmer, which is what DSLs tend to be focusing on.

Yeah that's largely true. XML to me maybe I am naive about it

But it wasn't a serious suggestion

Right. But XML to me is verbose and so you would have some left angle brackets and some complicated thing. Right angle brackets and blah, blah, blah and another set of angle brackets. Those angle brackets are really just left paren, right paren so it's more compact. There are some systems, so for example the text editor Emacs is a very simple engine and all of the commands that you do --that users use-- actually are written in Elisp, a dialect of Lisp. If they are not naive users --who are using Emacs-- but they are not AI people, they are not Lisp programmers and so it's a very compact language you can get a lot of things. So people less expert at programming in Lisp than you would think have found (Inaudible) --normal people, no domain experts, no--, so I agree with all of that. The other thing that's about Lisp is that Lisp has a type system. Some people think that: oh Lisp is not a typed language --I guess there is some controversy about the terminology. So what I learned in school was that the term "strongly typed" meant that: no operation would be permitted to be carried out on arguments of the wrong types. So that's usually interpreted as the compiler won't produce code for that, but in Lisp that's interpreted as: when you try to do that at runtime it throws an exception.

What you are getting at is that there is a difference between strong and weak typing and static and dynamic typing.

That's right.

So Lisp is a strongly typed, dynamically typed, strongly typed language.

That's right. So what that means, and this is useful for beginners I think because beginners use ,would use BASIC, they would use LOGO, they would use a bunch of other small languages like that and their programs are not verbose because it's telling the compiler about types everywhere. The types are done at runtime and so how do you make X, the variable X, refer to a floating point number. Well, you don't declare that X --is going to hold it-- and then you type in the thing, you just say setq X to 3.14 or 15, blah, blah, blah and then you can ask at runtime, what is the type of X, what x refers to? It says, well, it's a floating point number. So that makes it a little more compact, which might make it easier for end users, but again I wouldn't say let's try it on them. Someone has to try it on, but it's not an argument I would make.

Can you briefing explain what macros are, we already mentioned it on while explaining some of the Meta stuff.

So in most languages, so for your listeners, if you think of macros it's a string type of operation. So you see some sort of pattern of strings in front of you --the compiler does-- and says well this is a macro and it does a string substitution to what the macro means. So in Lisp, it's like that only different. So what the interpreter does and so the compiler mimics the semantics of the interpreter. Suppose you define the macros zetash (ph) and so zetash (ph) is going to be a complicated control construct that's going to spawn a bunch of processes and monitor them in a particular way and provide locks and all those complicated things. So you are going to write left parens zetash and then some complicated stuff. So you define that as a macro, you say: def macro zetash (ph) and then you write a description --sort of a pattern of what the different components of this expression is going to look like-- and then, what it does is it then, you write Lisp code that produces the expression that you want. So the interpreter and the compiler then when it sees a zetash (ph) expression, it will run this code that you wrote that will return as its value a piece of list structure and then either the interpreter will use that in place of the zetash (ph) expression or the compiler will compile the result. So what that means is you always have sort of syntactically meaningful units in your macros. So you don't have to worry that you left off a bracket or a comma or something like that, you always going to produce something that's at least a list.

Which is different from C's preprocessor -- for example you could do anything.

That's right you can put in anything, in fact with C's preprocess I believe you can define the -- I don't know C so well so you could tell me if it is wrong or your listeners can laugh their heads off. I believe you can have the name of the procedure or the function that is returned, be constructed from text from multiple files. So you can even easily figure out what the name of the thing is going to be.

I don't know that one either.

Yes. So you can't do that with Lisp. So you have this sort of syntactically, easy to get right form and it's through macros primarily that people define these sort of domains specific type languages on top.

Right. So you mentioned at the beginning that Lisp is at its core primarily a functional language. You also said that it has object oriented notions in it and there is specifically the CLOS (transcript note read KLOS) or CLOS (transcript note read SEE-LOS) --I don't know actually how you pronounce it-- that accommodates Lisp object system. So can you talk a little bit about how people got from Lisp to KLOS or SEE-LOS and what the differences are and maybe what flavor of OO it has?

Yup. So as a long history to this one of the important early meetings for object people was I believe it was in either 1971 or 1972 maybe 73. Alan Kay visited the MIT AI Lab and they talked to each other. And they both learned a lot, Alan Kay was always kind of a Lisp fan I believe in the 1960s. They exchanged a lot of ideas, so at that time MIT was a hotbed of Lisp implementation. So they got kind of interested in it. So Carl Hewitt developed the Actor language, which is a little bit different from --I think there is another actor dialect that came after that. In Plasma there were ideas of combining the functional part of Lisp with the object oriented part of something like Smalltalk with Logic Programming, but the real kind of breakthrough of how objects and functions were related came when Guy Steele and Gerry Sussman were trying to understand Carl Hewitt's Actor language. So the Actor language is a message passing system and so they figured they could try to understand the concepts by writing an interpreter for a dialect of that which is very Lispy and so they extended Mac Lisp to have a language that they were trying to understand what is message passing, what is an object and that language became known as Scheme.

I was about to ask that, yes.

So that got to be known as Scheme and what they did was they wrote an interpreter like what I just said earlier, so it's a short program and they thought well in order to capture some of the essence of what an object is, what they wanted to do is an object is really like a function that has no name perhaps and it gets as an argument, a message and then it looks at the message and decides what to do. But in their interpreter they had a separate branch for is this function versus is this an object I am sending a message to, and so they wrote some different code for each and then as they refactored the code --they didn't have that term back then-- they noticed that these two versions of Eval were exactly the same actually Apply were exactly the same. Then they realized, oh message passing is a form of function calling or function calling is a form of message passing and objects are a form of functions, or functions are a form of objects. So they've made that conclusion, but sadly or happily I don't know, people rapidly forgot that because they thought Scheme was so cool because it had these called Lexical Closures. So another concept in Lisp is this first classness and so that means that anything that exists in the language can be returned as a value, passed as an argument, stored in array, so you can do that to functions, you can do that to objects, but soon thereafter a lot of different experimentation along with different types of object oriented extensions. So there were loops, there were common loops, I forget all their names. Some of them were message passing and then someone came up with the idea --with a couple of ideas-- one was to: if you have message passing, then you are sending a message to one thing. So if you think about Lisp you say, well message passing is like a function call. So the object is the function and I'm going to send it a message and that message is one of the arguments, but you might send it some other arguments. So people started to write methods basically and objects that would sort of look at the first argument at runtime and decide which method to use. But when people looked, they saw that the method called, the message sent that's invoking the method if it had more than one argument, it look like send message to Foo A B C D four arguments. They said well, Steele and Sussman taught us that the send message doesn't count. So I can take the object Foo and make it the first thing --so that's the name of the function-- and and then you have got A B C D and the first argument is treated specially, but why? Why is the first argument special? So they started to think: well may be at runtime you would look at all of the arguments and you would invoke the method that was most appropriate for all of them. And the example they used was, suppose that you are drawing something on a display. So the classical way of doing that is you send a message to the object and say: display yourself. So then that thing has to figure out well what about the display? Is it a piece of paper, is it a printer, is it a handheld device --they didn't have them then. They had handheld devices, but they weren't electronic --so like a spoon and stuff like that. So they said, well it's kind of goofy to ask an object to think about a display even if they could do it very abstractly. So they would say, alright so I want to define a method that when it's handed an object of this class and you want to display it on a display of this type then it would just go right to the code. So that was called generic functions. So a generic function is --the arithmetic functions in Lisp are like that. So you can say plus, and an integer --or int-- and a real number and it figures out what code to run --sort of do the conversion, etcetera on its own. So they just generalized that, so CLOS which became the dominant sort of object oriented thing has that. So it has multi methods, which are methods that are defined. Then because when you have multiple objects --that sort of-- participate in selecting a method, you don't really associate the method with the object.

With one thing, there is no special this thing.

There is no special this, so what you do is you associate with the generic function, which makes sense in some ways. And then ideas that came along at the same time were multiple inheritance and so that came from a guy named Howard Cannon in Flavors which is-- he sort of thought a little bit like aspects are sort of thought of today, there is some kind of functionality, sort of the main functionality, that you want to add something on. You want to add a lock to some object. So that when you operate on it, you lock it, so no one else can, you operate and you unlock it. So he invented these Mixins. So that you could -- before you do it you do the lock, and after you do it you do the lock, but he didn't want that code to be sprinkled throughout. So he defined these things which are before and after methods which are kind of what you see in aspects. So multiple inheritances was used for doing these Mixins. So the intention was you would have a main sort of single inheritance hierarchy for your main thing and then if you wanted to have different Mixins they would have their own hierarchy. So that they would not be blended, but to generalize it they blend it, so they would have multiple inherence which made things complicated.

Yeah. And the Mixins typically had then this before and after things that would kind of enhance the primary structure.

That's right. So the terminology they used was, there was the primary method and then there were before and after methods. Again, Lisp people like to generalize, they said, well that's just one type of method combination. It's called method combination, so you have before methods that might apply, after methods that might apply or you might have something that's interposed. So if you have a certain argument, certain object you are sending the message to --logically-- then you might say: well in this case instead of using the usual thing I will do something instead and those are called 'round' methods. So that was called standard method combination, but you could have any kind. So what you could do is you can say: well if I invoke this generic function what I want to do is run all of the methods that apply and we assume that they return numbers will take the average or will add them up. So you could define any type of method combination that would examine what methods were going to use and what the classes were and this is all part of this Meta-circular type reasoning, very elegant, very complicated.

That led to this Meta object protocol thing which would probably be a separate episode I think.

Right, it's a big topic.

Yeah. You already mentioned Scheme and the term CLOS (transcript note read KLOS) or CLOS (transcript note read SEE-LOS), it's difficult what you called it?

I called it CLOS (transcript note read SEE-LOS).

Okay.

Most people gravitate to that these days, but CLOS (transcript note read KLOS) is also used.

Okay. The CL stands for Common Lisp, right?

Yeah.

So can you briefly mention which significant Dialects or Derivations of Lisp exist. Scheme, CL?

Well, the primary ones these days are essentially just Common Lisp and Scheme are the two. Back in the 70s and 80s because of the AI Labs, The Artificial Intelligence Labs were separate. There was only rudimentary Internet at that time, called the ARPANET not everyone was on it and that meant that every lab developed their own dialect of Lisp and so there was Low Lisp and Standard Lisp and MAC Lisp and Stanford Lisp and UCI Lisp and on and on I could go on for hours for all, just the names of them. Common Lisp was an endeavor to unify them. So all of those AIish type of Lisps became Common Lisp and so many people liked Scheme because it was small and elegant and it wasn't so side effecty and they went off on their own so they developed different dialects of Scheme.

Yeah so I think this imperative stuff you talked about before is something that is more or less in Common Lisp but not in Scheme.

Well they do have it but they don't -- it's just downplayed.

Okay.

They try to write in a more functional way. So the manual for Common Lisp is 600 pages, the manual for Scheme --well Scheme just got a lot bigger recently-- but up until one or two years ago. It was like 30 pages so it is easier and there were some other concepts in Scheme that caught on so there is this thing called continuation.

Oh right, yeah. It's a hot topic these days in web development and Java.

That's right. So what a continuation is, suppose you are doing a computation and suppose you are producing a list of things or suppose you are during a web transaction, so you might want to sort of return a value now, but reserve the right to sort of go back to where you were. So that's what a continuation is. A continuation is something that gets returned --it's a function-- and it says that if you invoke that function on an argument then you return to where that continuation was and you resume.

You kind of save the computation somewhere and go back there.

Save the computation. So cookies are sort of a silly way of implementing continuations. So there are some Web servers written in Scheme where continuations basically get passed back and forth. Now they pass tokens instead to refer to the continuations, but the server will hold a continuation etcetera.

Like Seaside in Smalltalk does the same thing.

Right yeah exactly. So Common Lisp doesn't have that --another big distinguishing feature. The macros are a little bit different, there are some technical problems that I am sure your listeners don't want to hear about, but if they wanted to know what the heck I am talking about just Google for or AltaVista for or Yahoo! for --or whatever-- Hygienic macros and that will tell you more than you want to know.

I also think that Laurence Tratt mentioned that in the episode on Compile-Time Metaprogramming with Converge, he also has something with Hygienic macros.

Yeah, yeah

Okay. Let's get a bit more practical in a way that we stop talking about concepts and theory; where is Lisp used these days and maybe if I were a cynic I would say why isn't it used much these days? What's the state of Lisp today?

So Lisp is used I guess I would say sporadically. It's still used in some, but not a huge amount of AI research. There are some commercial endeavors that are using Lisp so for example, there's a company in Lexington, Massachusetts they are called ITA, I don't know what the ITA stands for I apologize for that. And Dan Weinreb is one of the folks there. They are putting together and I guess they have deployed an Airline Reservations System written in Common Lisp. So there are couple of companies like that Yahoo! Store sort of does this thing that enables people to produce stores, storefronts, it's written in Common Lisp. Some specialized, like some vision, computer vision stuff is written in Lisp. Some robotics stuff is written in Lisp and it's just sporadically here and there, but commercially it's still viable. There are still some Lisp companies out there that produce implementations, all open source.

It didn't catch on as a mainstream, was it maybe because it is too flexible, too powerful or is it because it doesn't have curly braces as some folks say?

Well there are a lot reasons for that. Your listeners who have a certain age will be completely surprised to learn that in the early to mid 1980s Lisp was the Java of its day. The people, the investors in the business community thought that Artificial Intelligence was really going to take off with Expert Systems and all that. So the language of Expert Systems was Lisp and AI was going to take over the world and so I believe there was a BusinessWeek cover article about Lisp and Forbes had articles about Lisp. I and others were on radio programs and all sorts of stuff talking about Lisp because it was so --

So you are again on a radio program now.

Well it's happened again, It's come back around. So two things happened or-- two things converged one was what I call AI winter. I can't remember if I invented that term or Earl Sacerdoti did. It was during an interview that he and I did, it's kind of like this one, where toward the end of 1980s, the AI companies were really good, hyping what they could do and they weren't so good at delivering business results. So a lot of the companies said well it's because we are using Lisp. Lisp is not statically typed and so it's a little bit big and it's a huge, huge, huge language, the runtime for Common Lisp is 3 megabytes. So your listeners should be laughing now because what is the average size of a Java program these days, 150 billion gigabytes or something. So 3 megabytes back then was considered completely outrageous. Because it didn't have static typing, static typing was optional in Common Lisp that meant that the compiler had to produce code that always check the types, so it goes a little slower. So it was slow, it was hard for beginners to write good code and so you needed really good wizard level, very expensive programmers there weren't very many of them. So it was slow, it was big, complicated sort of more oriented towards mathematicians than practical people and all of that kind of conspired for Lisp to roughly disappear for most of 1990s.

Is there any Lisp hidden in any of today's languages? Is there any worthy successor of Lisp maybe or what's going to happen with Lisp in the future?

I think that you can see the influences of Lisp in lots of places. So Ruby certainly, I think, owns quite a depth.

It's Metaprogramming facilities.

Any of the garbage collected languages, Lisp had a garbage collector in 1958, 1959 and had garbage collection throughout and so Alan Kay said of course Smalltalk would have garbage collection. That's been adopted by Java and that's sort of a major reason for it's kind of success I think for some types of programs in some applications. Lisp is used sometimes in the extension language, it used as a scripting language in some situations. I think in Europe, you can talk this to people like Pascal Costanza folks like that it's getting a little bit of a resurgence starting to be used for more exploratory stuff in universities and some companies. I would like it to see a little bit of a comeback because it's a very nice language from my point of view to do language research experimentation.

Absolutely yes.

So I think it might have a little bit of resurgence, but I think the main influence will be through the ideas that's spread.

Let's talk a little bit about you. You recently mentioned, moved from Sun to IBM. So what did you do at Sun and why did you go to IBM and what do you do there?

Yeah. So let me tell a bit more of the story that might be of some interest to the listeners mostly because it's a fun story for me to tell because I'd like to tell, it might sound interesting. So in the 1995 for one reason or another I decided to go back and get a degree in poetry. So that's when I went to ParcPlace systems so I went to school in low residency MFA program. My company had failed, Lucid had failed in 1994 and so my goal was, my plan was I'd go back for a couple of years get an MFA. And then go back to doing language research using Lisp. So I went off and kind of didn't pay any attention to computer science stuff from 1995 to 1998. When I came back basically all of my research fields were deleted. There was no longer possible to do research, there is no place that I could do research using Lisp. There is no place I could do research in Lisp, on Lisp. I couldn't -- there's no departments, the university departments that would hire me, there were no companies that did it. There were no conferences for it anymore, they all got taken over by the functional programming guys. There were no journals that I could publish in and you can imagine if you are sort of an academically minded person to go away for a couple years and have your entire field deleted.

Yeah it is frustrating.

So it was quite frustrating. So at that point I said, okay well I will just consider myself a poet supporting myself by working in the computer industry. So Bill Joy called me up and he wanted me to do some consulting for him. So Bill Joy is one of the founders of Sun. He had a lab at Aspen called Aspen Smallworks. He had two projects he wanted me to consult on. One was supporting Christopher Alexander implementing some of his new ideas on what he calls The Nature of Order. So I served as adviser to Bill Joy who was funding this. The second on was to help with this project that Bill Joy basically wanted to become Open Source. So the Alexander thing kind of went away quickly, but then I started to work with Bill and Sun on making this one project Open Source. And then once that had a little success, I would say getting that project to be Open Source, he decided that Sun should move toward Open Source. So I spent -- how long was I at suns? So from 1999 till this last February, so that's some number of years. I was mostly converting the company to Open Source company. So learning and teaching about the licenses, teaching how to build communities, trying to figure out how companies could participate in Open Source because this really was not like what the Open Source was about, teaching management, coming up with business strategies. Eventually my colleague and I, Ron Goldman wrote a book on that, which is kind of, sort of like a handbook for businesses on how to do Open Source and what it all means.

Okay. We will put a link to it in the transcript.

Yeah, and so being an open source book, it is available online for free.

Great.

But you can also buy it and so there is a -- I am not sure there is a PDF of it, but certainly HTML version of it that's easily available. I think Open Source books have to be that way. When we sort of succeeded when Ron Goldman the co-author and I succeeded in that we went back into Sun labs to work on some research on keeping what we call it self sustaining systems, how to marry traditional programming with some biological concepts to sort of keep programs alive to sort of solve some problems on both sides of that equation. Sun labs is a very old fashioned type of lab. It's very engineering oriented lab and they were not as friendly I would say toward a project that was very expensive like that. So it just felt a little bit like that they had liked what I was doing, but I just felt like maybe I should be somewhere else. So I like Sun a lot and so in February of this year I moved to IBM Research, where I think there's a little more freedom, it's a bit bigger company and it has a little bit more resources. They seem to understand. So I was the general chair of OOPSLA and as I mentioned the 128 weeks. So if you can do the math that's like more than two years.

Yeah. You mean it was fulltime?

So it was fulltime for me for the last since June 1, so July, August, September, October and November 5 months of fulltime, Five months of halftime, then three quarters time and then the rest of the months were about 25% time. So that's big because OOPSLA is complex. I am sure you have been gathering that from these interviews.

Yeah. You are working on this ultra large scale systems stuff?

Right.

We have had an episode on that stuff.

Yeah. That's right. So couple of years ago I joined this task force that was looking at --task force sounds like really a military thing-- but a study group for ultra large scale so what would it mean to have a system of a billion lines of code for example. How do you put that together? Would there be an architect? Could there be a single mind that conceived of it. So I work on that, I work on some self sustaining systems stuff and I do some public services things like OOPSLA.

Cool. So to wrap this thing up do you want to briefly talk a little bit about your poetry side and how you think poetry, literature should go or should be of more importance in the software field and this kind of stuff?

Yeah. There are a couple of aspects of that. I didn't have a literature background when I went back to school and learning writing and sort of learning about creativity was not what I expected. The thing that was surprising about it is that it could be taught more or less and it's taught by a way of teaching and not by the subject matter or not content that sort of thrown at you. The way you learn is sort of creating and revising and examining other creations, while reflecting, while thinking about it, while writing about what you're doing and what you see. The other thing that I found out was that creativity comes from having a sort of diversity of ideas and background putting together --you know synthesizing things. I think all of that applies to science that the methods of teaching, the way you teach writing, the way you teach art should be used for teaching design, software design and stuff like that. So I have been working a little bit on creating an MFA of softwares, an MFA of design for that. Also, I think a lot of the ways of doing exploration, the whole concept of getting lost in order to discover. I think it applies to the work we do as technologists, engineers and I think it's quite informative. Writing poetry itself is quite an interesting enterprise because you need to open yourself up to the type of observation that you can learn how to do that is, it's not that commonly used or not consciously used in the software world or computer science world. The way I sort of starting to talk about it these days it's sort of -- the influence of chaos on reason. So going back sort of to an AI way of thinking about things, imagining I had like a theorem prover that was trying to reason about chess or doing something like that and running at the same time and same address space was this sort of rapidly associative program that just sort of every time the rational part was trying to prove some thing or looking at a concept then this other thing would shout out anything that was related metaphorically or sort of linked together. That's what creativity in the poetry world feels like that there is this chaotic thing that's going on that you sometimes pay attention to and it just informs you. So I am trying to sort of spread that idea and get other people to work and think that way because I think it would help them. So that's the thing. The other thing that's interesting about this -- for the last seven years I've written a poem a day.

Cool, yeah I have seen that on your website.

So in the poetry world the idea of writing a poem a day for a week is more than most poets can bear. Writing a poem a day for a month is considered impossible. There is one or two people who have done it for a year and doing it for seven years in a row --

Quite a difficult work.

I've gotten to a place in what it's like to write poetry, I am not a great poet, that the poets that I know who are good poets say when I talk about my process now, it's so different from what they do that they want to understand it because no one has gone that far with it.

We will put a link to some of them.

Yeah. I think that scientists and artists need to get together more and help each other out because we are all interested in the same things ultimately.

One last thing is worth mentioning is that I think it was you who introduced the Writers Workshop concept known from literature into the patterns community.

Yeah that's right.

So that's another kind of crossbreeding (ph) of these different worlds. Thank you Dick, anything else you want to say before we shut this down?

I really enjoy Software Engineering Radio as you know, or your listeners know. We used you for doing some Podcasts for OOPSLA.

Thank you for it.

I just love the way you do this.

So that is of course really good to hear. Thank you Dick for these nice words and thank you for the interview. I know you have been very busy at OOPSLA and you still found the time to talk to us. Thank you very much. Before we shut down this episode I want to play a song. It is called God Wrote in Lisp. It's obviously about Lisp. I've gotten to know this song during the talk Dick and Guy Steele gave at OOPSLA. It was called 50 in 50 it was about fifty different interesting features and fifty programming languages over the last years. Really, really great talk standing ovations at the end. So the song I am going to play it's from the Roundworm album by Prometheus Music and Eli Goldberg from Prometheus Music allowed us to use it on the Podcast. It's performed by Julia Ecklar and the lyricist is Bob Kanefsky. Have fun listening to it and talk to you at the next SE Radio Podcast episode. Bye.