 | |
|
by Janice J. Heiss
Jaron Lanier is well known for his work on "virtual reality," a term he coined in the 1980s. Renowned as a composer, musician, and artist, he has taught at many university computer science departments around the country, including Yale, Dartmouth, Columbia, and Penn. He recently served as the lead scientist for the National Tele-Immersion Initiative, which is devoted, among other things, to using computers to enable people in different cities to experience the illusion that they are physically together. Currently, he is working on something he calls phenotropic computing, in which the current model of software as "protocol adherence" is replaced by "pattern recognition" as a way of connecting components of software systems. In this first of a two-part interview, we met with him to talk about his vision of the fundamental changes that are needed in software development.
This current lack of scalability is a universal burden. There are monopolies in our industry because it's so difficult for anyone to even enter the competition; it's so hard to write large software applications. And that's strange to me. If you look at other things that people build, like oil refineries, or commercial aircraft, we can deal with complexity much more effectively than we can with software. The problem with software is that we've never learned how to control the side effects of choices, which we call bugs. We shouldn't be complacent about that. I still believe that there are ideas waiting to be created, and that someday we will have new ways of writing software that will overcome these problems. And that's my principal professional interest. I want to make a contribution to making bugs go away.
And that chaos is really what gets us. I don't know if I'll ever have a good idea about how to fix that. I'm working on some things, but you know, what most concerns me is what amounts to a lack of faith among programmers that the problem can even be addressed. There's been a sort of slumping into complacency over the last couple of decades. More and more, as new generations of programmers come up, there's an acceptance that this is the way things are and will always be. Perhaps that's true. Perhaps there's no avoiding it, but that's not a given. To me, this complacency about bugs is a dark cloud over all programming work. Rethinking the History of Computing
Of course, Turing was the first hacker who used a computer to break a secret code. There's a notion that you have some scheme for encoding information in time. So, you have some kind of transport layer that involves a pattern in time, and then you have variations on top of it that actually carry your signal. That's the part that varies. And computer science and basic information theory are both based on this notion. Computer architectures as we know them were first designed around simulated wires. Source code is a simulation of pulses that can be sent sequentially down a wire, as are passed variables or messages. Now, I think that's a notion that can be extended very, very, far. And if you really want to, you can even use it to describe all of nature, but it's not the only idea that could be extended that far. And it does get kind of awkward because this is not the way that natural systems work. For example, if you want to describe the connection between a rock and the ground that the rock is resting on, as if it were information being sent on a wire, it's possible to do that, but it's not the best way. It's not an elegant way of doing it. If you look at nature at large, probably a better way to describe how things connect together is that there's a surface between any two things that displays patterns. At any given instant, it might be possible to recognize those patterns.
And so you could think about information science in terms of how different pieces of the universe connect together by recognizing each other's patterns, instead of by adhering to protocol. The difference between two different pieces adhering to a protocol and sending information down a wire, and two different pieces of information having a surface between them, and recognizing patterns from each other, is one of degree. The change in emphasis relates to the kind of information about the other thing that's stored. And, in particular, it relates to temporal encoding, and whether you need a sort of a stack of the past that you use to decode what's coming down the pike. If you look at the way we write software, the metaphor of the telegraph wire sending pulses like Morse code has profoundly influenced everything we do. For instance, a variable passed to a function is a simulation of a wire. If you send a message to an object, that's a simulation of a wire. And it's not that there's anything wrong with this, but I can make an empirical observation: If you have a time-based protocol to send codes on a wire, it's inefficient to make that kind of coding error-tolerant. It's much more efficient to make it error-intolerant. So errors tend to be catastrophic. You tend to create a situation where, if you get one bit wrong in passing a variable to a function, the function does something that's not just wrong, but chaotically wrong, arbitrarily wrong, terribly wrong.
Creating Pattern Recognition Software
The other factor is that some of the mathematical techniques available to us have been improving. An example would be wavelets, which provide a way of breaking up a signal into frequency and time-based components. It's a sort of fancier version of a more familiar technique that most programmers will know about, called the Fourier transformation, or FFT for Fast Fourier Transformation. That's one example of a new pattern recognition technique, but there are others as well. So, there's a body of applied mathematics that's becoming better and better. There are also some empirical results from neuroscience that are giving us useful ideas, and that's a particularly delightful development. So just recently, we've seen better face recognizers, better face trackers, better handwriting recognizers, better gate trackers -- all kinds of things. So pattern recognition is really starting to come into its own. Sadly, a lot of that's driven by security and defense requirements, but for whatever reason, it's becoming viable. And we're at the point where computers can recognize similarities instead of perfect identities, which is essentially what pattern recognition is about. If we can move from perfection to similarity, then we can start to reexamine the way we build software. So instead of requiring protocol adherence in which each component has to be perfectly matched to other components down to the bit, we can begin to have similarity. Then a form of very graceful error tolerance, with a predictable overhead, becomes possible. The big bet I want to make as a computer scientist is that that's the secret missing ingredient that we need to create a new kind of software. "Phenotropic" is the catchword I'm proposing for this new kind of software. "Pheno" refers to "phenotype," the outward appearance of something. "Tropic" means interaction. I first published the basic ideas in a book, The Next 50 Years: Science in the First Half of the Twenty-First Century published in 2002 by Vintage Books and edited by John Brockman. In phenotropic computing, components of software would connect to each other through a gracefully error-tolerant means that's statistical and soft and fuzzy and based on pattern recognition in the way I've described. Advice to Developers
And at that point, there's a danger that you lose the faith that used to exist in prior generations: that computing could get better at a fundamental level. And since almost everybody in the whole profession goes through the academic world and out into the industrial world, everyone gets consumed in this way. So, I'm afraid we have lost our greater ambitions, and that deeply concerns me. If you talk to people who want academic careers and want to get degrees, an example of a hot topic might be quantum computing, which seems exciting. And I think it is exciting, but to me, what's much more important is how we fundamentally conceive of software. If we can't solve the problem of how to write big programs, it won't matter whether they're quantum or conventional. We're still going to have the same complexity barrier. And this overwhelmingly important issue that's at the center of everything isn't receiving the attention it deserves. I suppose we are all so emotionally committed to the particular problems under our noses that we lack the long-range faith that software could be fundamentally better. That's the long-range faith that drives fields like medicine, and I want to try to bring that faith back to computer science.
There are hundreds of challenges, and any one of them, if done well, could really improve the lives of millions of people very quickly. So, there's a lot of ripe territory. I'm going to call it "ripe," but I'm not going to call it "low hanging fruit," because I think these problems are genuinely difficult problems, and it's important not to pretend that they're easy. I think that anyone who makes progress on a problem like that deserves an enormous amount of credit. I would recommend that developers read the history of computer science very skeptically. Read some of the earlier writings by people like Turing, Shannon, and von Neumann and try to think through how these guys were wrong. What would they think about differently if they were starting out today? Here's the problem with computers: it's just so much work to think about programs that people treat the details of software as if they were acts of God. When you go to school and learn how to program, you are taught about an idea like a computer file as if it were some law of nature. But if you go back in history, files used to be controversial. The first version of the Macintosh before it was released didn't have files. Instead, they had the idea of a giant global soup of little tiny primitives like letters. There were never going to be files, because that way, you wouldn't have incompatible file formats -- right? The important thing to look at is how files became the standard. It just happened that UNIX had them, IBM mainframes had them, DOS had them, and then Windows. And then Macintosh came out with them. And with the Internet, because of the UNIX heritage, we ended up thinking in terms of moving files around and file- oriented protocols like FTP. And what happened is that the file just became a universal idea, even though it didn't start out as one. So, now, when you learn about computer science, you learn about the file as if it were an element of nature, like a photon. That's a dangerous mentality. Even if you really can't do anything about it, and you really can't practically write software without files right now, it's still important not to let your brain be bamboozled. You have to remember what's a human invention and what isn't. And you have to think about files in the same way you think about grocery carts. They are a particular invention with positive and negative elements. It's very important to keep that sense of skepticism alive. If you do that, it will really have an influence on the quality of code that you create today. See Also
Jaron Lanier's Home Page
Brief Biography of Jaron Lanier
One Half of a Manifesto
| ||||||||||||||||||||
| |
| ||||||||||||
Print-friendly Version
What's wrong with the way we create software today?
I think the whole way we write and think about software is
wrong. If you look at how things work right now, it's strange --
nobody -- and I mean nobody -- can really create big
programs in a reliable way. If we don't find a different way of
thinking about and creating software, we will not be writing
programs bigger than about 10 million lines of code, no matter
how fast our processors become. [After publication of this interview, Jaron Lanier
realized that his sentence should read: "bigger than about 20 to 30 million lines of code...".]
