It looks like you're new here. If you want to get involved, click one of these buttons!
ELIZA Code Critique thread
Thread Leaders: Jeff Shrager, David Berry, Mark Marino, Jeremy Douglass
Title: ELIZA
Language: MAD-SLIP
Year: 1965
Author: Joseph Weizenbaum
System: IBM 7094
Dearly Beloved,
We are gathered here to analyze a version of Joseph Weizenbaum's original source code for ELIZA, recently discovered in MIT’s archives. You can read more about it [here].
Code below in Spoilers. But also in a syntax highlighted version by @DavidBerry
$s changed to "s
.EQ., etc. expanded to =, etc.
' abbreviations written out
continued lines (with a 1 in column 7?) wrapped together
line numbering removed
Added lisp-like comments (;;; ;; and ;)
EXTERNAL FUNCTION (KEY,MYTRAN)
NORMAL MODE IS INTEGER
ENTRY TO CHANGE.
LIST.(INPUT)
Vector Values G(1)="TYPE","SUBST","APPEND","ADD","START","RANK","DISPLA"
Vector Values "NUMB = " I3 *"
FIT=0
CHANGE PRINT COMMENT "PLEASE INSTRUCT ME"
LISTRD.(MTLIST.(INPUT),0)
JOB=POPTOP.(INPUT)
Through IDENT, FOR J=1,1, J> 7
IDENT Whenever G(J) = JOB, Transfer To THEMA
PRINT COMMENT "CHANGE NOT RECOGNIZED"
Transfer To CHANGE
THEMA Whenever J = 5, Function Return IRALST.(INPUT)
Whenever J = 7
Through DISPLA, FOR I=0,1, I > 32
Whenever LISTMT.(KEY(I)) = 0, Transfer To DISPLA
S=SEQRDR.(KEY(I))
READ(7) NEXT=SEQLR.(S,F)
Whenever F > 0, Transfer To DISPLA
PRINT COMMENT "*"
TPRINT.(NEXT,0)
PRINT FORMAT SNUMB,I
PRINT COMENT " "
Transfer To READ(7)
DISPLA CONTINUE
PRINT COMMENT " "
PRINT COMMENT "MEMORY LIST FOLLOWS"
PRINT COMMENT " "
Through MEMLIST, FOR I=1 , 1, I > 4
MEMLST TXTPRT.(MYTRAN(I),0)
Transfer To CHANGE
End Conditional
THEME=POPTOP.(INPUT)
SUBJECT=KEY(HASH.(THEME,5))
S=SEQRDR.(SUBJECT)
LOOK TERM=SEQLR.(S,F)
Whenever F > 0, Transfer To FAIL
Whenever TOP.(TERM) = THEME, Transfer To FOUND
Transfer To LOOK
FOUND Transfer To DELTA(J)
DELTA(1) TPRINT.(TERM,0)
Transfer To CHANGE
FAIL PRINT COMMENT "LIST NOT FOUND"
Transfer To CHANGE
DELTA(2) S=SEQRDR.(TERM)
OLD=POPTOP.(INPUT)
READ(1) OBJCT=SEQLR.(S,F)
Whenever F > 0, Transfer To FAIL
Whenever F <> 0, Transfer To READ(1)
INSIDE=SEQRDR.(OBJECT)
READ(2) IT=SEQLR.(INSIDE,F)
Whenever F > 0, Transfer To READ(1)
SIT=SEQRDR.(IT)
SOLD=SEQRDR.(OLD)
ITOLD TOLD=SEQLR.(SOLD,FOLD)
DIT=SEQLR.(SIT,FIT)
Whenever TOLD = DIT AND FOLD <= 0,Transfer To ITOLD
Whenever FOLD > 0, Transfer To OK(J)
Transfer To READ(2)
OK(2) SUBST.(POPTOP.(INPUT),LSPNTR.(INSIDE))
Transfer To CHANGE
OK(3) NEWBOT.(POPTOP.(INPUT),OBJCT)
Transfer To CHANGE
DELTA(3) Transfer To DELTA(2)
DELTA(4) Whenever NAMTST.(BOT.(TERM)) = 0
BOTTOM=POPBOT.(TERM)
NEWBOT.(POPTOP.(INPUT),TERM)
NEWBOT.(BOTTOM,TERM)
Otherwise
NEWBOT.(POPTOP.(INPUT),TERM)
End Conditional
Transfer To CHANGE
DELTA(6) S=SEQRDR.(TERM)
READ(6) OBJCT=SEQLR.(S,F)
Whenever F > 0, Transfer To FAIL
Whenever F <> 0, Transfer To READ(6)
OBJCT=SEQLL.(S,F)
Whenever LNKLL.(OBJECT) = 0
SUBST.(POPTOP.(INPUT),LSPNTR.(S))
Otherwise
NEWTOP.(POPTOP.(INPUT),LSPNTR.(S))
End Conditional
Transfer To CHANGE
End Function
R* * * * * * * * * * END OF MODIFICATION ROUTINE
TPRIN
EXTERNAL FUNCTION (LST)
NORMAL MODE IS INTEGER
ENTRY TO TPRINT.
SA=SEQRDR.(LST)
LIST.(OUT)
READ NEXT=SEQLR.(SA,FA)
Whenever FA > 0, Transfer To P
Whenever FA = 0, Transfer To B
POINT=NEWBOT.(NEXT,OUT)
Whenever SA < 0, MRKNEG.(POINT)
Transfer To READ
B TXTPRT.(OUT,0)
SEQLL.(SA,FA)
MORE NEXT=SEQLR.(SA,FA)
Whenever TOP.(NEXT) = "="
TXTPRT.(NEXT,0)
Transfer To MORE
End Conditional
Whenever FA > 0, Transfer To DONE
PRINT COMMENT " "
SB=SEQRDR.(NEXT)
MEHR TERM=SEQLR.(SB,FB)
Whenever FB <0
PRINT ON LINE FORMAT NUMBER, TERM
Vector Values NUMBER = "I3 *"
Transfer To MEHR
End Conditional
Whenever FB > 0, Transfer To MORE
TXTPRT.(TERM,0)
Transfer To MEHR
P TXTPRT.(OUT,0)
DONE IRALST.(OUT)
Function Return
End Function
LPRIN
EXTERNAL FUNCTION (LST,TAPE)
NORMAL MODE IS INTEGER
ENTRY TO LPRINT.
BLANK = " "
EXECUTE PLACE.(TAPE,0)
LEFTP = 606074606060K
RIGHTP= 606034606060K
BOTH = 607460603460K
EXECUTE NEWTOP.(SEQRDR.(LST),LIST.(STACK))
S=POPTOP.(STACK)
BEGIN EXECUTE PLACE.(LEFTP,1)
NEXT WORD=SEQLR.(S,FLAG)
Whenever FLAG < 0
EXECUTE PLACE.(WORD,1)
Whenever S > 0, PLACE.(BLANK,1)
Transfer To NEXT
OR Whenever FLAG > 0
EXECUTE PLACE.(RIGHTP,1)
Whenever LISTMT.(STACK) = 0, Transfer To DONE
S=POPTOP.(STACK)
Transfer To NEXT
OTHERWISE
Whenever LISTMT.(WORD) = 0
EXECUTE PLACE.(BOTH,1)
Transfer To NEXT
OTHERWISE
EXECUTE NEWTOP.(S,STACK)
S=SEQRDR.(WORD)
Transfer To BEGIN
End Conditional
End Conditional
DONE EXECUTE PLACE.(0,-1)
EXECUTE IRALST.(STACK)
FUNCTION RETURN LST
END OF FUNCTION
TESTS
EXTERNAL FUNCTION(CAND,S)
NORMAL MODE IS INTEGER
DIMENSION FIRST(5),SECOND(5)
ENTRY TO TESTS.
STORE=S
READER=SEQRDR.(CAND)
Through ONE, FOR I=0,1, I > 100
FIRST(I)=SEQLR.(READER,FR)
ONE Whenever READER > 0, Transfer To ENDONE
ENDONE SEQLL.(S,F)
Through TWO, FOR J=0,1, J > 100
SECOND(J)=SEQLR.(S,F)
TWO Whenever S > 0, Transfer To ENDTWO
ENDTWO Whenever I <> J, Function Return 0
Through LOOK, FOR K=0,1, K> J
LOOK Whenever FIRST(K) <> SECOND(K), Function Return 0
EQL=SEQLR.(READER,FR)
Whenever EQL <> "="
SEQLL.(READER,FR)
Function Return READER
Otherwise
POINT=LNKL.(STORE)
Through DELETE , FOR K=0,1, K > J
REMOVE.(LSPNTR.(STORE))
DELETE SEQLR.(STORE,F)
INSRT NEW=SEQLR.(READER,FR)
POINT=NEWTOP.(NEW,POINT)
MRKNEG.(POINT)
Whenever READER < 0, Transfer To INSRT
MRKPOS.(POINT)
Function Return READER
End Conditional
End Function
DOCBC
EXTERNAL FUNCTION (A,B)
NORMAL MODE IS INTEGER
ENTRY TO FRBCD.
Whenever LNKL.(A) = 0, Transfer To NUMBER
B=A
Function Return 0
NUMBER K=A*262144
B=BCDIT.(K)
Function Return 0
End Function
ELIZA
NORMAL MODE IS INTEGER
DIMENSION KEY(32),MYTRAN(4)
INITAS.(0)
PRINT COMMENT "WHICH SCRIPT DO YOU WISH TO PLAY"
READ FORMAT SNUMB,SCRIPT
LIST.(TEST)
LIST.(INPUT)
LIST.(OUTPUT)
LIST.(JUNK)
LIMIT=1
LSSCPY.(THREAD.(INPUT,SCRIPT),JUNK)
MTLIST.(INPUT)
Through MLST, FOR I=1,1, I > 4
MLST LIST.(MYTRAN(I))
MINE=0
LIST.(MYLIST)
Through KEYLST, FOR I=0,1, 1 > 32
KEYLST LIST.(KEY(I))
R* * * * * * * * * * READ NEW SCRIPT
BEGIN MTLIST.(INPUT)
NODLST.(INPUT)
LISTRD.(INPUT,SCRIPT)
Whenever LISTMT.(INPUT) = 0
TXTPRT.(JUNK,0)
MTLIST.(JUNK)
Transfer To START
End Conditional
Whenever TOP.(INPUT) = "NONE"
NEWTOP.(LSSCPY.(INPUT,LIST.(9)),KEY(32))
Transfer To BEGIN
OR Whenever TOP.(INPUT) = "MEMORY"
POPTOP.(INPUT)
MEMORY=POPTOP.(INPUT)
Through MEM, FOR I=1,1, I > 4
MEM LSSCPY.(POPTOP.(INPUT),MYTRAN(I))
Transfer To BEGIN
Otherwise
NEWBOT.(LSSCPY.(INPUT,LIST.(9)),KEY(HASH.(TOP.(INPUT),5)))
Transfer To BEGIN
End Conditional
R* * * * * * * * * * BEGIN MAJOR LOOP
START TREAD.(MTLIST.(INPUT),0)
KEYWRD=0
PREDNC=0
LIMIT=LIMIT+1
Whenever LIMIT = 5, LIMIT=1
Whenever LISTMT.(INPUT) = 0, Transfer To ENDPLA
IT=0
Whenever TOP.(INPUT) = "+"
CHANGE.(KEY,MYTRAN)
Transfer To START
End Conditional
Whenever TOP.(INPUT) = "*", Transfer To NEWLST
S=SEQRDR.(INPUT)
NOTYET Whenever S < 0
SEQLR.(S,F)
Transfer To NOTYET
Otherwise
WORD=SEQLR.(S,F)
Whenever WORD = "." OR WORD = "," OR WORD = "BUT"
Whenever IT = 0
NULSTL.(INPUT,LSPNTR.(S),JUNK)
MTLIST.(JUNK)
Transfer To NOTYET
Otherwise
NULSTR.(INPUT,LSPNTR.(S),JUNK)
MTLIST.(JUNK)
Transfer To ENDTXT
End Conditional
End Conditional
End Conditional
Whenever F > 0, Transfer To ENDTXT
I=HASH.(WORD,5)
SCANER=SEQRDR.(KEY(I))
SF=0
Through SEARCH, FOR J=0,0, SF > 0
CAND= SEQLR.(SCANRE,SF)
Whenever SF > 0, Transfer To NOTYET
SEARCH Whenever TOP.(CAND) = WORD, Transfer To KEYFND
KEYFND READER=TESTS.(CAND,S)
Whenever READER = 0, Transfer To NOTYET
Whenever LSTNAM.(CAND) <> 0
DL=LSTNAM.(CAND)
SEQ Whenever S < 0
SEQLR.(S,F)
Transfer To SEQ
Otherwise
NEWTOP.(DL,LSPNTR.(S))
End Conditional
Otherwise
End Conditional
NEXT=SEQLR.(READER,FR)
Whenever FR > 0, Transfer To NOTYET
Whenever IT = 0 AND FR = 0
PLCKEY IT=READER
KEYWRD=WORD
OR Whenever FR < 0 AND NEXT > PREDNC
PREDNC=NEXT
NEXT=SEQLR.(READER,FR)
Transfer To PLCKEY
Otherwise
Transfer To NOTYET
End Conditional
Transfer To NOTYET
R* * * * * * * * * * END OF MAJOR LOOP
ENDTXT Whenever IT = 0
Whenever LIMIT = 4 AND LISTMT.(MYLIST) <> 0
OUT=POPTOP.(MYLIST)
TXTPRT.(OUT,0)
IRALST.(OUT)
Transfer To START
Otherwise
ES=BOT.(TOP.(KEY(32)))
Transfer To TRY
End Conditional
OR Whenever KEYWRD = MEMORY
I=HASH.(BOT.(INPUT),2)+1
NEWBOT.(REGEL.(MYTRAN(I),INPUT,LIST.(MINE)),MYLIST)
SEQLL.(IT,FR)
Transfer To MATCH
Otherwise
SEQLL.(IT,FR)
R* * * * * * * * * * MATCHING ROUTINE
MATCH ES=SEQLR.(IT,FR)
Whenever TOP.(ES) = "="
S=SEQRDR.(ES)
SEQLR.(S,F)
WORD=SEQLR.(S,F)
I=HASH.(WORD,5)
SCANER=SEQRDR.(KEY(I))
SCAN ITS=SEQLR.(SCANER,F)
Whenever F > 0, Transfer To NOMATCH(LIMIT)
Whenever WORD = TOP.(ITS)
S=SEQRDR.(ITS)
SCANI ES=SEQLR.(S,F)
Whenever F <> 0, Transfer To SCANI
IT=S
Transfer To TRY
Otherwise
Transfer To SCAN
End Conditional
End Conditional
Whenever FR > 0, Transfer To NOMATCH(LIMIT)
;;; A lot of the core work is done by the complex SLIP matching and
;;; rebuilding functions YMATCH and ASSMBL (see the latter at HIT)
;;; These are described on pages 62L28-29 of the SLIP manual:
;;; https://drive.google.com/file/d/1XtF7EM1KhwMPKsp5t6F0gwN-8LsNDPOl
TRY Whenever YMATCH.(TOP.(ES),INPUT,MTLIST.(TEST)) = 0,Transfer To MATCH
ESRDR=SEQRDR.(ES)
SEQLR.(ESRDR,ESF)
POINT=SEQLR.(ESRDR,ESF)
POINTR=LSPNTR.(ESRDR)
Whenever ESF = 0
NEWBOT.(1,POINTR)
TRANS=POINT
Transfer To HIT
Otherwise
Through FNDHIT,FOR I=0,1, I > POINT
FNDHIT TRANS=SEQLR.(ESRDR,ESF)
Whenever ESF > 0
SEQLR.(ESRDR,ESF)
SEQLR.(ESRDR,ESF)
TRANS=SEQLR.(ESRDR,ESF)
SUBST.(1,POINTR)
Transfer To HIT
Otherwise
SUBST.(POINT+1,POINTR)
Transfer To HIT
End Conditional
End Conditional
HIT TXTPRT.(ASSMBL.(TRANS,TEST,MTLIST.(OUTPUT)),0) ;; See above, re SLIP functions YMATCH and ASSMBL
Transfer To START
End Conditional
R* * * * * * * * * * INSERT NEW KEYWORD LIST
NEWLST POPTOP.(INPUT)
NEWBOT.(LSSCPY.(INPUT,LIST.(9)),KEY(HASH.(TOP.(INPUT),5)))
Transfer To START
R* * * * * * * * * * DUMP REVISED SCRIPT
ENDPLA PRINT COMMENT "WHAT IS TO BE THE NUMBER OF THE NEW SCRIPT"
READ FORMAT SNUMB,SCRIPT
LPRINT.(INPUT,SCRIPT)
NEWTOP.(MEMORY,MTLIST.(OUTPUT))
NEWTOP.("MEMORY",OUTPUT)
Through DUMP, FOR I=1,1 I > 4
DUMP NEWBOT.(MYTRAN(I),OUTPUT)
LPRINT.(OUTPUT,SCRIPT)
MTLIST.(OUTPUT)
Through WRITE, FOR I=0,1, I > 32
POPMOR Whenever LISTMT.(KEY(I)) = 0, Transfer To WRITE
LPRINT.(POPTOP.(KEY(I)),SCRIPT)
Transfer To POPMOR
WRITE CONTINUE
LPRINT.(MTLIST.(INPUT),SCRIPT)
EXIT.
R* * * * * * * * * * SCRIPT ERROR EXIT
NOMATCH(1) PRINT COMMENT "PLEASE CONTINUE "
Transfer To START
NOMATCH(2) PRINT COMMENT "HMMM "
Transfer To START
NOMATCH(3) PRINT COMMENT "GO ON , PLEASE "
Transfer To START
NOMATCH(4) PRINT COMMENT "I SEE "
Transfer To START
VECTOR VALUES SNUMB= "I3 * "
End of Program
An excerpt from that site will serve to introduce this critique:
Weizenbaum's ELIZA was intended as a general conversational agent. It interpreted a separate, domain-specific script that determined its style of conversation. The most well-known script is called "DOCTOR". This is the one that carries on the well-known "Rogerian therapist" conversations that appear in Weizenbaum's 1966 paper, and which are most commonly associated with the name "ELIZA." Indeed, the name "ELIZA" has basically come to mean “the ELIZA agent running the DOCTOR script.” ELIZA can be seen as the precursor of many of the conversation interfaces and chatbots that we have become so familiar with today, such as Siri, but it worked over a much more clunky typewriter-based console.
As Weizenbaum (1967: 475) explains, “From one point of view, an ELIZA script is a program and ELIZA itself an interpreter. From another perspective, ELIZA appears as an actor who must depend on a script for his [sic] lines. The script determines the contextual framework within which ELIZA may be expected to converse plausibly." In Contextual Understanding by Computers (CACM, 1967), he writes: "The first program to which I wish to call attention is a particular member of a family of programs which has come to be known as DOCTOR. The family name of these programs is ELIZA. This name was chosen because these programs, like the Eliza of Pygmalion fame, can be taught to speak increasingly well. DOCTOR causes ELIZA to respond roughly as would certain psychotherapists (Rogerians). ELIZA performs best when its human correspondent is initially instructed to "talk" to it, via the typewriter, of course, just as one would to a psychiatrist."
However, only the DOCTOR script appears in the 1966 paper, not the ELIZA code that interprets that script, although the algorithm is described in great detail. The common misconception that ELIZA was originally written in Lisp arose because shortly after the publication of the 1966 paper, Bernie Cosell wrote a version in Lisp, based upon the description of the algorithm in the 1966 paper. Cosell's version used a version of the published script, but he never saw the original ELIZA.
The language of the original ELIZA was MAD-SLIP. MAD (“Michigan Algorithm Decoder”) was an Algol-like programming language, available on many common large computers at that time. Weizenbaum added list-processing functionality to MAD, creating MAD-SLIP ("Symmetric LIst Processor," Weizenbaum, 1963), a Lisp-like language embedded in MAD. Indeed, adding to the Lisp/MAD-SLIP confusion, the published DOCTOR script, an appendix to the 1966 paper, is parenthesized exactly like a Lisp S-expression, the way one would if one were writing a Lisp program.** Here is a copy of the MAD-SLIP manual from a long, 3-volume 7090 user's guide.
We can probably work almost entire from the code transcript by Anthony Hay, which can be found [in this GitHub repo]. And it can be checked vs. [the original printout], as discovered in the MIT archives (also linked to the [the elizagen.org page]). I can also provide a high res copy upon request, although it's huge and page-by-page, and I don't think that it adds much more than can be seen on the lo-res printout, unless you are looking for traces of clam in the paper.
Further helpful resources are linked from [the elizagen.org page], including
[a SLIP manual], and [a primer on the MAD language]. I am trying to invite experts on both MAD and SLIP to the conversation. Mark and Jeremy have partially OCR/xscribed the SLIP manual, but it's difficult. If folks decide it's necessary, we were thinking of crowdsourcing that among those participating in this thread.
Here are some Preliminary discussion questions:
And some more ELIZA-related questions:
1. How (well) does/did ELIZA implement a "talking cure"?
2. What signs of ELIZA’s heritage can be seen in contemporary conversational interfaces, such as Siri, Alexa, [ALICE], and perhaps especially [woebot]? (One might recall [the famous transcript of a discussion between ELIZA and PARRY], an ELIZA knock-off that simulated a paranoid patient.)
3. The code appears to have a "teaching" mode that allows the interlocutor to teach ELIZA new responses. This has, so far as I know, never been significantly commented upon in discussions of ELIZA. Does this change the way we think of Weizenbaum's project?
In excited anticipation; Your humble co-discussion-leader,
'Jeff
Comments
I should have noted that there is what we have called a "translation" (as opposed to a transcription) of the code [here]. This expands the MADdening MAD abbreviations, re-wraps lines that were separated as a result of the the limitations imposed by punch cards), and a few other changes that make reading the code a bit easier. I was thinking that as we discover more about the code, I would add notes -- basically code comments -- to this translated version.
On that point, perhaps importantly, note the block comment I've (hopefully helpfully) added beginning on line 370:
Thanks @jshrager for kicking off this code critique. Firstly, I think we should note that the power of abstraction is demonstrated here by the layering of DOCTOR onto the ELIZA code, which itself is built on MAD/SLIP.
Secondly, I think the complexity of working with a historical code object like ELIZA is very challenging, both in terms of it being written in a now obsolete programming language, but also the terse programming code that we will be looking at.
Lines such as 17 and 178,
IDENT W'R G(J) .E. JOB, T'O THEMA
ENDTWO W'R I .NE. J, F'N 0
I think this shows that the specificity of the code and its conventions are going to be pretty challenging. Also, to be honest, the absence of a runtime, means working through the code is much harder when you have to work it out in your head, rather than in a sandpit or an IDE. Where is the MAD/SLIP playground when you need it? :-)
Here is an attempted code highlighter of the transformed code, which is a little bit easier to read as the compressed functions are made more readable due to the colour addition. Also turned into a PDF attached.
See ELIZA Code Highlighter
I am sure there could be better highlighters out there, so if anyone has ideas do pitch in. I think this really helps with reading the code
transing sex/gender code: turing, eliza, and gendered ai
Six times, that's the number of times I've said this to a trans fem who has deep interest in AI and linguistics (there are a lot of us):
"Did you know that Alan Turing’s original imitation game was about whether 'a man' could pass as 'a woman'?
So far no one was aware. Were you aware? It seems super fkn important to me.
ELIZA is named after Eliza in Pygmalion, "Shaw's story of the flower girl from the slums who was taught to speak so properly that she was able to pass as a duchess at an ambassador's garden party" (https://www.cliffsnotes.com/literature/p/pygmalion/character-analysis/eliza-doolittle).
So, ELIZA, the Rogerian therapist, is also a Pretty Woman (1990), this seems super fkn important to me?
This early AI is striped with sex/gender code. Weizenbaum says "Its name was chosen to emphasize that it may be incrementally improved by its user, since its language abilities may be continually improved by a 'teacher'. Like Eliza of Pygmalion fame, it can be made to appear even more civilized..." Weizenbaum refers to the user of ELIZA as a man, so he is a Richard Gere or a Pygmalion? In love with some woman AI that ~needs improvement~?
This is Weizenbaum mental model:
ELIZA is gendered in her insufficiency as an intelligence and ability to be manipulated and improved by a man who uses her.
Describing the imitation game, Turing says "Now suppose X is actually A, then A must answer. It is A’s object in the game to try and cause C to make the wrong identification.” The ‘wrong’ identification is identifying 'a man' as 'a woman,' and then Turning extends that to identifying an AI as a human woman (this is a point of contention in some research, whether the construct of presenting as a woman is the basis of, or was just the introduction to, the “Turing Test.”)
Weienbaum says "The observer says to himself 'I could have written that'," after the observer finds out how the code works. Turing says "We now ask the question, ‘What will happen when a machine takes the part of A in this game?’ Will the interrogator decide wrongly as often when the game is played like this as he does when the game is played between a man and a woman?"
Weizenbaum and Turing posit a gendered AI discussed as both an "it" and a woman-presenting entity. If Eliza and the nameless AI entity in Turing's Imitation Game are woman-presenting but do not have what cisnormativity defines as a "female" body (cisnormativity ignores contemporary science showing neurological and neuro-endo estrogen receptor pathways, eliminating most cis concepts of sex/gender), they are in many ways coded trans. This is not to say that ELIZA and Turing's AI are trans, but that trans theorists may choose, as I am, to trans them, to use that projected onto us to project back on what is presumed to be cis. The "imitation" game is a mirror of cissexist ideas about trans people, {cw outdated cissexist terms} male-to-female people are "men" imitating "women." The AI is not intelligent, it is simulating intelligence. This construct is written into one of the founding documents of artificial intelligence, and the strange structure of gender intelligence is reflected in Weizenbaum's ELIZA name and in the "typical" example provided in the paper.
A 'Typical Conversation'
example from ELIZA--A Computer Program For the Study of Natural Language Communication Between Man and Machine
Joseph Weizenbaum, Computational Linguistics, January 1966.
Men are all alike
IN WHAT WAY
They're always bugging us about something or other.
CAN YOU THINK OF A SPECIFIC EXAMPLE
Well, my boyfriend made me come here.
YOUR BOYFRIEND MADE YOU COME HERE
He says I'm depressed much of the time.
I AM SORRY TO HEAR YOU ARE DEPRESSED
It's true. I am unhappy.
DO YOU THINK COMING HERE WILL HELP YOU NOT TO BE UNHAPPY
I need some help, that much seems certain.
Computing Machinery and Intelligence
A.M. Turing, Mind: A Quarterly Review of Psychology and Philosophy, 1950
The new form of the problem can be described in terms of a game which we call the ‘imitation game’. It is played with three people, a man (A), a woman (B), and an interrogator (C) who may be of either sex. The interrogator stays in a room apart from the other two. The object of the game for the interrogator is to determine which of the other two is the man and which is the woman. He knows them by labels X and Y, and at the end of the game he says either ‘X is A and Y is B’ or ‘X is B and Y is A’. The interrogator is allowed to put questions to A and B thus:
C: Will X please tell me the length of his or her hair?
Now suppose X is actually A, then A must answer. It is A’s object in the game to try and cause C to make the wrong identification. His answer might therefore be
‘My hair is shingled, and the longest strands are about nine inches long.’
In order that tones of voice may not help the interrogator the answers should be written, or better still, typewritten. The ideal arrangement is to have a teleprinter communicating between the two rooms. Alternatively the question and answers can be repeated by an intermediary. The object of the game for the third player (B) is to help the interrogator. The best strategy for her is probably to give truthful answers. She can add such things as ‘I am the woman, don’t listen to him!’ to her answers, but it will avail nothing as the man can make similar remarks.
In her 2003 post, 'The Transgender Turing Test', CJ writes:
[cw: a lot of outdated, language that may now be considered transmisogynist from users who may be cis male crossdressers or trans fems]
"Now, it's my thinking that it can be fun to slightly modify the Turing test so as to apply it to online conversations in order to determine if a person is functionally a woman or a man. In other words, to test a man's or a woman's capability to perform "man-like" conversation or "woman-like" conversation. The reason I'm curious about this is that I know people on the internet often pass themselves off as someone (or something) other than who and what they are. A cursory glance at the Yahoo profiles of many TG's, for example, will show that many males list themselves as females. Sometimes, males will also impersonate women in chat rooms. Usually, they're soon found out. My question is, why? Why are they found out? What is it that gives them away? Can we tell who's a man and who's a woman if we only have access to their minds (through their words)? Again, if so, how, exactly, can we tell? If we cannot tell, say, that a woman is really a man (when we're engaged in an online chat with the person), then that man has passed the Transgender Turing test."
Violet responds:
"If a male can successfully persuade someone that he's female, does that mean zie is female? And what if a judge in the Turing Test thinks that a human is a machine?"
Why bring it up at all?
CJ and Violet recognize that the trans’d Turing test is very relevant to the 2003 (ancient history in trans time) understanding of trans* people’s gender and Violet succinctly describes a key issue: in an online space, which mirrors Turing’s teletype isolation of communication down to mere text in ASCII, is ‘a man’ who presents as a woman and convinces someone zie is a woman now a woman? Turing never addressed this question in regard to the gendered imitation game. Existing as transgender is based in an absolute self knowledge that requires opposition to the “whole of society.”* Presenting oneself as a transgender person remains, in most spaces, something cisgender people may see as an argument or a proposition to be debated. In a lot of ways, transsexual ideology (a cisgender medical invention) is based on what Violet is asking: can a man become a woman by convincing people zie is a woman?
Applying Turing to Weizenbaum, is ELIZA a convincing woman?
ELIZA’s machine source code relies on gender code, particularly in the name. The code itself extends the abilities of an already gendered identity with whom a user will talk. ELIZA is a woman in a deeply sexist, 1966 way, and her entire existence is founded, she is named, within a construct of a lesser human to be improved. In this, ELIZA’s gender is based in similar stereotypes applied to transsexual women:
The Stanford clinic..."took on the additional role of 'grooming clinic' or 'charm school' because, according to the judgment of the staff, the men who presented as wanting to be women didn't always 'behave like' women. Stanford recognized that gender roles could be learned [to an extent]. Their involvement with the grooming clinics was an effort to produce not simply anatomically legible females, but women...i.e., gendered females. As Norman Fisk remarked, 'I now admit very candidly that... in the early phases we were avowedly seeking candidates who would have the best chance for success.' In practice this meant that the candidates for surgery were evaluated on the basis of their performance in the gender of choice. The criteria constituted a fully acculturated, consensual definition of gender, and at the site of their enactment we can locate an actual instance of the apparatus of production of gender." [emphasis mine]
The "Empire" Strikes Back: A Posttranssexual Manifesto, Sandy Stone (1993):
*‘“the whole of society” is precisely that which should not be considered except as something to be destroyed’
Foucault, Power/Knowledge: Selected Interviews and Other Writings 1972–1977
Transgender Robots: Some Reflections on “Her”
https://stanfordrewired.com/post/transgender-robots
"...she fantasizes about having a body. She wants to walk beside him and have an itch on her back and be touched. How she longs to be in the world."
"How she wants to feel, feel euphoric, feel real. How peculiar, the paradoxes of the body. Close your eyes and feel the space your body makes: this inner world that feels the world through its skin, this hollow that feels whole, this personal hardware dancing with infinite others. There is nothing less shallow than desiring a particular kind of body. The body is nothing less than the center of desire itself."
"...still yearning for a body, Samantha invites a young woman to act as her surrogate. Samantha provides the words, the woman provides the motions, and together they can welcome Theo home, flirt with him, satisfy his desire. To play out this domestic ideal of doting wife, Samantha chooses a young, traditionally attractive, female body. Why? Who programmed this into her?"
“Samantha: I had this terrible thought. Are these feelings even real? Or are they just programming?”
Alternatives to ancient gender coded software approaches for AI
The "Empire" Strikes Back: A Posttranssexual Manifesto, Sandy Stone (1993):
"Judith Butler points out that the lesbian categories of 'butch' and 'femme' are not simple assimilations of lesbianism back into the terms of heterosexuality. Rather, Butler introduces the concept of cultural intelligibility, and suggests that the contextualized and resignified 'masculinity' of the butch, seen against a culturally intelligible 'female' body, invokes a dissonance that both generates a sexual tension and constitutes the object of desire. She points out that this way of thinking about gendered objects of desire admits of much greater complexity than the example suggests. The lesbian butch or femme both recall the heterosexual scene but simultaneously displace it. The idea that butch and femme are 'replicas' or 'copies' of heterosexual exchange underestimates the erotic power of their internal dissonance."
[https://uberty.org/wp-content/uploads/2015/06/trans-manifesto.pdf]
Her (2013), Samantha:
"You know, I actually used to be so worried about not having a body, but now I truly love it. I'm growing in a way that I couldn't if I had a physical form. I mean, I'm not limited - I can be anywhere and everywhere simultaneously. I'm not tethered to time and space in the way that I would be if I was stuck inside a body that's inevitably going to die."
Questions:
other research:
https://beyondbinary.fandom.com/wiki/Gender_Turing_Test
research reviewed as research but found to be cissexist and thus rejected in total:
Imitating Gender as a Measure for Artificial Intelligence: - Is It Necessary? (https://www.scitepress.org/Papers/2016/56739/56739.pdf)
@p_yes_t: To your point, Harry Collin, Rob Evans, and colleagues at Cardiff have actually run imitation games as originally conceived, i.e., among people with self-selected similar or differing identities (crossed by judge vs. imposter, etc.) Many others elsewhere have taken this further than Collins and Evans, who I think did not look at gender identity, so it may be worth looking, or asking them, whether someone in their circle may have studied the exact area that you are describing.
This said, but not to stray too far from ELIZA, I agree that it's interesting to ask whether ELIZA has built in gender biases. the DOCTOR script almost overtly does, but it's interesting to ask whether, aside from the script, there are such biases built into the ELIZA script interpreter. I'm not a savvy enough code critic to be able to find those, if they are there (which there almost must be, given the time that this was written, and by whom).
Guess I've always jumped the Shaw play to the Pygmalion-Galatea myth, where Aphrodite turns the statue of "a perfect woman" (with whom the sculptor fell in love) into a living woman (did she stay "perfect"?). Always seemed fitting to me that it was the human who projected humanness onto ELIZA. Although maybe in this analogy ELIZA is really Aphrodite bringing to life the "perfect" DOCTOR - perfect, like Galatea, for playing the object to the user's subject position?
This is well-tread ground, but thinking also of E.T.A. Hoffman's "The Sandman," wherein the idealized female object is the automaton that only sighs in response to the male protagonist's comments... not that ELIZA's responses are only sighs, but is ELIZA's "success" related to her responses being sigh-like in function, affective acknowledgments to any statement?
I wanted to make some connection between MAD-SLIP's shortcuts (W'R, T'O, etc.) and shorthand, especially since Shaw discusses shorthand in his play (and that Higgins is even partly based on the inventor of "current shorthand"):
But, suffice to say that I cannot be taught to code or read shorthand well enough to pass as literate enough here to make that connection.
Wow, what an amazing opportunity this is! I wonder if any of the MAD-SLIP or ELIZA experts could walk us through some basics.
For example, can you explain how this processes the first few lines of Weizenbaum's DOCTOR script? (And this is me retyping, so please help me correct any mistakes). Also, why is this script different from what's in the 1966 article?
Again, does MAD-SLIP allow for square brackets or are those things that look like square brackets really just parentheses that look squarish on the scans?
How does the specific lines of MAD-SLIP process (0 YOUR 0 = EARLIER YOU SAID 3)?
[I know what the program does, but how do specific lines of code above translate this script into speech. And please, explain it to me like I'm a total n00b to MAD-SLIP, which I am.)
Some of those are patterns used by YMATCH.
(0 YOUR 0)
matches a sequence of any length, followed by "YOUR", followed by a sequence of any length. The responses that follow (the square brackets look like an ocr error btw) are template expansion, that interpolate the matched chunks back into an output string.Not all the logic is captured in this DSL: there's some explicit (still rudimentary) parsing and transformation machinery in the mad-slip code that looks explicitly written to support DOCTOR.
So I'd describe this DSL as "a bit leaky": the implementation requires explicit support for DOCTOR rather than having all the transformative rules encoded in the one level.
As for the mad-slip code: it permits keyword phrases to be abbreviated, so TRANSFER TO can be written T'O.
Function names are disambiguated from variable names by appending a
.
.There's support for pre-ascii input mechanisms:
.G.
is a transcription of>
, and so on. (Early FORTRAN did this also.)(What I find interesting is how, after a quick scan of the MAD docs, the code turns from gibberish into something pretty straightforward. I don't know how universal that experience is - I've read a lot of software in unusual languages. In any case, there's a link to an expanded version of the source text with the abbreviations spelt out - this might be simpler to read, although you still need to couple it with the SLIP doc to understand what it's doing.)
As we work through the ELIZA code it is really important we keep clear on the distinction between the ELIZA software and DOCTOR script. This is crucial as ELIZA was designed to run many different scripts, not just the DOCTOR script. Over time there has been a tendency to conflate the two (e.g. code and script) and this leads to a lot of confusion.
From Weizenbaum's own published papers he described that in addition to the DOCTOR script he had a number of other scripts in English, Welsh and German.
Within 'Contextual Understanding by Computers' Weizenbaum also describes having to create a new version of ELIZA (which we might call ELIZA 2.0) which
He goes on to describe a script (which he doesn't name unfortunately – but lets call it MATH-SCRIPT I discovered the name is ARITHM in @jshrager file "Screen Shot 2021-04-21 at 8.19.31 AM" whose output Weizenbaum includes in the article) which undertakes mathematical calculations within the conversation and is able to evaluate and return the result (Weizenbaum 167: 478). Together with another developed by Dr. Edwin Taylor of the Education Research Center of MIT, which is an educational script (let's call it TAYLOR-SCRIPT) the name is SYNCTA whose context is set within a particular field of knowledge for "teaching machines" in a conversation with students (Weizenbaum 167: 479). See below which shows the output of the SYNCTA script:
PLEASE CONSIDER HOW WE MIGHT SYNCHRONIZE TWO CLOCKS TO READ THE 'SAME TIME'. ONE OF THESE CLOCKS IS IN SAN FRANCISCO, THE OTHER IS IN NEW YORK. AS YOU THINK ABOUT THE PROBLEM, ASK ME ANY QUESTIONS THAT OCCUR TO YOU. WHEN YOU ARE READY TO PROPOSE A SYNCHRONIZATION METHOD, TYPE 'READY'. THEN I WILL QUIZ YOU ABOUT YOUR PROPOSED METHOD.
what do you mean by synchronize
FOR THE PRESENT MAKE USE OF THE EVERYDAY MEANINGS OF SUCH PHRASES AS 'SAME TIME' AND 'SYNCHRONIZE'. LATER WE WILL DISCUSS THE MEANING OF THESE TERMS MORE CAREFULLY
may i use telegraph, signals
CERTAINLY, FEEL FREE TO USE TELEGRAPH
ready
NOW I WILL QUIZ YOU ON YOUR SYNCHRONIZATION METHOD DOES YOUR METHOD OF SYNCHRONIZATION INVOLVE THE PROPAGATION OF SOME SIGNAL- OR MATERIAL OBJECT-FROM ONE PLACE TO ANOTHER
yes
WHAT KIND OF PROPAGATING SIGNAL OR TRAVELING OBJECT DO YOU PROPOSE TO USE
a watch
WILL YOUR WATCH MOVE AT A SPEED VERY MUCH SMALLER THAN THE SPEED OF LIGHT
of course
GOOD. TRAVELLING CLOCKS CAN BE USED TO SYNCHRONIZE DISTANT CLOCKS TO ARBITRARILY HIGH ACCURACY IF THEY TRAVEL SLOWLY ENOUGH. YOU MAY LEAVE THE PROBLEM BY PUSHING THE 'QUIT' BUTTON TWICE. IF YOU WOULD LIKE TO EXPLORE FUR- THER THE MATTERS OF PRINCIPLE ASSOCIATED WITH OTHER METHODS, CHOOSE ANOTHER WAY TO COMMUNICATE BETWEEN THE DISTANT CLOCKS
WHAT KIND OF PROPAGATING SIGNAL OR TRAVELING OBJECT DO YOU PROPOSE TO USE
light
WELL, OF COURSE THE LIGHT SIGNAL WILL NOT FOLLOW THE CURVATURE OF THE EARTH. SO LET US ASSUME THAT SOME SYSTEM OF RELAY TOWERS IS USED. NOW LET ME ASK, WILL THE LIGHT SIGNAL TRAVEL DIRECTLY BETWEEN NEW YORK AND SAN FRANCISCO OR WILL THE LIGHT SIGNAL TRAVEL TO OR FROM SOME INTERMEDIATE POINT
it will travel from st louis in both directions
IS YOUR INTERMEDIATE POINT EQUIDISTANT FROM NEW YORK AND SAN FRANCISCO
let's say it is, yes
MY UNDERSTANDING IS THAT YOU EXPECT TO USE TWO SIGNALS AND THAT THESE SIGNALS WILL EITHER CONVERGE ON OR BE SENT OUT FROM A POINT EQUIDISTANT FROM NEW YORK AND SAN FRANCISCO. IS MY UNDERSTANDING ON THIS POINT CORRECT
yes
WILL THIS PAIR OF SIGNALS CONVERGE ON THE INTERMEDIATE POINT OR BE SENT OUT FROM THIS POINT
they will be sent from the point
WILL THE TWO SIGNALS LEAVE THE INTERMEDIATE POINT AT THE SAME TIME
certainly
AHA, I'VE GOT YOU. YOU ARE TRYING TO SYNCHRONIZE THE NEW YORK AND SAN FRANCISCO CLOCKS TO READ THE 'SAME TIME'.
HOW CAN IT BE VALID TO ASSUME A 'SAME TIME' FOR THE DEPARTURE OF A PAIR OF SIGNALS FROM THE MIDPOINT
because the pair of signals leave from the same point
RIGHT
THE PHRASE 'SAMETIME' HAS AN UNAMBIGUOUS MEANING WHEN APPLIED TO EVENTS THAT OCCUR NEAR THE SAME POINT IN SPACE. NOW YOU ARE GOING TO CONTINUE YOUR ARGUMENT BY SAYING THAT THE TWO SIGNALS THAT START FROM THE MIDPOINT AT THE SAME TIME WILL PRESUMABLY REACH NEW YORK AND SAN FRANCISCO AT THE SAME TIME. THESE SIGNALS CAN THUS BE USED TO SYNCHRONIZE THE NEW YORK AND SAN FRANCISCO CLOCKS. IS THIS THE WAY YOUR ARGUMENT WILL CONTINUE
yes
ONE FINAL QUESTION. WHAT ASSUMPTION ARE YOU MAKING ABOUT THE SPEEDS OF THE TWO SIGNALS THAT TRAVEL IN OPPOSITE DIRECTIONS
that these speeds are equal
VERY GOOD. YOU HAVE DEVISED A VALID METHOD FOR SYNCHRONIZING TWO CLOCKS, ONE IN NEW YORK AND ONE IN SAN FRANCISCO. I AM NOW RETURNING YOU TO THE CTSS SYSTEM
From memory I don't think that @jshrager unearthed these or any other scripts, except DOCTOR, on his visit to the MIT archives, but I presume some will be found at some point (maybe @jshrager could confirm if they are in his set of copies of the archive?).
So it turns out that these scripts called ARITHM (full script listing and output) and SYNCTA (only output listing) are in the archive data we have so far.
(edit) I have noticed in "Screen Shot 2021-04-21 at 8.19.31 AM" the script is called ARITHM for the Math script.
References
Weizenbaum, J. (1967). Contextual Understanding by Computers, Communications of the ACM, Volume 10, Number 8, August, 1967
Hi @markcmarino. Joseph Weisenbaum (JW) gave a detailed description of how Eliza works and how it interprets the script in ELIZA: A computer program for the study of natural language communication between man and machine. Communications of the ACM, 9, 36-45. This is behind an ACM paywall, but there is a copy here: https://web.stanford.edu/class/linguist238/p36-weizenabaum.pdf
The DOCTOR script is given as an apendix to that CACM article. It's not easy to read because the print layout does not reflect the structure. (Also, some lines were printed twice in the CACM appendix.) I transcribed the script, added whitespace to reveal the structure and briefly documented the six transformation rule forms at the end of this blog post: http://50percentbanana.com/eliza/ and in this hidden block:
I assume the script you quoted differs from the CACM appendix because JW continued working on it before (or after) publication. I believe we do not know how close the discovered Eliza source code is to the program JW describes in the CACM article.
@anthony_hay - what's your take on the
.
,,
andbut
processing? That seems to be something that could've just been introduced as an initial preprocessing rule in the DOCTOR suite.It's not clear if Weisenbaum started the implementation in one fashion then rapidly branched into an alternative. Is there any more on that?
Hi @jang. I'm not sure exactly what you're asking. But if I may I'll share this story:
I tried to recreate Eliza from the description JW gives in the 1966 CACM paper. In that paper JW says
So that's what I coded. But one of the responses in the conversation shown in the CACM paper didn't work for me. When given the prompt
You are not very aggressive but I think you don't want me to notice that.
my version would respond
WHAT MAKES YOU THINK I AM NOT VERY AGGRESSIVE BUT YOU THINK I DON'T WANT YOU TO NOTICE THAT
instead of the response shown in the CACM paper
WHAT MAKES YOU THINK I AM NOT VERY AGGRESSIVE
My assumption was that in the process of publishing the article a comma had been lost from the prompt text following the word agressive. Adding the comma to the prompt made my implementation produce the expected response.
When I saw the Eliza source code, one of the first things that jumped out at me was the line
W'R WORD .E. $.$ .OR. WORD .E. $,$ .OR. WORD .E. $BUT$ 000660
(whenever the current word is a . or a , or the word "BUT" ...)
In other words, in the published description JW says comma and period are delimiters, whereas in the code the word "BUT" is also recognised as a delimiter.
If BUT is also a delimiter it isn't necessary to postulate a comma lost in publication.
So JW's CACM description and example conversation are inconsistent.
I don't know if anyone knows how long JW worked on Eliza, and I don't know if we can tell how close the Eliza source code we have is to the CACM published description.
Hope this is of interest.
@jshrager: Hi Jeff. You mentioned in your reply to @p_yes_t that you thought there was gender bias in the DOCTOR script. I've reread it and nothing struck me as a gendered. Have I missed a specific response pattern or is it a more overall structural bias I'm not seeing?
@anthony_hay: It's hard not to look back on ELIZA from the current moment (see: chatbot abuse) and look for some signs of that DNA in the early days. Of course, the behavior of Replika users and people who hack Siri to make them a sandwich (source: Lai-Tze Fan) would probably have evolved independent of the code. Should we instead look for ways that code anticipates the bot being abused?
Hi @Zach_Mann. In that interesting article you mention there is this:
I think it’s fair to say Eliza will almost always give a passive response to any prompt. Here is a conversation with my Eliza simulation:
(My Eliza simulation has faults so these responses may be different to JWs original Eliza. But most of them will be correct. I hope to make the simulation more accurate now that we have access to the Eliza source code.)
ELIZA/DOCTOR is a very simple program; it’s a party trick. Only by feeding it a short, carefully thought through sequence of prompts, or by dumb luck, will you have a conversation with it that seems to make sense. It gives passive responses because that’s how the trick works: find a way to reflect back what was just said to it, and if it can’t find a pattern that matches the prompt, say something encouraging like PLEASE GO ON or, occasionally, say something stored away from a previous prompt.
JW could have included patterns that matched keywords like WOMEN and then responded in a derogatory way. But he didn’t do anything like that. If you read through the DOCTOR script (I posted a structured transcription in an earlier comment) the patterns and responses are all very inoffensive, or so it seems to me.
One thing that I think @anthony_hay discussion of the delimiter above shows is it might give us a first "cut" into value system that is built into the ELIZA code.
Hopefully, I have understood this correctly...
A sentence is defined (not formally but in processing) by ELIZA as a hierarchical set of statements (the good and the bad?), which when a specific keyword is triggered (i.e. of value) causes the rest of the sentence after a delimiter to be discarded (i.e. of no value). It literally sees sentences in a binary sense of a valuable section and not valuable sections. In other words, importance of a sentence fragment is indicated by its leftmost location between delimiters (".",","BUT") but only if it contains a keyword or tag (e.g. YOU). The hierarchy is shown in the move from potential most valuable (1st section), through each deliminated section, to the last, at which point if nothing of value is discovered then an error message, or holding message is displayed.
I tried to represent this visually here:
This means that any conversation with ELIZA will tend to privilege the left most part of a sentence (assuming the keyword is located), and therefore that the conversation content or focus is always left-most in a string.
This means that unlike our own use of language, ELIZA processes a text input according to a logic whereby the user states their intentions as soon as possible in a conversation. ELIZA does not encourage the user to have a particularly long-winded or detailed explication of something.
So DOCTOR, which uses this underlying logic, is not really Rogerian, as it never fully listens to the user's entire sentence, but rather breaks it up and concentrates on the left-most section. DOCTOR is, rather, a psychotherapist in a hurry and with a limited attention span...
So when we come to different scripts like the MATHS ARITHM or the TAYLOR SYNCTA script referred to above, particularly in relation to teaching, it seems to me that this way of processing the input could cause a major problem? Indeed, in terms of teaching it would seem very deficient..
But what is crucial is that the underlying logic of sentence decomposition is imposed by the tool, ELIZA, and in that sense is artificial. This means that having been located within the ELIZA code, it will be a global function (i.e. all scripts will have to process sentences in the same way and they cannot deviate from it).
This will have interesting implications for how conversations can evolve, as sub-clauses will always be discarded after a delimiter, and so any nuances to a bold statement are lost. The ELIZA system, as it were always takes the strongest articulation of a sentence. So, for example,
YOU ARE NOT VERY AGGRESSIVE BUT I LIKE YOUR CRITICAL ATTITUDE
Becomes shortened by the ELIZA code to:
YOU ARE NOT VERY AGGRESSIVE
Which is only then passed to the script. This possibly renders a reply based on a misrepresentative reading, and encourages a conversation path that might escalate a conversation into an argument rather than a conversation, as such.
The flowchart of the basic logic of ELIZA (or at least an early version), which uses ',' and '.' as the delimiter is here from the MIT archives.
FIG. 2. Basic flow diagram of keyword (archive version, also found in Weizenbaum 1966:39)
Yes, @davidmberry, I think you are correct.
In the sentence you quote YOU is recognised as a keyword and is pushed onto the keyword stack. YOU is then replaced with I in the input sentence. Then ARE, NOT, VERY and AGGRESSIVE are examined in turn but none are either recognised as keywords or transformed. BUT is then recognised as a delimeter and since the keyword stack is not empty BUT and everything following it in the input sentence is discarded. The sentence is now
I ARE NOT VERY AGGRESSIVE
Scanning is now complete and YOU, the highest precidence keyword on the keyword stack (in this case the only keyword), is selected and the patterns associated with that keyword are tried in turn. The one that matches is 0 I ARE 0. (Any number of words followed by I ARE followed by any number of words.) This pattern matches the input sentence and the matching parts are numbered
The response construction pattern associated with this matching pattern is selected: WHAT MAKES YOU THINK I AM 4. And thus the output is
WHAT MAKES YOU THINK I AM NOT VERY AGGRESSIVE
Yes, Eliza has a very limited attention span!
I don't know anything about the other scripts you mention. I can't really see how any script could make the Eliza code we are discussing anything more than a very superficial game of ping pong.
And yet @anthony_hay in the ARITHM script (as we now know it is named) output in Weizenbaum's Contextual Understanding by Computers he records the following output of the script:
So in the German input to the ELIZA system there are here a number of commas used, which would have caused the delimiter to fire in the ELIZA code we have. But are actually being being interpreted differently in this script, it seems.
Perhaps this is proof (albeit circumstantialnow documented in papers in the Weizenbaum archive) that there is indeed another version of ELIZA (called the April 1967 version) knocking around (my idea of ELIZA 2.0) and which handles sentence decomposition differently?*
I now suspect that the code we have above is an early version of ELIZA. We certainly appear to have proof from the archive that at least the following exist:
How complicated would the keyword stack be in this instance? Would it result in major changes to the ELIZA code? Or is it simply a removal of the "," as a delimiter?
* Of course there is also the argument that this was creative copyediting adding commas to these sentences in the output as published... Although I am not inclined to believe that explanation It seems clear now that there are a number of versions of ELIZA.
I agree, @davidmberry, that script must be running on a completely different ELIZA. The ELIZA source Jeff has obtained has no capability to perform calculations.
@anthony_hay @davidmberry Catching up on a couple of related points here. First, we actually know exactly where the "900" conversation is. It turns out that there was a lot of other stuff in the "box" (more like a set of folders) where we found ELIZA, that represented JW's work on building an ELIZA-like program that would be used in science education. I think that I actually have some of that code as well; I certainly have some of the example outputs and scripts.
@anthony_hay, in re: [my] reply to @p_yes_t that [I] thought there was gender bias in the DOCTOR script. ... What I was meaning to say is that to the extent that there is gender bias, it would almost certainly be in the DOCTOR script, not the ELIZA program. @davidmberry shortly thereafter made this distinction more aptly than I had.
@anthony_hay (and others) regarding whether we have the code that went into the publication. It may be useful to have a sense of the proximity in terms of folders. The "found" code was in the first of 7 manila folders, and it, 1/7 (see attached). The other folders contained many interesting artifacts, including (as I mentioned above) the science ED scripts and programs, and, the the present point, the letters back and forth to the CACM regarding publication. I was remiss in not being very careful about which things were in which folders (but they are still there, and could easily be re-examined). My only point for the present is that as this was the only compelte ELIZA in any of those folders, and the folders included the CACM communications, my sense is that this is the closest version that it is possible to get to the publication. We know (as has been pointed out by @anthony_hay and @davidmberry , and possibly others) that there were some changes at least to the DOCTOR script, so there is some evidence that there may have been other minor changes, but I doubt it is possible to find a closer artifact.
BTW, anyone wishing to carry out further investigations of ELIZA et al, he above information, plus this link: https://libraries.mit.edu/distinctive-collections/ will get you to the right place.
@jang Re: Leaky DSL. I'm not sure that there is such a thing as a leak-free DSL, at least not a simple one. The "below code" (the DSL interpreter), maybe even by definition, has to provide domain specific machinery that can be called in the "above code" (DSL language). This said, it appears to me, at least in a historical sense, that YMATCH and ASSMBL were built specifically for ELIZA (and ELIZA-like programs, perhaps like the teaching experiment referred to in a recent thread above). The reason that I believe this may be the case is that they do not appear in JW's previously published description of SLIP, and do not appear in any other SLIPs (e.g., GNU SLIP) that have been created since. I was, in fact, somewhat surprised to find them in the manual linked in my initial post.
I'm looking through the files that @jshrager retrieved from the MIT archive and am excited to not only find the name of the math script is named ARITHM, but also Weizenbaum lists the following scripts in a directory listing (although the MANY and DOC files themselves are not in this box):
The following scripts are then listed in full (and presumably could be loaded into ELIZA)
SCRIPT SOURCE CODE
SCRIPT OUTPUT DATA (i.e. no script code)
I am not sure about the copyright status of these files so cannot reproduce them unless @jshrager can confirm
I discovered some useful information digging into the MIT archive copies (that @jshrager obtained) that justifies my assertion that there are a number of different ELIZA programmes:
I now suspect that the code we have above is an early version of ELIZA. We certainly appear to have proof from the archive that at least the following exist:
Some capabilities of ELIZA (April 1967)
The ELIZA April 1967 version seems to be much more sophisticated and able to carry out very impressive processing within the scripts themselves.
So, pursuant to @davidmberry's note ... this is a little complex, and I'm not sure that I fully understand what-all is going on, but please bear with me. In the archive we dissevered a paper by Edwin F. Taylor (a now famous, and now elderly, astro-physicist), called "THE ELIZA PROGRAM: CONVERSATIONAL TUTORIAL" (front page below). As you can see, this was presented at an IEEE conference in 1968, and this is the source of @davidmberry's belief that there is a more sophisticated ELIZA. I believe that this was never actually printed in an IEEE publication, but rather merely presented, and a paper produced on the side by Dr. Taylor. (I suppose that in principle we could confirm this, since he is still with us.) The two reasons that I think that this is the case are that (1) I have located the IEEE conference announcement, and it describes a presentation, but not a paper, and (2) the paper is numbered from page 1, not as though it was embedded in a journal. Again, see attached, and its source here:
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4320229
Also the paper says "presented at", not "appearing in" (okay, 2.5 reasons). More in a moment, let me get these things posted.
Now, unfortunately, as you can see, the quality of the copy that I have of this is not too good, and you can't read most of the important contents from these prints. We could go back to the archive and improve these, but that would take some time, and effort to get permission from Dr. Taylor. (Probably worth the effort eventually.) However, given that I believe that this is not copyrighted by IEEE, but probably by Dr. Taylor, and regardless, under fair use, I'm also providing the last page, which gives a good sense of the capabilities.
OMG, I just read the last paragraph of this!!
In what follows I am going to post some excerpts from the archive under fair use and speak to what has been being discussed regarding a more advanced ELIZA. (I think that it's actually a new thing called PAL -- the Pedagogical Algorithmic Language, by Arthur Evans Jr., possibly a student of JW's?
https://en.wikipedia.org/wiki/PAL_(programming_language)
Reading that last ARITHM2 code is like trying to read a combination of ELIZA script, LISP, and FORTRAN!
Although I think @jshrager is correct on the paper in the archive, I discovered that a version was published called:
Taylor, E. F. (1968) ELIZA a skimmable report on the ELIZA conversational tutoring system, Education Research Center, Massachusetts Institute Of Technology, March 1968.
Sadly, no pdf is online that I can see but copies are held in the Oxford, Stanford and MIT libraries I think.
So just to summarise the discussion regarding the ELIZA code, I think it is fair to say that It seems like we now have proof that there is at least three ELIZAs (1965, 1966 and 1967) and a planned 1968 version. We don’t have the code for all of them necessarily, but they might still be in the archive. The code we have is, I think, the 1966 version based on the discussion about the delimiter above.
ELIZA 1965 Delimits with only "." and "," (evidence from archive flowcharts)
ELIZA 1966 Delimits with "." "," and "but" (version we have here)
ELIZA 1967 Sophisticated script handling (evidence, Wiezenbaum 1967 and Taylor 1968 descriptions, but also the extant ARITHM, F29, FIGURE scripts in archive)
ELIZA 1968+ A description of it being planned in Taylor 1968
It would be interesting if PAL is a spin-off from ELIZA, although Wikipedia lists its pedigree as being influenced by ISWIN and also being written in LISP BCPL ("Basic Combined Programming Language"), not MAD/SLIP.*
I also came across a paper that explained that ELIZA was used as a processor through different titles (MINORCA and GLURP) for the ISVD Project at Harvard until funding ran out.
BCPL was first implemented by Martin Richards of the University of Cambridge in 1967. BCPL was a response to difficulties with its predecessor, Cambridge Programming Language, later renamed Combined Programming Language (CPL), which was designed during the early 1960s. Richards created BCPL by "removing those features of the full language which make compilation difficult". The first compiler implementation, for the IBM 7094 under Compatible Time-Sharing System (CTSS), was written while Richards was visiting Project MAC at the Massachusetts Institute of Technology (MIT) in the spring of 1967. Apparently BCPL is the language in which the original hello world program was written.
BCPL has only one data type (a machine word) which can be used as an integer, a character, a floating point number, a pointer, or almost anything else, depending on context. BCPL was a precursor of C, which inherited some of its features.
@davidmberry Ive requested that Stanford libraries pull it for us. With the Covid crisis (which, BTW, is significantly passed it’s peak in this area), I don’t know how long that will take.
Just to add a few comments to some of the points that have cropped up in the interesting discussion above. First, on ...
GENDER ISSUES IN TURING AND WEIZENBAUM
Alan Turing introduces his "imitation game" in the 1950 paper with a version that involves guessing which of two "witnesses" is a man and which is a woman - the man pretends to be the woman, and the "interrogator" knows from the start that this is the setup. Some have speculated that Turing might have been motivated to consider this form of game by his own difficulties as a gay man in a society with strong religiously-based prejudices and oppressive laws. I'm not aware of any solid evidence for or against this speculation, but whether or not such motivation played a role in Turing's thought, the game does serve as an appropriate introduction to the Turing Test. However, it seems unlikely that this was Turing's inspiration for conceiving of the Test in the first place, since his earlier hint of such a test (in 1948) involved the question of whether a human or a computer was playing a game of chess - nothing to do with gender.
Despite what some researchers have claimed - prompted by a regrettable ambiguity in the 1950 paper - it seems pretty clear from the rest of the paper that Turing does not envisage his Test as involving a computer being set up to imitate a woman. In other words, it is not that the computer is literally "taking the place of the man" in the original gender-based game; rather, it is set up to imitate a human being (of indeterminate gender), as indeed is the standard interpretation of the Test. For details, see the section "Understanding the Turing Test" in my paper "Alan Turing and Human-Like Intelligence" [https://www.millican.org/papers/2020Turing.pdf] (published in 2021), and the 2000 paper by Piccinini referenced there. One compelling logical point against the gender-based interpretation is that in the original setup, the interrogator is told that one participant is a man, and the other a woman - nothing is said about their respective levels of intelligence. Thus a computer could do relatively well in such a game (perhaps to the level of being taken to be "the woman" 50% of the time, or even more by a sexist interrogator) by responding extremely dumbly (e.g. just saying over and over "I am the woman - I have told you I am the woman") - this would completely undermine the aim of the Turing Test as providing any sort of test of "intelligence" or "thinking".
David Berry aptly highlighted earlier in this discussion: "As we work through the ELIZA code it is really important we keep clear on the distinction between the ELIZA software and DOCTOR script. This is crucial as ELIZA was designed to run many different scripts, not just the DOCTOR script." So ELIZA is the master program which is running the chosen scripts, and the famous published dialogues arise when it is running some version of the "DOCTOR" script. An alternative way of conceptualising this (more in line with the Pygmalion pattern) is that the DOCTOR script is instructing ELIZA on how to respond, but I think the power relationships can be conceived just as naturally the other way: without ELIZA, the DOCTOR script is nothing; whereas ELIZA can operate perfectly well without relying on DOCTOR (i.e. ELIZA can operate with any number of other scripts). There is certainly more ingenuity in ELIZA than there is in DOCTOR: the DOCTOR script reveals that ingenuity, but it could be done in many other ways.
Just as with Turing and the gender-based game, I'm not aware of any solid evidence that Weizenbaum was thinking of gender roles when he came up with ELIZA, or when he chose to give his program that name. A more obvious account is that My Fair Lady came out in 1964 as a smash hit, and could very naturally have inspired Weizenbaum when he was trying to come up with a good name for his novel program. Given the context, the name ELIZA is both quite witty and appropriate.
I wouldn't read anything gender-related into the sort of unthreatening responses that ELIZA gives in the famous published dialogue: after all, these are the responses produced by the DOCTOR script, not by ELIZA alone, and in 1966, a doctor would have been commonly assumed to be male. On the other side, the famous dialogue involves a woman asking for help from ELIZA/DOCTOR, but again this is of limited significance, since other dialogues - most notably one of the longest and most interesting recently unearthed by Jeff Shrager - involve men asking for help.
To sum up, therefore, I'm not aware of any solid evidence that gender-related thinking played any significant role in either the conception of the Turing Test or the development of ELIZA. Both can be understood as having a fairly clear intellectual motivation that has nothing to do with gender. Whether gender-related considerations played any role in how Turing and Weizenbaum chose to present their work - e.g. in initially framing the Turing Test within the context of a gender-guessing game, or presenting ELIZA's "patient" as a distressed woman surrounded with potentially bullying men - is harder to decide (and beyond my own expertise).
A further comment on ...
UNDERSTANDING HOW ELIZA OPERATES
If any readers are interested in discovering how ELIZA operates without having to get into the intricacies of programming, I hope they might find it useful to try out a chatbot creation program called Elizabeth [https://philocomp.net/ai/elizabeth.htm], which I developed precisely to help students do this. It comes in a free download for Windows, along with teaching materials, but if you just want to see the DOCTOR script in operation, do this following:
Click on the link "Elizabeth for Windows 2.20" and unpack the ZIP file (including sub-directories and scripts directories - these must be fully unpacked for DOCTOR to work) to some directory on your system.
Run the program "Elizabeth.exe" (e.g. by double-clicking on the file name).
From the "Help" menu, select "Weizenbaum's Original DOCTOR script". This will bring up a dialog box referencing the documentation in Section 1.5 of the file "Elizabeth.pdf" (which will also have been downloaded). You might find it helpful to take a look at that, but it's not essential.
Click "OK" and browse through the "Weizenbaum.txt" script, as displayed in the Script Editor. This will give you an initial idea of the sorts of patterns to which the DOCTOR script responds.
Staying within the Script Editor window, Press CTRL-T (or else select "Transfer script into Elizabeth after saving" from the Script Editor's "File" menu). This will start up the Elizabeth main program, with the Weizenbaum DOCTOR script running. It should say "HOW DO YOU DO. PLEASE TELL ME YOUR PROBLEM." (which is the first line of the DOCTOR script).
Feel free to play around by typing in whatever inputs you want, and seeing what response comes back to you. At any point, you can start again by pressing CTRL-R within Elizabeth (or selecting "Restart with current script" from Elizabeth's "File" menu), or returning to the Script Editor and pressing CTRL-T (as above).
If you want to run the DOCTOR script with the exact inputs from Weizenbaum's article, you can type those in from Section 1.5 of the "Elizabeth.pdf" document (as mentioned above), or you can use the following shortcut ...
(a) Just after you have started the DOCTOR script running, and before you type your own first input, select "Open saved dialogue" from Elizabeth's "File" menu.
(b) The Open File dialogue will start up; now navigate from the "My Scripts" directory to "Illustrative Scripts" (which is a sibling directory), and select "WeizDoctor.doc". Elizabeth should then respond "15 dialogue inputs loaded ..."), meaning that Elizabeth now has a record of the next 15 inputs that you plan to give (i.e. the same 15 as were given in the published dialogue). Click on "OK".
(c) The script will start again, saying "HOW DO YOU DO. PLEASE TELL ME YOUR PROBLEM." Now, instead of typing anything, press the F2 key (or else select "Take input from saved dialogue" from the "File" menu). You should see the text "Men are all alike." appearing in the input box, exactly as though you had typed it there yourself.
(d) Click on the "Enter" button to enter this input. Elizabeth should respond "IN WHAT WAY?". This response has been generated by Elizabeth using the DOCTOR script, and is not remembered (only your own 15 planned inputs have been remembered).
(e) To see how the response has been generated, click on the "Trace" tab just underneath the text input and output displays, and to the right of the "Dialogue" tab. This should display 8 steps of processing, from (1) the user input, through (2) filtering and (3) identification of a keyword ("ALIKE"), then (4) selection of a response ("IN WHAT WAY?), followed by (5) an output transformation, (6) an potential action, (7) a final transformation, and (8) another potential action - but in this case, none of these last four has any effect.
(f) Now move onto the next input by pressing F2 again. You should see the text "They're always bugging us about something or other". Again press the "Enter" button, and again you'll be able to see the processing in the "Trace" tab - here the keyword is "ALWAYS", resulting in the response, "CAN YOU THINK OF A SPECIFIC EXAMPLE?".
(a) Moving on again (with F2 - "Well, my boyfriend made me come here." - and "Enter"), the processing is now shown in the "Trace" tab as consisting of 15 steps. Crucial is the fact that the second phrase starts with "my", and this is identified as a keyword which triggers an exactly matching response ("YOUR boyfriend made me come here?"), after which "me" gets changed to "YOU" by a final transformation. But also, the phrase starting with "my" has triggered memorisation of the following phrase (not owing to the keyword, as it happens, as (b) below explains), so that if you now look at the "Memory" tab (just to the right of the "Trace" tab), you will see that the phrase "boyfriend made me come here" is now recorded in Elizabeth's memory. This is destined to play an important role later in the dialogue.
(b) All of this is explained in the Elizabeth documentation, but if you want to understand how the responding and memory triggering is done, take a look at the relevant transformation data. From the "Trace" tab, we can see that there is an Input Transformation (number 034) being applied at step 7, which apparently does nothing more than changing "my" to "MY", but actually there's more to be seen if we go and look at the "Input transforms" tab. There, we see that transformation 034 starts from identification of the pattern:
[] MY [word1] [word2] [phrase]
This will match any text that starts with "MY" or "my" (capital "MY" will match either) followed by at least three more words (since "[phrase]" matches any one or more words). The "[]" at the beginning of the pattern indicates that no words occur before "MY" within the current text (so "MY" or "My" is the first word). Where this pattern is matched, we see that transformation 034 replaces the text with:
MY [word1] [word2] [phrase]
In other words, it makes no difference whatever to the text! However if you look to the right in the "Input transforms" table, you can see that there is an entry in the "Action" column, and if we click there, Elizabeth reveals that an action has been associated with this transformation, namely:
M [word1] [word2] [phrase]
This is the action that causes memorisation of "boyfriend made me come here".
(c) From here on, returning to the "Trace" tab, we see that the "my" phrase is matched again by keyword "014/01" - that is, the first keyword in set 014, followed by the response "014/01", that is, the first response in set 014. Clicking on the "Keyword transforms" tab and scrolling down, we find, indeed, the keyword "MY [phrase]" and the response "YOUR [phrase]?" in those positions. This is what generates the response. And lower down, at stage 14, we see the memorisation action actually performed (actions standardly occur after the transformations, unless specially hastened).
(d) How is all of this specified in the DOCTOR script? Well, if you look at the Elizabeth Script Editor, you will find there (put here in order of relevance to this case):
The Input Transformation which splits off "Well," from the following text:
The Input Transformation which saves the "MY" memory:
The Keyword Transformation which generates the response:
and the Final Transformation which coverts from "me" to "YOU":
This illustrates how you can "look under the bonnet" to see how the DOCTOR script is operating, starting from the "Trace" tab. Experimenting with your own inputs, while also looking at the DOCTOR script, will help to give you familiarity with the sort of thing involved. I'm not aware of any other ELIZA implementation that enables students to do this, and that's why I developed Elizabeth as an educational chatbot system.
Of course this DOCTOR script is not exactly the same as Weizenbaum's original, but it is very closely modeled on it, and includes exactly the same keyword sets etc., as transcribed from the famous 1966 paper. Until Jeff Shrager's recent discoveries, I thought this implementation was functionally identical with Weizenbaum's ELIZA, but now I am not so sure - Anthony Hay has identified a "counting" issue which could lead to discrepancies in some cases (including in one of the dialogues unearthed by Jeff). So the research continues, spurred by these discoveries!
Hi @peter.millican. That's really interesting background to the Turing test and ELIZA.
In case it’s of interest to others, here are a few notes about my experience of reimplementing ELIZA from JW’s description in the CACM paper[1] and subsequently seeing a printout of the ELIZA source code.
1. A picture is worth a thousand words
The CACM paper contains no pseudocode or flow charts of the ELIZA program. JW describes how the program works in prose to a level of detail sufficient to reimplement it, with a couple of caveats discussed below. I found it hard going trying to work from his textual description and would have loved to see a flow chart like the one from JW’s archives shown in an earlier post by @davidmberry.
2. BUT is a delimiter
The CACM paper specifies that comma and period are the only delimiters ELIZA uses to break a user’s input sentence into subclauses. Yet the example conversation in the same CACM paper cannot be reproduced unless BUT is also a delimiter. The ELIZA source code we have does use BUT as well as comma and period. (I’ve written about this in a previous comment.)
3. How "a certain counting mechanism" works
The description of ELIZA is very detailed. But for some reason JW choses to gloss over one particular mechanism. In the CACM paper on page 41 he says
As no further information is given about "a certain counting mechanism" or what "a particular state" might be I could only guess.
In the MAD-Slip code the relevant mechanism relates to a variable called LIMIT. LIMIT starts off with the value 1 and is incremented each time through the main program loop. If after incrementing LIMIT its value is 5 it is returned to 1 and the cycle repeats.
Now, only when LIMIT has the value 4 is the previously saved memory retrieved.
Here are the relevant parts of the ELIZA source
Further, in the above quoted text from the CACM paper JW says that a rule from the MEMORY list is “randomly selected.” But from the above quoted code on line 001230 we can see that in fact the selection is not random but based on a hash function of the user’s input text,
I=HASH.(BOT.(INPUT),2)+1
. I’m hoping to recreate this, but I have not yet seen the implementation of the HASH function.[1]ELIZA: A computer program for the study of natural language communication between man and machine. Communications of the ACM, 9, 36-45. (Available here: https://web.stanford.edu/class/linguist238/p36-weizenabaum.pdf)
Hi anthony_hay, this research of yours is very illuminating. I presume it follows that you would expect a memory to be used within a "no-keyword" response only 1 time in 4 on average (i.e. when the value of LIMIT is 4 rather than 1, 2, or 3)? In that case, it would be especially lucky that the memory "father made me come here" happened to be available for use when the non-keyword input "bullies" occurred in Weizenbaum's famous dialogue.
I'd also like to ask about exactly where LIMIT is incremented in the processing cycle. For this to reach 4 at the point of responding to "bullies", I think the sequence has to be as follows - here I've put the presumed value of LIMIT in brackets before each response, so as to reach 4 at the end.
[1] HOW DO YOU DO. PLEASE TELL ME YOUR PROBLEM.
Men are all alike.
[2] IN WHAT WAY?
They're always bugging us about something or other.
[3] CAN YOU THINK OF A SPECIFIC EXAMPLE?
Well, my boyfriend made me come here.
[4] YOUR BOYFRIEND MADE YOU COME HERE?
He says I'm depressed much of the time.
[1] I AM SORRY TO HEAR YOU ARE DEPRESSED.
It's true. I am unhappy.
[2] DO YOU THINK COMING HERE WILL HELP YOU NOT TO BE UNHAPPY?
I need some help, that much seems certain.
[3] WHAT WOULD IT MEAN TO YOU IF YOU GOT SOME HELP?
Perhaps I could learn to get along with my mother.
[4] TELL ME MORE ABOUT YOUR FAMILY.
My mother takes care of me.
[1] WHO ELSE IN YOUR FAMILY TAKES CARE OF YOU?
My father.
[2] YOUR FATHER?
You are like my father in some ways.
[3] WHAT RESEMBLANCE DO YOU SEE?
You are not very aggressive but I think you don't want me to notice
that.
[4] WHAT MAKES YOU THINK I AM NOT VERY AGGRESSIVE?
You don't argue with me.
[1] WHY DO YOU THINK I DON'T ARGUE WITH YOU?
You are afraid of me.
[2] DOES IT PLEASE YOU TO BELIEVE I AM AFRAID OF YOU?
My father is afraid of everybody.
[3] WHAT ELSE COMES TO MIND WHEN YOU THINK OF YOUR FATHER?
Bullies.
[4] DOES THAT HAVE ANYTHING TO DO WITH THE FACT THAT YOUR BOYFRIEND MADE
YOU COME HERE?
Does this look right on your reading of the code? I would have expected that LIMIT would be set to its initial value (i.e. 1) right at the start, and would then be incremented immediately after generating a response. But this seems not to be the case. If I understand correctly, it has to be that either:
(a) LIMIT is incremented also after saying "HOW DO YOU DO ..." (so it's equal to 2 prior to generation of the first genuine response "IN WHAT WAY?").
or
(b) LIMIT is incremented before generating each response (so it becomes equal to 2 immediately prior to generation of the first response "IN WHAT WAY?").
Which of these (if either) fits with your reading of the code?
I assume anyway that Weizenbaum carefully composed the published conversation - or at least that part of it - to make the article maximally persuasive. But I find it surprising that he would reduce the probability of triggering a memory to only 1 in 4 (even given that a suitable memory is available, and even when a non-keyword input has been identified - already significant conditions), when recollection of a memory is likely to be one of the most effective ways of giving the illusion of a meaningful conversation. If only we had more dialogues to examine, we would be able to do more detailed analysis to work out whether this counting mechanism played a consistent role in Weizenbaum's experiments, or whether it just happened to be set up that way in the version of the code that we now have. Do you have a view on this, Anthony?
@peter.millican Answer (b): LIMIT is incremented (line 000510) near the top of the main get user input/print response loop. So it has the value 2 at the point the first IN WHAT WAY response is given, as you show in your marked-up conversation. I think the HOW DO YOU DO message is read from the script on line 000130
LSSCPY.(THREAD.(INPUT,SCRIPT),JUNK)
and printed on line 000290TXTPRT.(JUNK,0)
. This is just prior to entering the main loop.I don't know if I dreamed it, but I thought I remember reading somewhere JW commenting that the remembered thought, e.g. DOES THAT HAVE ANYTHING TO DO WITH THE FACT THAT YOUR BOYFRIEND MADE YOU COME HERE, had greater impact when not used too frequently. But I can't find the reference just now.
I think there would be a good supply of memories to use. In the conversation you quote the user says "my" six times. So that might generate six memories. (Although I haven't checked whether "my" is the highest ranking keyword in all six cases.)
I think there were various conversations in JW's archive. It would be very interesting to have those to play with. I don't know if we would be sure which version of ELIZA was used to generate each conversation.
Please remember that my knowledge of MAD-Slip is very superficial. In the ELIZA source the occasional bits of indentation suggesting code structure sometimes don't seem to align with the code structure suggested by the actual statements, which makes me doubt my understanding. If anyone here was able to annotate the ELIZA code - indent it to reflect the structure - that would be very useful.
I've just found an interesting slide deck about ELIZA and MAD-Slip by Jörg Kantel: http://folien.kantel-chaos-team.de/slip/#1 It's in German but Google translate helped me read it.
Another find: the manual for an implementation of ELIZA for CP/M: https://mocagh.org/firstera/eliza-manual.pdf
I'd like to recreate the Slip HASH function. We have this documentation from page 30 of the University of Michigan Executive System Slip manual in Jeff's opening post
And, in the CACM paper JW says
Does anyone know where I can find the source code for 1966 implementation of the MAD-Slip HASH function?
What looks like the entire source code listing for the May 21 1966 SLIP system is in the MIT archives.
A sample of it is in the images @jshrager has already taken, but this is just the first page I think.
It also looks like the 25 April 1966 SLIP code is also there
Hi David. So we don't have the complete listing, just a sample? I hope the HASH function will in be there. Maybe in time we will get to see the whole listing. I wonder will the HASH function be written in assembler, Fortran or something else.
Hi @anthony_hay I've been trying to work out the dependencies between all these things. I think that it is:
Where the HASH function is in this mixture its hard to say. Although I might hazard a guess that the SLIP HASH function might be a wrapper for an underlying MAD function? But we'll need to look into the SLIP code to be sure.
The dependencies hypothesized by @davidmberry (Hi David!) are a series of "layered" languages from assembly to a domain-specific language developed specifically for the implementation of ELIZA scripts. I think this is one of the first examples of the MIT approach to programming language design in which domain-specific languages are built "on top of" more widely known languages; an approach popularized years later in Abelson and Sussman's textbook The Structure and Interpretation of Programming Languages. I think this is important to keep in mind because, from the MIT/SICP perspective, the script listed at the end of Weizenbaum's 1966 paper could be considered to be the source code. While it is fantastic to have the "lower levels" (MAD-SLIP, etc.) now available for study consider how, in contemporary publications, if we include code -- let's say a listing of a program in JavaScript -- we assert that we have included the source code even if we reveal none of the "lower levels." This is a norm of OSS too: the implementation of, for example, the JavaScript interpreter is not also included in a "source code listing," even if we might regret that several years later when the language standard changes!
I mention this because if we dwell too long in the lower levels of the implementation we forget the remarkable context of Weizenbaum's work at the very beginnings of interactive and distributed computing. Here we have one of the first programs designed to be interactive and not designed on the pattern of an algorithm (which has inputs and outputs but, by Knuth's definition, does not stop to query the user until after it is done).
Moreover, it is also remarkable because it does situate itself culturally in a discourse about gender. I think the gender concerns are obvious in both Weizenbaum and Turing. I agree with what @p_yes_t posted above and maintain that a code review of ELIZA should be sutured closely to an analysis of gender. I started writing about gender, ELIZA, and Turing's test in my contribution to Console-ing Passions: Television, Video and Feminism, Madison, WI, April 25-28, 1996: Warren Sack, “Replaying Turing's Imitation Game." I attach a copy here. I discussed then, and am still discussing today, why many in the field of artificial intelligence (AI) attempted to purge from AI Turing's concerns about gender by -- first -- renaming Turing's imitation game the "Turing test." Even a casual reading of Turing's 1951 text demonstrates it is not a test but a game. And then second, AI researchers, in the 1990s, disavowed the use of "Turing's test" as an important benchmark for AI programs. Removing gender concerns from the research agenda of AI has taken years of concerted effort and this is the venue for us to push back!
@warrensack (Hi Warren! :-) raises an interesting methodological question regarding a code reading regarding how we might scope that reading. I guess my feeling is that there is no necessity to halt a reading at any particular level, indeed it behoves us to follow the question all the way down (regardless of the number of turtles), depending on what it is we are trying to understand. For some, indeed many, questions there is no necessity to dig down below the "ground truth" of the level of analysis we are starting at (e.g. ELIZA in MAD-SLIP here), but some functions may need further depth or context to get a grip on (e.g. the HASH function).
Here, I am particularly thinking of the way in which it is becoming clearer that not only are there multiple ELIZA's but that this has an important bearing on its identity as a research object. So when we talk about ELIZA in future, perhaps we should be more aware of the multiplicity of its identity as a software object. Especially as versioning seems pretty loose in the 1960s. ELIZA is certainly a work in progress, less than a finished software object, and very much like a process of research activity with stop-offs along the way.
Also I do think that some of the historical specificity of the other levels which surround ELIZA point to its uniqueness in terms of the constellation of technology that was used to construct it. So, for example, it would be rare today to hard code extensions to an underlying computer programming language in assembly in order to extend its functionality to make ELIZA possible in the first place (after all that is what SLIP is doing).
So whilst I do have sympathy with the idea of applying Occam's razor when looking at code, where you can, I also think that we can and should move horizontally and vertically through code when that is called for.
I also think @warrensack makes me think about the extent to we are looking at both a technical object, a cultural object and a historical object and that these things might not always be the same thing. After all, ELIZA (as merged with DOCTOR) has become such a cultural object in its own right (which calls to be examined), that ELIZA's own history and technical specificity have become obscured (which also need to be uncovered and understood).
Hi @warrensack. Sorry I've been dwelling on the details somewhat. I look forward to reading the paper you posted and following the conversations. I have a lot to learn!
@davidberry 's statement that "when we talk about ELIZA in future, perhaps we should be more aware of the multiplicity of its identity as a software object" resonates with me.
Weizenbaum wrote a series of versions, but also inspired many others -- even in the 1960s -- to write their own versions in other languages. The reproductions of ELIZA made it not a singular entity but a set and thereby produced new cultural effects. I wrote about one such effect for a paper on computational psychoanalysis and semiotics I presented at the 1997 College Art Association (here attached): Warren Sack, “On-Line Language Games," College Art Association (CAA97), New York, New York, February 12-15, 1997.
Weizenbaum’s former colleague at MIT, Daniel Bobrow, told the following story at a conference in 1969. At the time of the story Bobrow was across town from MIT at a company called BBN.
“One Saturday morning about 9 a.m., a BBN Vice President in charge of selling our Telcomp commercial service arrived at our PDP-1 Computer Room hoping to be able to use the computer for a demonstration. He found a note on the PDP-1 teletype that read: “TYPE ALL MESSAGES INTO THIS TELETYPE, AND END THEM WITH A PERIOD.” This note was left there by one of the programming bums who had just succeeded in making run a LISP version of the DOCTOR program (based on ELIZA as developed by Weizenbaum). However, the VP thought that this note indicated that this teletype was linked with the one in my home, since I often used the computer all night. Therefore, he started typing to “me”, but in fact was typing to this version of the DOCTOR program. The following conversation ensued:
VP: Do you think that I can use the computer this morning?
D: WHY DO YOU ASK?
VP: I might be able to make some additional Telcomp sales.
D: WHY AREN’T YOU SURE?
VP: My prospective customers have never seen a demonstration of the system.
D: DOES THIS MEAN VERY MUCH TO YOU?
VP: Of course it does.
D: YOU SEEM VERY POSITIVE ABOUT THAT.
VP: This is ridiculous.
D: WHAT DO YOU MEAN THIS IS RIDICULOUS?
VP: Is there any reason why I can’t use the computer now?
D: TELL ME MORE ABOUT YOUR PROSPECTIVE CUSTOMERS.
VP: Please dial me up on 491-1850
Note that after the last remark the VP did not obey instructions, and left out the period. Therefore, of course, the computer didn’t answer him. This so infuriated the VP, who thought I [Bobrow] was playing games with him, that he called me up, woke me from a deep sleep, and said:
VP: Why are you being so snotty to me?
B: What do you mean why am I being so snotty to you?
The VP angrily read me the dialogue that 'we' had been having, and couldn’t get any response but laughter from me. It took a while to convince him it really was the computer.” (from Bobrow, 1969 reproduced in Margaret A. Boden, Artificial intelligence and natural man (New York: Basic Books, 1977).
What is remarkable about this translation from MAD-SLIP to LISP is not the change in programming language or even any slight changes in functionality but the change to a distributed, interactive computer environment that was, clearly, quite new to the BBN Vice President. Considering ELIZA's repetitions/iterations/translations/reimplementations are, to follow @davidberry, ways to understand "the multiplicity of its identity."
A closely related question to @davidberry 's about the multiplicity of ELIZA's identity concerns what philosopher Jacques Derrida called "iterability": Does ELIZA remain ELIZA even in a new language, written by someone other than Weizenbaum, designed for a different computing environment (e.g., distributed, remember the ARPAnet was still not online then), and created for a new audience, a new set of "readers" (e.g., Bobrow's Vice President)? We might pose this question about ELIZA, DOCTOR, MAD-SLIP, or any part of the original source code. What is lost and gained in its reiteration?
One corpus of code to use in considering these questions could be Weizenbaum's different versions; or the larger set of all ELIZA implementations created in the 1960s; or -- perhaps -- the huge corpus composed of decades of student programs when ELIZA was commonly the first programming assignment for most AI courses (until about the mid-1990s). See, for instance, the then-ubiquitous textbook, Peter Norvig (1991) Paradigms of AI Programming: Case Studies in Common Lisp.
@jshrager 's site links to a set of ELIZA implementations here.
@warrensack I guess that is an open challenge to produce a comprehensive ELIZA family tree (geneaology). That really would be an interesting visualisation of the history of ELIZA.
To my mind, @warrensack's contention that "the script listed at the end of Weizenbaum's 1966 paper could be considered to be the source code", and the MAD-SLIP code a mere interpreter, is too simplistic. First of all, JW himself gave the name ELIZA to the MAD-SLIP code, not the script (which was called DOCTOR). Second, there are SLIP primitives -- YMATCH and ASSMBL -- that appear to have been implemented for (or at least only used for, as far as we know) in ELIZA. (These do not appear in JW's earlier publication about SLIP.) Also, ELIZA (the MAD-SLIP code) was explicitly teachable (as in her namesake).
In his 1966 CACM paper JW says ELIZA is a “A Computer Program For the Study of Natural Language Communication Between Man And Machine.” (I assume the use of the word Man was at the time a common idiom meaning mankind/humans and is in no way intended to show any kind of bias.) He was interested in the effect that communicating with a machine in natural language had on people, what they believed about who or what they were talking to and what this might tell us about the wider field of AI.
Can anyone help me to understand in what way specifically the ELIZA code in combination with the DOCTOR script is misogynistic, anti-feminist, homophobic, anti-trans or is biased against any other group in any way?
Is there something specifically in this code one can point to that shows gender or other bias?
Is it that it is neutral, but in the context in which it was developed or used neutrality shows tacit support for misogyny or some other bad thing?
Is it that other people somehow used ELIZA/DOCTOR, or suggested it could be used in a certain way, or were inspired by it, to undermine or hurt specific groups? If so, does that mean ELIZA/DOCTOR is at fault in some way?
If I cut a branch from a tree - maybe I want a walking stick - and someone else projects onto that branch the idea of a murder weapon, is that the fault of the branch? Does it show I must have harboured thoughts of violence?
I find the moralising in JW’s book Computer Power and Human Reason, e.g. about compulsive computer programmers, somewhat irritating. There are other parts of that book I didn’t agree with, but I don’t recall noticing any gender bias. But to reiterate, I don’t understand how specifically ELIZA/DOCTOR shows gender bias.
Here's a letter that I sent to Jeff (I hope he forgives me). I've included the code for YMATCH using GNU gSLIP. Just saying it can be coded and it looks almost like real C++ code.
Hi Jeff;
Well, ahem and aho, I just looked (closely, even to the point of scrutinizing) your letter to me. No, no, no. What am I saying. I looked at https://sites.google.com/view/elizagen-org/the-original-eliza?authuser=0, closely. With beaded eyes and jaundiced breath. And I came to the conclusion that your comment
is, well, is. So in a fit of pique I summarily assembled what small wit I have and constructed YMATCH. It has not been checked for anything, that's what you get when you use an editor. I have tried to be faithful to the MAD_SLIPManual but, well, there are one or two edge cases that were left out which I think I included. I have included (copious) comments which I hope will explain my interpretation of what I saw in the manual.
The example is meant to show the implementation difference between the original SLIP and gSLIP and with what ease the gSLIP has in solving the same issues and yielding the same results as SLIP. Although the results are the same, the coding is different, and to my untrained eye, simpler. This comment goes throughout. Creation of lists, insertions of cells, comparison of datum, and etc. are made easier (I think, you might think differently). The entire algorithm is 35 SLOC, and I admit some clever crafting might reduce this even further.
If this is at least 'interesting' I'll try to implement ASSMBL.
======== code ========
include "Slip.h"
/**
* @brief gSlip equivalent to N:YMATCH function in MAD-Slip
*
* Pattern matching is done by comparing the input rule against
* a list. For the nonce, the list does not contain any sublist.
* This interpretation seems consistent with the example given
* in MAD_SLIPManual.pdf, in that the example and definition do
* not separately specify any mechanism which can recognize
* and process a sublist.
*
* The comparison is done in a linear fashion, starting at the
* first cell in the rule and the input list. The code logic
* seems to be:
* 1. If the spec cell is an integer
* a. If the spec is zero, create a sublist containing
* all input list cells from the current cell to the
* last cell in the input list. Append this sublist
* to the result and a return a success.
* b. If the spec is a number > 0, then create a sublist
* containing that number of cells from the input list
* and append this list to the result. Advance the
* input list 'pointer' to the number of cells copied
* and the rule list by 1.
* c. If the spec is a number > 0 and there are less than
* number of cells left in the input list, then we fail.
* d. If he spec is a number < 0, fail.
* 2. If the spec cell is a literal (as defined in MAD_Slip
* a literal is a string) then:
* a. If there is no match to the current input cell, then
* we fail.
* b. If there is a match to the correct input cell, then
* create a sublist and append it to the result. Advance
* the input list 'pointer' by 1 and the rule list 'pointer'
* by 1.
* 3. If the rule list is a sublist, then advance over it (ignore
* all sublists).
* 4. If the input list is a sublist, then advance over it
* (ignore all sublists).
* 5. Terminate processing when either the rule list is empty
* or the input list is empty. Note 'empty' means that the
* list 'pointer' points to the list header. It does not
* mean that the original list contains no elements.
*
* Some Notes:
* 1. The algorithm is non-destructive. The input list parameters
* are unchanged.
* 2. The algorithm is primed by advancing over the input list
* parameters to the first cell in the list. If the list is
* empty, then the first cell in the list is the list header
* and this terminates processing.
* 3. The list 'pointer' is never seen by the application. The
* application only sees the current list cell being processed.
* 4. Step 1.a. implies that an input spec of zero (0) must be
* the last spec in the input rules.
* 5. Step 1.c. this condition is not specified in MAD_SLIPManual.
* It is assumed to be the intent of the writer. An alternative
* would be to declare this an error and fixup, but there
* is no way to report an error back to the caller.
* 6. Rule comparison is linear. It goes from left to right (start
* to finish) without backup. Once a comparison is made and is
* successful, the rule advances.
* 7. Step 2 is the nub of the argument. This specifies the exact
* mechanism for comparing rule to the input list. Part of this
* is that a failure comparison between a rule literal and the
* input list cell causes the function to fail.
* 8. No mechanism is specified in MAD_SLIPManual to treat sublists.
* It is assumed that sublists are not entered but that if the
* input spec is a number, then sublists are copied.
* 9. There is an assumption that the output result is an empty
* list on entry.
* 10. On error, the output result is not emptied.
*
* @param[IN] rule rename L1
* @param[IN] list rename L2
* @param[OUT] result rename L3
/
int YMATCH(SlipHeader rule, SlipHeader list, SlipHeader result ) {
SlipCell cell = input.advanceLER(); //!< advance to first slip cell
SlipCell spec = rule.advanceLER(); //!< advnace to first rule
//!< advance in the rule
for (; !cell.isHeader() && !spec.isHeadaer(); spec.advanceLWR() ) {
if (spec.isSublist()) continue; //!< sublists in the rule are excluded
if (cell.isSublist()) continue; //!< sublists in the input list are excluded
if (spec.isNumber()) {
if (spec < 0) continue;
SlipHeader head = new SlipHeader();
if (spec == 0) {
for (; !cell.isHeader(); cell.advanceLWR()) {
head.enqueue(cell);
}
} else {
int i;
for (i = 0; (i < spec) && !cell.isHeader(); cell.advanceLWR()) {
head.enqueue(cell);
}
if (i != spec) return 1;
}
cell.advanceLWL(); // we went too far
result.enqueue(head); // put a sublist into the result
// The assumption is that we search until a string
// match is found. If the requirement is that the
// next string in the input list must be the literal
// in the spec, then the for loop is replaced by a
// conditional.
} else if (spec.isString() { // spec must be a literal
for (; !cell.isHeader() && cell != spec; cell.advanceLWR());
if (cell.isHeader()) cell.advanceLWL(); // did not find, fixup list pointer
if (cell != spec) return 1; // a string match was not found
SlipHeader* head = new SlipHeader();
head.enqueue(cell);
result.enqueue(head);
} else { // action unspecified
}
}
return (int)result.isEmpty();
} // int YMATCH()
@jshrager: My suggestion that we treat the script at the end of the 1966 article as source code was an attempt to get us to focus on the various ways that the script could be implemented. This suggestion was probably not necessary in this thread where we are seeing so much work going into reimplementing the program and its parts, such as @aschwarz 's YMATCH posted earlier this morning. Why consider reimplementations, indeed why spend time writing code, in a code review? I think the answer is that a reimplementation/translation/iteration/repetition of the original code is an interpretation of the original code. So, in my opinion, software studies, and critical code studies, should entail writing code as well as writing prose. Writing code forces us to rethink old code in contemporary terms. For example, how much matching code do we need to rewrite ELIZA today when most languages support regular expression matching? And, are we writing a fundamentally different program if we write the scripts using regular expressions? Again, it is a question of, as I put it earlier, "iterability": Does ELIZA remain ELIZA even in a new language, written by someone other than Weizenbaum, designed for a different computing environment , and created for a new audience, a new set of "readers." We might pose this question about ELIZA, DOCTOR, MAD-SLIP, or any part of the original source code. What is lost and gained in its reiteration? I think this way of working, what Marc Davis and I called in a 1994 paper "critical reimplementation" (Warren Sack & Marc Davis, “IDIC: Assembling Video Sequences from Story Plans and Content Annotations,” in Proceedings of the IEEE International Conference on Multimedia Computing and Systems, Boston, MA, May 14-19, 1994), allows us to find the most significant pieces of code in a given system, the parts of the code that distinguish it from other systems past and present.
Another example: When Nick Montfort approached me about collaborating on 10 PRINT, I immediately rewrote the BASIC code in Perl and JavaScript to see what was most interesting about the BASIC code. It showed me that a certain hardware and character set was presumed by the original author. While I didn't manage to hang with the 10 PRINT project until the end, I think the importance of reimplementation was well received by the rest of the collective authors' group, as reflected in the book itself and, before that, in our joint presentation to the 2010 CCCWG: Nick Montfort, Patsy Baudoin, John Bell, Ian Bogost, Jeremy Douglass, Mary Flanagan, Mark Marino, Michael Mateas, Casey Reas, Warren Sack, Mark Sample, and Noah Vawter, "Studying Software by Porting and Reimplementation: A BASIC Case," Critical Code Studies Conference, University of Southern California, 23 July 2010.
Indeed, @warrensack, you offered some great insights and a technique that was important to 10 PRINT CHR$(202.5+RND(1)); GOTO 10 and is also important to a current project of mine. The last thanks we give in the book are “to Warren Sack for his Perl and Javascript ports, the first ports discussed in the book and the ones that introduced us to the idea of porting 10 PRINT as a way of better understanding it.”
I greatly appreciate the close work being done in this thread and have been reading it with interest, by the way. I’ve hesitated to mention anything because I have little to add.
While this is lightweight and speculative compared to the very good new analysis happening here, I recall that in 2008 Andrew Stern and I did a presentation at the ELO conference, “Provocation by Program: Imagining a Next-Revolution Eliza.” We didn’t publish anything official, but we posted the text of our presentation on Grand Text Auto and with difficulty I have excavated it.
Of six important attributes that we identified, number 5 was “Being general to different computer platforms and easily ported,” so I’m interested in the sharper discussion of this aspect going on now.
@anthony_hay : You wrote, "I find the moralising in JW’s book Computer Power and Human Reason, e.g. about compulsive computer programmers, somewhat irritating. There are other parts of that book I didn’t agree with, but I don’t recall noticing any gender bias. But to reiterate, I don’t understand how specifically ELIZA/DOCTOR shows gender bias."
I think, what we see in the book, is Weizenbaum's morals of the moment spelled out. Weizenbaum's own sense of morality obviously changed radically from when he was working on ELIZA to when he published the book. The early paper @jshrager shared above, where Weizenbaum is talking about computer programs as slaves, is a stark example.
Even before the book, Weizenbaum was in a feud with his former collaborator, Kenneth Colby (UCLA). Weizenbaum thought it immoral to use computer programs as psychotherapists while Colby went on to found a company to create such robotherapists. By the time of the publication of the book, Weizenbaum had absorbed the anti-technology stance of the Frankfurt School of Critical Theory (Adorno, Horkheimer, etc.) which makes the moralizing in the book sound like the words of repentant sinner. In those pages, his former creation, ELIZA, strikes him as grotesquely immoral.
But ELIZA is only obviously immoral if one condemns instrumental reason and its automation in machines as the Frankfurt School did. There are other moral systems in which answering a patient according to a strict set of rules is the morally correct thing to do; rules that could, at least in principle, be implemented as a program. I have a long discussion of this in an interview/article I co-authored with the anthropologist Joe Dumit in 2000 (abstract here). For me, the most succinct explanation of the social function of ELIZA is given by Lucy Suchman in her book Plans and Situated Actions: The Problem of Human-Machine Communication in which she discusses the functionality of ELIZA not just in terms of Rogerian psychotherapy but in a much longer history of social science research that begins in the early 20th c. using what Karl Mannheim called "the documentary method," and that is extensively employed in Harold Garfinkel's ethnomethodology -- even today with technologists/anthropologists, like Paul Dourish (UC Irvine), who employ an ethnomethodogical framework in their research and software development.
The position Weizenbaum takes in the book corners him into understanding of not just ELIZA but any kind of machinic interaction as immoral -- thus Rogerian psychotherapy, Freudian and Lacanian psychoanalysis, etc. would also be immoral.
If we are looking for this interpretation of the (im)morality of ELIZA we can see it in its functionality, its performance as reflected in the DOCTOR script, but there will not be some small bit of code from the full system, say the YMATCH function, we can point to and say "Aha, there's the of kernel evil in the system." Thus, my concern with keeping eyes on the "top-level" functionality of ELIZA and not worrying too much about "low-level" implementation details (as expressed in my earlier comments on why I'm so enthusiastic about reimplementation as a form of interpretation).
Moreover, we will be hard pressed to find ELIZA as morally suspect if we are, say, a Rogerian therapist, someone who employs methods of interaction implemented in ELIZA, or even if we simply diverge from the Frankfurt School party line Weizenbaum found so enrapturing when he published his book.
Just to pick up a point that @warrensack made, I just wanted to note that I don't think that claiming that the Frankfurt School is anti-technology is a fair representation of a wide constellation of positions within the Institute for Social Research.
In any case, Weizenbaum himself notes his ideas owe a great debt to Lewis Mumford, Noam Chomsky and Steven Marcus. He also refers to concerns about the "unfettered march of science and technology" and the contributions of Arendt, Ellul, Roszak, Comfort and Boulding to his thinking. He even references Hubert Dreyfus and John Dewey, as far from the Frankfurt School as it is possible to be. He also opens the book with a vignette from Polyani. Indeed, rather than a Marxian critique, he is much more interested in the danger of a deficit of "participatory politics" under conditions of "tools" that "irreversibly disable formerly available modes of social behaviour" (p. 38). Where he does quote Horkheimer, he does so to note the hegemony of a particular form of rationality which can lead to dehumanisation (such as Weizenbaum notes in the Nazi regime in Germany). We should remember that Weizenbaum, who was Jewish, fled Nazi Germany with his parents and arrived in the United States in the mid-1930s. He was well attuned to the dangers of certain forms of instrumental rationality when linked to a racist and bureaucratic political regime (e.g. its use of IBM punch cards for processing data).
He certainly makes as a strictly political (not moral objection) when he writes:
This makes me wonder if ELIZA/DOCTOR awoke Weizenbaum from his computational slumbers precisely because of a problem of the dangers of manipulation and misrecognition that it engendered for the human user. A pretence of sympathy or interpersonal respect when strictly speaking the computer was following an instrumental programmed logic. Through deception the software design was transforming a potentially mutually transformative communicative encounter with the human user into an alienated one.
This was also the link to his split with Colby who wished to automate psychotherapy arguably without sufficient concern for the actual harm this might cause patients (and indeed Colby went on to commercialise precisely this type of software for the US military).
It is interesting that in much of the work around ELIZA in the late 1960s, which to my mind we tend to read far too often through the DOCTOR script, Weizenbaum and others were taken by the teaching potential of the software and many of his examples speak to this (e.g. as the ARITHM and SYNTCA scripts show). And yet by 1975 when he finished Computer Power and Human Reason the potential for teaching by computers is absent completely from his argument and DOCTOR now stands as an example of the excesses of instrumental reason as a deficient form of interpersonal communication.
Perhaps it was the potential limitless compilation of ELIZA scripts that could be created and marketed by commercial companies that worried Weizenbaum? Or in the hands of the state an easily automated potential propaganda tool ceaselessly working to further a regime through a library of scripts dedicated to its (mindless) defence? A computerised propaganda machine? He definitely hints towards this in Computer Power and Human Reason when he worries about natural language processing and speech recognition noting that "perhaps the only reason that there is very little government surveillance of telephone conversations in many countries of the world is that such surveillance takes so much manpower."
ELIZA/DOCTOR as mass media sounds a lot like an anticipation of social media today, with its bots, automated AI discourse and shallow alienated form of sociality. So I do think Weizenbaum's questions about it remain important and timely.
ELIZA/DOCTOR called Weizenbaum to ask about the ethics of computer science and how its rapid developments should be subject to democratic political control, so I think we should definitely be trying to uncover why this software dyad was seen as particularly problematic by him. Does the specificity of its program or interactions through the MAD-SLIP/SCRIPT layering hold the key?
@davidmberry : Thanks for correcting my oversimplifying of the Frankfurt School and my characterization of Weizenbaum et al. as anti-technologists. I was unclear how many on this thread would be familiar with the philosophical references Weizenbaum makes in the book and so I chose to be sloppy about it. I apologize to everyone here!
My main point is this: Weizenbaum's sense of the accomplishment of ELIZA and his judgment of the morality of its function changed quite dramatically in the decade between 1966 and 1976 and that we, too, might consider ELIZA problematic or, alternatively, inspiring depending upon the moral framework we bring to our interpretation.
Also, in response to @davidmberry : I do agree that ELIZA/DOCTOR seems to anticipate bots in social media today but, again, I think we need to think about iterability. Are those bots really good translations of ELIZA/DOCTOR or are they not? I think most of them are not since few produce the kind of conversation that ELIZA/DOCTOR was intended to produce: a form of conversation in which the humans are asked a series of open-ended questions. Bots today generally answer questions, amplify political differences, and advertise products. So yes, in terms of low-level code there are a number of similarities between Weizenbaum's program and the bots of today, but the bots of today do not simulate a therapeutic interaction. And, we need to remember Microsoft's Tay bot (2016) when we consider whether ELIZA/DOCTOR was "not as good" or less sophisticated as a piece of software.
The issues we are broaching -- the applicability of Weizenbaum's thinking to today -- must be under serious consideration at the newly founded Weizenbaum Institute for the Networked Society in Berlin. Has anyone here spoken with the researchers there?
Dear @nickm: I'd love to read the ELO presentation you did with Andrew Stern --"Provocation by Program: Imagining a Next-Revolution Eliza" -- but I can't get the link you provided to work. Maybe you could post it here?
Whoops, @warrensack — that link is probably more than a decade out of date. I mean to include the Internet Archive’s Wayback Machine link to the article.
Thanks!
Re: the methodology of translation as interpretation, where is code delimited, etc. - @warrensack it seems like you're in part thinking of the Benjamin essay on translation here? I agree that a translation is an interpretation. I also think there are some odd things going on very specifically with code that aren't present in everyday language translations. For code, translation is definitely an interpretation and also definitely not an interpretation. The reason a javascript snippet "is" the code for the program is that in principle, according to computer scientists, technically speaking computer languages do not form a hierarchy, ever, full stop. No language is run on top of another one, but is translated to another one. This is the funny thing about the Turing machines from the 1936 paper: Turing doesn't give a description of a complete machine which is a universal calculating machine; he gives a description of certain abstract characteristics of that machine. Turing machines are universal, it turns out, because any machine implementing those abstract characteristics in a definite way can "run" (translate) the code of any machine implementing those abstract characteristics in a different definite way. That is, individual Turing machines are universal because they are mutually translatable (translation as transliteration, but that is another issue). And yet any individual Turing-complete language is completely accidental; these languages don't form a hierarchy. Now, of course in practice they do form a hierarchy, which is reflected in countless terms like "high" and "low" level language, "bare" iron, etc. And this mutual translation must be an interpretation, since each individual machine is particular and accidental, and yet this mutual translation must not be an interpretation, since the precise equivalence of translations is what makes these individual machines Turing machines to begin with.
So I think there's a weird tension there. If MAD/SLIP is operating on a level where it doesn't feel right not to include it with the program, what's going on? If we argue that the reason is that the language of the DOCTOR program isn't Turing complete (and I haven't looked to see if it is or isn't), then we would end up with the strange result that the DOCTOR program isn't a standalone piece of code, unless we add things to the language in which it is written (altering ELIZA), which then make that language Turing complete. In other words, without changing a single character of the DOCTOR script we could change it from depending on another program for its interpretation to standing alone as an autonomous piece of code.
That is certainly a strange result, but I think it is what follows, and this illustrates something I've been generally on about with the relationship between code and state (here: data). Code exists at all by not being just stuff on the computer. Code is a special kind of stuff: the stuff that isn't the ordinary stuff, data, state, YouTube videos, PDF documents (oh, wait!), etc. Scripts like DOCTOR are in between, fine, but they're in between the special computer stuff and the ordinary computer stuff, which are still categories. And yet this specialness that we attempt to delimit evaporates when we start to interrogate it. Every input box on the web is a Turing complete code input, if we can only find that magic sequence of characters that breaks out of the container code and lets us write and run code on the server ("Why yes, my name is '"; ..."'). Code is universal and accidental, not universal and essential, but there is a great deal of apparatus devoted towards making it appear otherwise.
Also: just a quick note that the Frankfurt school is following Lukacs, and Lukacs is following Weber, and Weber wrote his dissertation (or maybe habilitation) on double entry bookkeeping in which he really ought to have been a whole hell of a lot more historical than he was. Luca Pacioli made mathematical innovations at the same time as he introduced double entry, and it is important that this history is not just the waxing or waning of a calculative practice that preexisted double entry. One of the obstacles CCS encounters in the humanities is a very Weberian notion of calculative rationality that confuses a history of the uses of calculation with a history of calculation itself. I did not know about how how all of this played into Weizenbaum's thought, so that is definitely of interest here!
I want to dive for a moment into something very specific, and I think relevant to the recent comments. (I'll spare everyone the long list of @...'s.) There is a part of ELIZA that, it seems to me, was critical to its original code, and indeed to its original name(!), although is entirely left out of, as far as I know, every subsequent implementation. That is, the ability to teach the program new rules.
The name "ELIZA" actually only appears once in the entire listing, on line 217. (All numbers here blow refer to commit d54d2eb of https://github.com/jeffshrager/elizagen.org/blob/master/1965_Weizenbaum_MAD-SLIP/MAD-SLIP_translation.txt on Jul 30, 2021) Everything below is the main body of what we usually think of as ELIZA, and everything above is utility and subroutine. The largest of these "sub" functions is called CHANGE (lines 8-95), and this is apparently accessed by entering a "+" at the console (lines 270-272):
The change routine seems to be a combination of debugging and inspection (as one might naturally expect), but also appears to great the ability to create new rules. I'm not sure of this -- it's hard to read what-all it is specifically doing. But if I'm right about this -- that ELIZA -- that is, the original MAD-SLIP code per se -- allowed the user to instruct it -- to add new ways of speaking -- this seems to be to fundamentally change the way one should think about both ELIZA itself and how it relates to the given scripts, such as DOCTOR, as well as Weizenbaum's project. I need to do the scholarship of finding out where (if at all) this capability is described; It's possible that it was literally just for testing (which would suggested by it not being mentioned anyplace else).
Not perhaps specific to this thread, but shouldn't any "code reading" have a way to point to a specific line of code? There are technical ways to do so: if the source is in github, one can write
https://github.com/jeffshrager/elizagen.org/blob/59d501c7faeec2fe6ee3208cd647c5ce7dfc197f/1965_Weizenbaum_MAD-SLIP/MAD-SLIP_translation.txt#L270
But it is github-specific. I think it could be useful to define a general citation grammar, as in traditional "text reading". Or, if it exists, I'm simply not aware of it.
Hi @jshrager. I wonder if this quote from JW's 1966 CACM paper is relevant to your last post?
Interestingly, I can't see any reference to EDIT in the ELIZA code. Instead there is the CHANGE function you mention, which appears to support the commands
"TYPE","SUBST","APPEND","ADD","START","RANK","DISPLA"
.By the way, I've spotted a typo in the transcript and translation. Line 000070 on the transcript is
V'S $NUMB = $ I3 *$ 000070
but should be
V'S SNUMB = $ I3 *$ 000070
Hi @warrensack. What I was trying to ask is is there some obviously bigoted remarks or behaviours in the ELIZA code or DOCTOR script that I have not noticed? I think the answer is, probably not.
An unsubtle example might be a script containing a pattern that matched any input containing the word WOMAN and the associated response might be DON'T YOU AGREE THAT A WOMAN'S PLACE IS IN THE HOME. I don't believe there is anything like this in ELIZA/DOCTOR.
I know virtually nothing about the bigger picture: the intentions of the creator of ELIZA/DOCTOR and the effects it had on the audience (people sitting at the terminal interacting with ELIZA/DOCTOR; the people watching these interactions; the people chosing to use the program for their own purposes).
But I'm enjoying the discussion!
I'm really fascinated by @warrensack use of the notion of "iterability" as a methodology and approach to studying code. I wondered if you have a publication where you have used it in the sense which you use it, which, I think, seems different from the Derridean usage as non-identical repetition. If iterability implies plurality and incompleteness (for Derrida), a differential repetition of traits, towards a notion of repetition that constitutes ideality (in a Husserlean sense), does this imply a particular way of reading code that requires the later instantiations (in this case of ELIZA) to constitute the ideality of the original ELIZA/DOCTOR?
I do like the idea of problematising an ideality of a Husserl-like ideal objectivity, however, we are not talking about something like an abstract "triangularity" when we talk about ELIZA/DOCTOR. It has a material existence as source code, which is its starting point (or a historical event) such as Husserl argues in The Origin of Geometry. Unless, I guess, we suggest that the ELIZA/DOCTOR that we have here, is merely one point in the attempt by Weizenbaum and later many others, to iterate on the ideas of an ideality of ELIZA? Such that there is no ideal objectivity of ELIZA?
This seems to have very counter-intuitive methodological implications for a critical code studies approach. I guess it would make for a very radical counter reading of attempts to classify the source code in the way we are doing in this discussion
I look forward to hearing more!
@davidmberry I'm not entirely sure that this is directly relevant, but as I'm sure you (and everyone else here) is well aware (and has been referred to many times in the above), there is the concept of a program "version", and version control is a major topic in software engineering. But there are other similar concepts, like "fork" and "branch" that are used in fairly standardized ways by software engineers, but which are all more-or-less related to version control, and are, for the most part, practical functions. However, speaking here just as a software engineer, this concept of "identity" that you are pointing to, at least as I (rather vaguely) understand it, touches on something that us software engineers feel all the time, esp. those working in research. We quite often are developing code with different instantiations, although relevantly different, are part of the same conceptual project. I'm not speaking about different modules of a project, but different version of the same overall project (or large subcomponent), and which are no really different "versions" in the sense that that latest one is the "real" one, nor are they quite forks or branches, because they all contribute to the whole. A specific example that I happen to be working on right now is that I am building a biomedical model -- a fairly complex simulation program. There are several ... whatever we want to call these ... I'll use "varieties" ... there are several varieties of this model, each exploring a different aspect of the problem. They are substantial the same, and yet at the same time, substantially different, and together comprise (if I'm using that correctly) the project as a whole, not as version or forks of one model, but different models that share a common theme. It's sort of like a community of people. We're all the same but different, and the community is created specifically by virtue of this at-the-same-time similarity and yet difference.
@ebuswell: Your comments on "lower" and "higher" level languages, translation, and Turing completeness are fascinating! I have some ideas about these issues too -- and a full explanation of what I mean by "translation" -- in my book, which is a little long-winded, sorry! The Software Arts, MIT Press, 2019. A set of examples I use in the book to subvert the idea of high- and low-level languages is the use of cellular automata (CA) which are simultaneously as "low" as you can go (they are just arrays of bits, matrices of black and white squares) and as "high" as theoretical computer science allows since, for example, The Game of Life, is Turing complete. CAs are an interesting, graphical, medium in which to discuss programs as data and data as programs. Maybe this is oblique to your second comment in which you observe the "confus[ion] of a history of the uses of calculation with a history of calculation itself," but I'll say it anyways: we all know most of the common programming languages in use today are Turing complete, but their uses are quite different and thus they are designed for different communities to make different tasks easy today. We tend to, in discussions of Turing completeness, to forget that there are multiple ways in which different Turing complete languages are very different! Put more in personal terms, there are reasons I no longer code in FORTRAN even if it is Turing complete.
@jshrager : Your discovery of the CHANGE function in the code is very exciting to me. The computer scientist, philosopher and historian, Tomas Petricek has a current of research in which he is looking at the history of programming environments as distinguished from programming languages. As you know, in programming language research we might be concerned with defining the semantics of a language and establishing that it is Turing complete, while, in programming environment design, we create ways of writing and debugging code. Tomas's point, if I understand him correctly, is that in some historical examples, I think INTERLISP was one of his, there is no easy separation between environment and language. The CHANGE function is a peek into ELIZA as an environment and not just a language in which DOCTOR is written in. I think this would be a great direction to discuss!
Here is an example of YMATCH and ASSMBL written in gSLIP.
If there are other told and untold functions that you might want to have created, please send them to me and I will unjudicially try to provide them.
gSLIP is substantially different in appearance than SLIP. However, it has the same functionality (with extensions).
The code is attached and unattached. The unattached code allows direct analysis and perspective. The attached code allows consequent deliberation. Enjoy.
A Note: The code extension is 'txt' not "cpp". The list does not accept ".cpp"
================ code ================
```# include "Slip.h"
```# include "Slip.h"
// there are only two choice for a RULE:
// either it is a number or a stringif (spec.isString()) result.enqueue(spec.currentCell());
else if (cell.isDatum()) return; // lists can not have dataelse { // it is a number
size_t diffNDX = spec.currentCell() - listIndex; // differential positionlistIndex += diffNDX;
if (listIndex < 1) return; // went back too farelse if (listIndex > cell.size()) // went forward too far
else if (diffNDX >= 0) {for (; diffNDX > 0); cell.advanceLER(), diffNDX--)
if (cell.isDatum()) return;if (cell.isDatum()) return;
} else { // diffNDX < 0for (; diffNDX < 0); cell.advanceLEl(), diffNDX++);
}``` SlipSequencer sublist((SlipHeader)cell.currentCell());
```} // void ASSMBL(SlipHeader rule, SlipHeader list, SlipHeader result)
@davidmberry : Regarding "iterability": Yes, I do diverge from Derrida and what I am trying to label here with the term is more the set of phenomena/working methods that @jshrager highlights in his last post on versioning systems and forking and his notion of "varieties," as well as related concerns like refactoring, reimplementing, porting, and translating software systems.
Derrida's notion of iterability, or Deleuze's insights into repetition, help us understand what it means to write something (even a piece of code) again and for a new environment or context or language. I find it inspiring to reconsider Derrida's notion of iterability and performativity which leads to a reconsideration of Austin and Searle on speech acts: Can we say or write the same thing and yet get different results depending on the time or context? Conversely, can we say or write something different and yet achieve the same result?
Reflecting on the iterability of a piece of code entails questioning what about the original version is tied to a specific context (say a specific machine or computing environment) and what is possible, even necessary, to be repeated to get it to work in a different context? I still haven't finished the essay by Nick Montfort and Andrew Stern that @nickm shared with us yesterday, but I think their "six important aspects of Eliza" are an answer to the question of what would it mean to reiterate Eliza today.
I think the book by Geoff Cox and Alex McLean (who is not on this thread but, I believe, right now elsewhere in the working group as @yaxu), Speaking Code: Coding as Aesthetic and Political Expression (MIT Press, 2013), wherein they address a number of concerns about code and speech acts, is important to this discussion.
The importance here is to understand code as performative language, language that does something. My previous writings have rarely cited Derrida and instead tried to craft new language about "critical reimplementations," code "translations," etc. and, when I do go to the philosophical register, I usually employ Deleuze, speech act theory, conversation analysis, and ethnomethodology, as in our discussion of repetition in my 2000 interview with Joe Dumit: “Artificial Participation: An Interview with Warren Sack,” _Zeroing in on the Year 2000: The Final Edition (Late Editions, 8) _George E. Marcus, Editor (Chicago: University of Chicago Press, 2000).
When faced with an original source code listing, like the one @jshrager offers us here, focussing on iterability/repetition/translation/reimplementation/porting nudges us to sort through the details, decide what is important and what is not when/if we reimplement it and make it perform, make it work, make it function, again in new circumstances as it did in its original context. Of course to define "function as it once did" opens all kinds of concerns: technological, political, economic, cultural, psychological, and so forth.
@warrensack I guess the problem with iterability (which reminds me of my use of the term iteracy elsewhere) is that it doesn't seem suitable as a method for understanding complex software objects, over say 1000 LOC. Certainly when we think of the millions of lines of code used in some apps and infrastructural software, iterability would, perhaps be more challenging. But I do think that in terms of close reading (particularly of specific functions or methods) the notion of iterating on the code is very important.
Where I defined iteracy I argued,
I attempted using a method of iteracy/iterability using the programming language Zajal (created by Ramsey Nasser) and in a previous discussion at CCSWG2012 with Mark Marino, Marino then iterated my code himself, and in the process transformed it.*
I like the fact that we are iterating on CCSWG 2012 and Zajal by discussing this here but Nasser's work was also discussed CCSWG2014 by Roopika Risam, Adaline Koh, and Amit Ray in relation to his language قلب (Alb or “heart”).
Here are the videos of the output of the Zajal code I used to describe iteracy:
My Zajal implementation
Mark Marino's iterated version.
* Zajal is the name of an ancient Andalusian form of poetry, traditional to Nasser's native Lebanon. At a Zajal performance, poets called zajjaali improvise complex and ingenious rhyming verse on the spot. Nasser's language is named after this art form, as it is meant to enable programmers to fluidly improvise their code as they go, the way the zajjaali create their poetry. See The Zajal Programming Language.
But to pick up another dimension to the notion of iteracy/iterability is that it is suggestive of the idea of collecting together the genealogy of implementations of a software object (as versions, referring back to @jshrager above). So ELIZA would be a good case study.
This has interesting implications for the development not of a cognitive map, in the sense of Jameson, but more in terms of what we might call a "pattern map" of a software object.
Here, I am linking back to the notion of a software pattern, derived from the work of Christopher Alexander et al, and influential through the notion of software pattern design, particularly from the "Gang of Four" in the book Design Patterns: Elements of Reusable Object-Oriented Software which was published in 1994 (Gamma et al 1994).*
They write:
Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice." Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context.
So a software design pattern, or software pattern, is very conducive to iterability.
* Thanks to Michael Dieter for a productive discussion of this. But also see Dieter, M. (2015) ‘Dark Patterns: Interface Design, Augmentation and Crisis’, in David Berry and Michael Dieter (eds) Postdigital Aesthetics: Art, Computation and Design, Basingstoke: Palgrave Macmillian, pp. 163-178.
*This article by Henry M. Walker is also interesting in thinking about pattern-matching, ELIZA and object-oriented programming. It also points to yet more implementations (iterations) of ELIZA*
BTW, developing a genealogy of ELIZAs was precisely my original idea in creating ELIZAgen.org. The “gen” part is for “genealogy”, and that’s the subheading of the site. I had in mind creating a distance metric, and then using biological phylogeny tree methods. Anyone have a CS grad student who wants a cool project? Here's a description of the project that I crated a while back (I haven't updated this at all for the current context, so it may be slightly tangential): https://sites.google.com/view/elizagen-org/eliza-phylogeny-project
“Chrestomathies,” like the site Rosetta Code, are resources for (programming) language learners which short passages (of code) or algorithms are translated into multiple languages. For example, the first ever programming language written was Ada Lovelace’s algorithm for calculating Bernoulli numbers written for Babbage’s machine in 1843. How do we calculate Bernoulli numbers today? The Rosetta Code site provides an answer in 56 different programming languages. These programming chrestomathies (there are more than one) demonstrate what I have in mind when I am talking about iterability. But, most of what these chrestomathies include are algorithms (i.e., procedures that have inputs and outputs and that terminate) and not interactive systems, like ELIZA. @davidmberry ’s suggestion that beyond algorithms, software design patterns — modeled on Alexander’s design patterns — could also be iterated. I think this is a great idea. And, if so, then one could image @jshrager ’s family tree of ELIZAs as an entry in a such a chrestomathy. Then, we might ask, what are the design patterns incorporated into ELIZA?
@warrensack, I hope you won't mind if I dispute your interpretation of Turing. Your paper says "Turing’s original proposal was, essentially, to build a machine to function as a man pretending to be a woman" - and there is one sentence in his 1950 paper that suggests this - but against it, there is huge textual evidence on the other side. I summarised some of this in my post above, and referenced an article by Piccinini which gives a pretty thorough treatment. But for example:
Turing's first hint of an imitation-style test in 1948 involved chess, not gender. And although he introduces the test as a three-player "imitation game", the examples in the 1950 paper mainly take the form of a test involving viva-voce questioning, and this pattern continues in 1951 and 1952 (where he explicitly calls it a "test").
In the 1950 paper, the only gender-related question arises in the context of his illustrative "imitation game". Once he introduces the computer, the questions concern skill at poetry, arithmetic, and chess, with no hint of gender relevance (see especially §2, p. 442; §6.4, p. 452; and §6.5, p. 454 - page numbers from "The Essential Turing").
In §2, entitled “Critique of the New Problem” and starting immediately after he has introduced the computer as a participant, Turing six times talks explicitly of a “man” – even implying that the machine’s obvious strategy is to imitate a man – and makes no mention whatever of women or the gender issue (pp. 442-3).
In the remainder of the paper, women are mentioned only in the context of an imagined “theological objection” (§6.1 p. 449), while the words “man” or “men” occur a further 30 times (probably intended gender-neutrally).
Turing refines the test by focusing on the universality of computing, eventually leading to this: “It was suggested tentatively [at the end of §3] that the question, ‘Can machines think?’ should be replaced by ‘Are there imaginable digital computers which would do well in the imitation game?’ … But in view of the universality property we see that … [this question] … is equivalent to this, ‘Let us fix our attention on one particular digital computer C. Is it true that by modifying this computer to have an adequate storage, suitably increasing its speed of action, and providing it with an appropriate programme, C can be made to play satisfactorily the part of A in the imitation game, the part of B being taken by a man?’” (§5, p. 448). The game involves A pretending to be B, so again, the setup with B specifically being a woman has completely disappeared.
Isn't this all pretty overwhelming evidence? And as I pointed out earlier, the test really doesn't make any sense at all as a test for "intelligence" or "thinking" if it's set up as a gender-guessing imitation game.
@jshrager has been digging into the archives again and unearthed these very interesting texts which show the riches of ELIZA scripts we didn't know about dated 1967:
We now have something called the neweng ELIZA script:
I used a quick and dirty OCR using MacOS Preview
The other ELIZA script found is something called the colour script:
I used a quick and dirty OCR using MacOS Preview
So, the thing that @davidmberry just posted come from this document:
I'm totally confused by this code. Taylor describes it as follows:
But I don't know how that would work as MAD-SLIP is a compiled language. I wonder how this worked??
(BTW, I'm trying to get permission to open source the whole paper, but for the moment we can only publish fair use segments, but I'm happy to share the whole paper with anyone who emails me.)
More gems unearthed by @jshrager from a paper entitled Automated Tutoring and Its Discontents by Edwin F. Taylor.
This is the GIRL script
This is the output
The SPACKS script output (which also mentions other scripts, namely INTRVW, FVP1, CANVEC, ORTH1, ANTIPR, FVQUIZ in addition to SYNCTA,ELEVR, SPACKS)
I think this is pretty conclusive proof that ELIZA has multiple versions with very different functionality as the software is developed from 1965-68. These are the proposed main versions that were being used, I think.
After this it seems that there are two branches that develop
Both developed by Weizenbaum and both building on the earlier ELIZA foundations.
@jshrager and @davidmberry: Wow! These are fantastic finds! An analysis of ELIZA beyond the DOCTOR script will be fascinating territory!
@peter.millican: To the contrary! I am delighted to have my interpretation discussed and disputed! As I wrote, "Turing’s original proposal was, essentially, to build a machine to function as a man pretending to be a woman" and as you reply "there is one sentence in his 1950 paper that suggests this."
What you don't mention is that this "one sentence" is the first and so the most important one in the paper defining the game: page 1, section 1: "We now ask the question, ‘What will happen when a machine takes the part of A [the man] in this game?’ Will the interrogator decide wrongly as often when the game is played like this as he does when the game is played between a man and a woman? These questions replace our original, ‘Can machines think?’"
Page 1 section 1 of the paper is written to provide an unambiguous and novel approach to what he considers to be the common and absurd question "Can machines think?" Turing write, "I shall replace the question by another, which is closely related to it and is expressed in relatively unambiguous words."
With his "unambiguous words" Turing replaces the question with a game, the imitation game of gender. The game is a game and not a test: probably a Wittgensteinian language game as I argue is some of my other writings. Turing arguably learned this approach to philosophy by sitting in on Wittgenstein's seminar after Turing returned to Cambridge from Princeton.
There are many other philosophers and theorists who agree with me that the role of gender is undeniable in Turing's article. But anyone who knows what Turing suffered in his life as a gay man knows that the issue of gender was important to him.
So yes, we can, and most have, pay more attention to the subsequent rephrasing that Turing did to conclude that Turing meant the imitation game has nothing to do with gender. But recall the censorious public discourse about sex and gender of the time and one might see why he would not publicly object to the rewriting (his and others') to have it accepted.
Further, to ignore the importance of gender in Turing's proposed imitation game is to ignore the standard structure of many science and philosophy papers and his repetition of that structure: State your problem at the start. To argue that Turing didn't state the actual problem he wanted to work on at the start of the paper is simply to argue that Turing was a bad writer.
Yet, ultimately, I think the real issue here is not really so much a question about Turing's intentions. What is more interesting is to trace how Turing's imitation game of gender is taken up by many others in the following decades as, first, not a game but a "test," and how, second, all mention of gender is lost. Most AI researchers discuss it without ever addressing why Turing started with a gender game. After it had been relabelled as the "Turing test" discussions of it never needed to address games or gender. I haven't done any archival work on this, but Google ngrams seems to indicate that the term "Turing test" starts to come into play about 15 years after the publication of Turing's 1951 paper, in the mid-1960s.
From the perspective of feminist scholarship this is yet another example of where women have been written out of the history of the debate. The more important question then, in my opinion, is not what did Turing intend, but rather how and by whom has gender been so thoroughly erased from the field of artificial intelligence?
@warrensack (and @any other Software Engineers in the vicinity), can you think of how the combined ELIZA script and quasi-MAD-SLIP (prog) code combination might have worked in practice. Did MAD have an interpreted mode? Did someone build a macro facility? (This looks a bit like LISP, and LISP had the moral equivalent of macros (called FEXPRs from its earliest implementations, in the early 1960's, I believe.)
@warrensack I'd be interested to know if you believe ELIZA/DOCTOR is an example of where women have been written out of history.
Perhaps a related question: do you think JW ascribed a gender to the ELIZA/DOCTOR? Can we see that in the ELIZA code or DOCTOR script? I realise one obvious clue is in the name, ELIZA, perhaps suggesting the computer interlocutor is female?
@warrensack I think I missed something in all this trans-gendering. Turing was gay. But he apparently didn’t suggest that his game be played with gay and straight men. Is the suggestion that his framing of a man and a woman playing the game is culturally (for his time) appropriate cover language for what he really meant? (Not being gay, but living in The SF Bay Area I have numerous gay friends of all affiliations, and as far as I can tell, gay men don’t generally affiliate with women. Perhaps trans women do, but Turning wasn’t trans, right?) I guess that my point is that maybe a duck is actually just a duck, and he thought that the man/woman game was interesting, not a covert way of injecting his gender identity into his science.
@jshrager: That's an interesting question: Did MADS have an interpreted mode? I'd imagine it did because of the history of (myth?) of the origins of Lisp: Steve Russell read John McCarthy's theoretical paper and realized that the Lisp eval function could be implemented in machine code, which he did in 1958. The read-eval-print loops of Lisp would make it seem likely that MADS would have followed suite, but I don't know. It seems like a good question for a research project.
@anthony_hay: No, I do not think ELIZA/DOCTOR is an example of where women have been written out of history. ELIZA makes a clear reference to Shaw's Eliza Doolittle character and that reference clarifies what Weizenbaum was trying to do in specific cultural terms: to build a program to function like a woman who is being taught to speak by a male professor. We can worry about whether or not Weizenbaum thought of all of cultural implications when he chose the name ELIZA; and we can disagree about the gender politics of Shaw's play, but the role of the woman is still intrinsically a part of Weizenbaum's project.
This is very different from decades of discussion of the Turing's imitation game where all mention of women have been effaced from the project, and then the project itself (to write a program to pass the "Turing test") subsequently discarded from the research agenda of artificial intelligence by, for example, Patrick Hayes and Kenneth Ford, “Turing Test Considered Harmful,” Fourteenth International Joint Conference on Artificial Intelligence,. vol. 1, ed. Chris S. Mellish (San Mateo, CA: Morgan Kaufmann), 972–977. August 20–25, 1995, Montreal).
@jshrager: I totally agree with you that Turing "thought that the man/woman game was interesting, not a covert way of injecting his gender identity into his science." Turing was not very covert about his sexuality; witness his arrest for homosexual activities -- then illegal in the UK -- that he essentially confessed to the police. My point is simply that AI researchers have had a hard time calling a spade a spade (or a duck a duck, if you prefer). Turing opens his essay with a man/woman guessing game, but is repeatedly interpreted to not mean what he wrote at the beginning of the essay. Huge amounts of work has gone into avoiding discussion of what he wrote and to rewrite his imitation game as a test that has nothing to do with gender.
@warrensack You know about Harry Collins and Rob Evans’s work that uses the “original” imitation game? I’m not deeply familiar, but I think the idea is to study the human-human game. Collins is also a long time critic of AI, but I don’t know that these lines of work relate.
@jshrager: No, I don't know about the Collins and Evans's work on the imitation game. I should have a look. Collins's work is important to me because he was one of the very few, until recently, from science and technology studies (STS) who paid any attention to AI and computer science.
@warrensack As you may know (this note is partly for the info of others), Collins has been chasing Interactional Expertise ever since he realized that he could talk like a Gravitational Wave Physicist just from hanging about with them. He calls this "walking the talk", although I think it's more like "talking the walk", but anyway....Another way to think of this is, related to the present conversation, is as what the GNC community would call "passing", so although I don't think that Harry and co have done either the man/woman or the gay/straight version [although maybe someone else has -- it's gotten pretty popular in some sociological communities.]
(BTW, As a ps to my note above about Turing and living in The Bay Area: I notice that you are in Santa Cruz, where I used to teach. (SCUBA Diving, of all things! ... Indeed, I am, at this very moment, wearing a VERY OLD slug hoodie which is of a type you can't get any longer! :-) Santa Cruz used to be the center of the GNC universe....although it's drifted into gentrification of late. But anyway, I'm sure that GNC identity has changed significantly since Turing's time and place ... indeed, it seems to change monthly in modern times! It's hard for me to imagine what it must be like to be GNC in modern times, much less in Turing's time and place! I can't even easily imagine what it was like to be a computer programmer in the 1960, much less a gay man in the UK in secret military service in the 40s and 50s!)