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 NetBehaviour@netbehaviour.org http://www.netbehaviour.org/mailman/listinfo/netbehaviour
