Hi Daniel, Thanks for sharing with us some of the context, structure & decisions around using The Eliza program. I was intrigued of its origin and found this info about it on wikipedia...
"ELIZA is a computer program and an early example (by modern standards) of primitive natural language processing. ELIZA operated by processing users' responses to scripts, the most famous of which was DOCTOR, a simulation of a Rogerian psychotherapist. Using almost no information about human thought or emotion, DOCTOR sometimes provided a startlingly human-like interaction. ELIZA was written at MIT by Joseph Weizenbaum between 1964 to 1966." Also visited here (http://www.manifestation.com/neurotoys/eliza.php3) "ELIZA first appeared in the 60's, some people actually mistook her for human." >I'm a big fan of Rosa's work but knew little about the demoscene, >so it was great to read about it from her perspective and consider >its connection to Glitch Art. I'm watching where Rosa & JonCates and other peer glitchers take it, noticing they are bringing in their own flavour and calling it 'Critical Glitch Artware', and not Glitch Art - adding 'software art' element to it all (it seems). Oh yeah, before i forget - do you know http://runme.org/ ? I'm sure you do... I thought that your recent project would fit well amongst their software art repositories platform... >the breakdown of this data is visible as it runs: you see the >data corroding as Eliza's speech breaks down. I would like to see this in action. > I would love to write a Linux compiler -- >will definitely let you know if/when it happens. I look forward to the Linux compiler version of 'Entropy', in the meantime will hassle some one who has Microsoft/Windows and download it :-) Wishing you well. marc > Marc, > > Thanks. I'm a big fan of Rosa's work but knew little about the demoscene, so it was great to read about it from her perspective and consider its connection to Glitch Art. > > A big part of the Glitch aesthetic to me is the loss of stability. I thought this would be particularly interesting to apply to the experience of programming, since programming often has a rigid quality. Programmers need to get things just right or the program will be defective if it runs at all -- there's little room for approximation. But, of course in the real world programs are buggy -- even when they're written perfectly (which rarely happens), they run on operating systems, use standard libraries, and these huge bodies of code written by other people have their own bugs and inconsistencies (luckily for us Glitch Art folks). All code is faulty somewhere, if you dig deeply enough. > > Entropy brings this chaotic nature to the forefront. When you code in Entropy, you need to let go of this sense of control -- the most you can hope for is that the person using your program gets the gist of what you're trying to do. To program in Entropy means treating all data as limited resources that have unspecified number of uses before they've veered far enough away from their original values that they're essentially random. > > The best Entropy programs are ones that are ambiguous and structurally flexible. So if a loop runs fifty times instead of forty-five, it won't crash -- they conform to its corrosive and approximating nature. When I wrote the Eliza program, since the same data is used over and over, the breakdown of this data is visible as it runs: you see the data corroding as Eliza's speech breaks down. > > Hope that answers your question.... > > I would love to write a Linux compiler -- will definitely let you know if/when it happens. > > -Daniel > > > _______________________________________________ > NetBehaviour mailing list > [email protected] > http://www.netbehaviour.org/mailman/listinfo/netbehaviour _______________________________________________ NetBehaviour mailing list [email protected] http://www.netbehaviour.org/mailman/listinfo/netbehaviour
