Rudy Rucker - The hacker and the ants

When I wanted to get a feel for one of our Veep simmies, I would set my viewpoint so that I could see through the robot’s eyes and move its parts with my own hands. I wore the robot-model like a tuxedo, and I drove the robot around in cyberspace houses. No actual robot and no actual house-just an idea for a robot in an idea of a house. I would try and figure out what was right and wrong with the current model. If I noticed a problem with any of the hardware-bad pincer design for instance-I would go into cyberspace and use a Makita Visual Regrammarizer to change the geometry and back-propagate the changes to make a new set of specs.

Once I had a good knowledge of the kinds of things a particular robot could do, I would pull back to try and write software that could drive it around without me being “in” it. And then, I might need to change the simmie to make it work better with the new software. This process would take dozens, scores, hundreds, or even thousands of iterations. The only way to make a profit was to do as much of this as possible in virtual reality. Cybercad!

Even with the use of cybercad, the process still wouldn’t have worked if each iteration involved human judgment-for then it would have taken too long. So GoMotion was using artificial life techniques to make the evolution happen automatically. The way I’d applied this to the Veep was to look at the kinds of changes that the other programmers and I had typically been making to the code. I’d been able to cast our repeated program changes in terms of 1347 different numerical parameters that we were tweaking and re-tweaking. So now the problem of making a good Veep became the problem of finding good values for those 1347 mutually interacting numbers. To do this, Roger and I had run a process of simulated evolution on a population of a few hundred simulated Veeps that we’d installed in a virtual suburb of Our American Homes, each home with a different Veep but the same virtual family consisting of instances of Walt, Perky Pat, Dexter, and Baby Scooter Christensen.

Some of the badly parametrized virtual Veeps did things like get stuck in a corner and buff the floor so long in one place that they made a hole, or wander outside and get lost, or kill everyone in the house and burn the house down. These were parameter sets to get rid of.

Over and over the badly behaving parameter sets were replaced by combinations of the better-behaving sets, and after a quintillion machine instructions had executed we’d gotten a good design. Artificial life!

When GoMotion would get a combination of software and simmie that seemed to work well, they’d order up the parts and build a material prototype of the thing, like Studly.

Rather than keeping a big physical inventory of mechanical and electronic parts, GoMotion used Blackstone Hardware. Blackstone was a cyberspace hardware store with ghostly replicas of all available hardware components on its aethereal and all but endless shelves. All available hardware — from pinhead diodes to prestressed concrete bridge beams, from jackhammers to chip-etching lasers, from rubber washers to superconducting yttrium/iridium whiskers. It cost $1024 an hour to walk around in Blackstone’s, but it was totally worth it. Access time was fast, since you would have a knowledgeable and attentive clerk-simmie at your elbow-and once you found the part you wanted, you told the clerk and Blackstone would express mail it to you on the spot.

The Blackstone clerk had whatever appearance you wanted: clean-cut college boy, overalled graybeard, bikini-clad calendar girl-there were about fifty choices. The clerk was a simmie being run by the Blackstone catalog software, though if you had a complicated question, a person at Blackstone would slip into the clerk simmie and talk through it as if it were his or her own tuxedo. You and your clerk could be visible or invisible to the other shoppers-as you liked. For reasons of industrial security, we at GoMotion always stayed invisible in Blackstone’s, as did most other big companies’ shoppers.

The man who actually built our physical robot models was called Ken Thumb. Ken was a slim blue-collar type; soft-spoken, brilliant, implacable. Before signing on as GoMotion’s machinist he’d worked with the Survival Research Lab art/robotics group putting together big crazy machines out of parts he would find in abandoned factories and warehouses. You’d just about never see Ken in virtual reality. As someone who built real machines out of real parts, he had an irritated contempt for cyberspace.

It was a fact that cybercad designs did not always translate effectively from cyberspace to the machine shop. The cyberspace “physics” was, after all, only a limited model of Nature’s true laws. Actual materials tended to have small nicks, resonant vibrations, casting strains, thermal noises, transient voltages, and various other sources of unexpected chaoticity. This meant that some virtual reality designs failed catastrophically when first incarnated by Ken. After he fixed the design, he would post scathing e-mail messages about what we had to do to bring our specs into line with reality.

“We” in this case was not so much me as it was Dick and Chuck, the thirty-year-old guys who did most of the nitty-gritty coding up of our Veep hardware designs. Dick was the Chief Engineer. He was pretty buttoned-down. Chuck was an insanely intense Florida country boy; every time I saw him he looked more gaunt. He was into hideously violent cyberspace battle games, Roman coliseum type matches, with full medical accuracy on the spurting arteries and severed bones.

Another person I was seeing a lot at GoMotion was Jeff Pear, the tech group manager. He’d shown up and started acting like my boss only a few months earlier, which was something I still kind of resented. I hated having a boss, any boss; it was even worse than having a landlord. Pear had bailed to GoMotion from a company that had gone bankrupt using the Lisp programming language.

The problem with Lisp was that it was not a close match for what was actually going on inside any real computer. There could, in principle, be a computer for which Lisp was right; some guy had actually designed a Lisp-based computer chip way back in the nerdly dawn of computation. Jeff Pear even had a big picture of the abandoned Lisp chip on his wall: his long-lost Promised Land. But here in the real Silicon Valley, there weren’t any Lisp chips, and running Lisp on a real computer chip was like using a phrasebook to write a letter in Chinese to a friend who doesn’t speak Chinese-and then having to mail a copy of the phrasebook with the letter. Running a Lisp program on a real machine meant doing that type of meaningless extra shit a few billion times a second.

The language that I and most other hackers were using was called SuperC. SuperC was an object-oriented extension of good old C, a concise language that was closely attuned to the architecture of the chips we were using.

For the true killer speed necessary to keep our robots abreast of real time, even SuperC wasn’t fast enough. A big part of our Veep code was based on something called ROBOT. LIB, a library of machine-instruction-coded functions and utilities that Roger Coolidge had developed on his own. How Roger had managed to write such amazingly tight code was something of a mystery; it seemed superhuman, preternatural. Sometimes I briefly lost sight of the fact that my SuperC robot programs wouldn’t have worked without Roger’s ROBOT. LIB, but Roger was always ready to remind me of my oversight.

Jeff Pear was really into having meetings. At least once a week I was supposed to like physically drive to GoMotion and sit in some room with Chuck and Dick and Leonard and maybe Ken Thumb and a few others and watch while Jeff Pear drew charts on a whiteboard. A total waste of time, though I did enjoy talking to my coworkers before and after the meetings. The body has an atavistic need for physical interaction.