Slashdot Mirror
Interview with Jaron Lanier on "Phenotropic" Development
Sky Lemon writes "An interview with Jaron Lanier on Sun's Java site discusses 'phenotropic'
development versus our existing set of software paradigms. According to Jaron, the 'real difference between the current idea of software, which is protocol adherence, and the idea [he is] discussing, pattern recognition, has to do with the kinds of errors we're creating' and 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.'"
-Chuck
My Freakin Blog
The day a compiler makes programs based on what it thinks we want a program to do is the day that conventional computing goes out the window.
This was posted earlier in the week on /..
Computers will program themselves!
Please moderate this comment up. The author's clever reference to the high quality Internet Explorer ("IE") helps to demonstrate the philosophical differences between Communist RMS, and the competant corporation, Microsoft.
<cough>Bullshit.</cough>
This guy obviously knows nothing about biology. A single base change in DNA can result in mutations that cause death or spontaneous abortion. As little as a change in a single 'character' can be lethal. That's a pretty "small change" that results in a pretty big "crash."
I'm not sure if this invalidates his argument, but it certainly doesn't do much for his credibility.
"If you are an idealist it doesn't matter what you do or what goes on around you, because it isn't real anyway."-R.P.W.
we will not be writing programs bigger than about 10 million lines of code no matter how fast our processors become
And how is this a problem?
And when you link your 10 million line program with my
:|
10 million line program, we've got a 20 million line program.
This idea of an inherent limit to the complexity of
programs using current methods is pure larksvomit, and
if Jaron Lanier sells it, he's a snake oil hawker.
This is Jack's total lack of surprise ->
-I like my women like I like my tea: green-
"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."
Fantastic! We'll all get down and program small, specific routines for processing data, each one doing its' own job and doing it well. Those nasty, horrid standard protocols he refers to will allow all these small components to easily talk to each other - across architectures, networks etc.
Oh wait, this is the way it already works. Is this guy then, proposing that we learn a new way to program because our systems aren't monolithic enough? *sigh*
That is only if you consider one living been only. I think he means that is robust as an ecological balance. If a small change in the DNA base of one animal happens, he dies, and is unable to reproduce. So the 'error' was confined, and dealt with. It didn't explode giving a blue screen. Evolution is a phenomena of many living beens, not one. Even if a big change happens in a specie, most of the time the system is robust enough to absorb it and change the system into one that works. And, because of the evolutionary mechanism, only the good mutations, by definition, spread. Imagine a computer program where only the useful threads got resources allocated...
"There is no teacher but the enemy."-Mazer Rackham
...but i don't see how it's physically possible. It sounds like he's proposing that we re-structure programming languages or at least the fundamentals of programming in the languages we do know (which might as well mean creating a new language). This isn't a bad thing per se, but one example he talks about is this:
Am i stupid or something? He seems to be drawing two, completely unrelated things together. Our computers, our CPUs, our ICs, at the end of the day they're just a bundle of very, very tiny on/off switches - pure binary logic. When we develop code for this environment, we have to develop according to those binary rules. We can't say "here's a rock", but we can say "turn on these switches and those switches such so that it indicates that we are pointing to a location in memory that represents a rock".
Maybe i'm missing his point, but i just don't understand how you can redefine programming, which is by definition a means of communication with a predictable binary system (as opposed to a "probability-based system" or whatever quantum physicists like to call reality), to mean inputting some kind of "digitized" real-world pattern. It's bizarre.
I got a sig so you would remember me.
we will not be writing programs bigger than about 10 million lines of code no matter how fast our processors become.
Oh I am sure a group of say about 15 Irish kids could do it in a year.
... this guy doesn't seem to really know what he's talking about.
As someone else has mentioned, life in many respects isn't robust - and where it is, it's not relevant.
For instance, genetic code is mutable - but try doing that with machine instructions. That's why Tierra creatures are written in its own pseudo-machine language.
If there's one thing that I don't want happening in code, its tiny errors causing almost-reasonable behaviour. Brittle code is code that's easy to debug.
What he really wants is lots of small, well-defined objects or procedures doing their one task well. If you decompose a design well enough, there's nothing to limit scalability.
Good design is the answer.
I seriously doubt nature came to the elegant design of 4 base pairs overnight, so let's work hard at making it better w/o throwing a pile of dung on people's face. After all, they are the ones who have to build the pieces to get to that point.
That bastard tried to kill President Sheridan, and then ran off!
I used to like this guy.
The problem with the kind of system he's talking about is that the more robust you make it, the harder it is to change it's behavior.
Take the cockroach, for instance. It is damned hard to train 100 of them to work together to open a pickle jar.
That's because a cockroach is extremely robust at being a cockroach, which has nothing to do with teaming up with 99 other cockroaches to open a pickle jar.
I don't believe nature had a design for each individual life form, other than to be robust. That doesn't give us any particular insight into how to both design something robust that meets a specific goal, which is the point of almost all software.
Once you get to the point where the specifications of each component are as exact as they need to be to meet a specific goal, you're lacking exactly the kind of robustness that he's describing.
What he's really saying is that entropy is easy to defeat. It's not. Perhaps there will be easier ways to communicate our goals to a computer in the future, but the individual components will still need to be extremely well thought-out. I think it's the difficulty of the language that makes symbol exchange between a human and a computer difficult - the fact that the human needs an exact understanding of the problem before they can codify it isn't going to change.
Education is the silver bullet.
His comments don't seem to make any sense with regard to the way we, as humans, actually view The Real World either:
Of course a file is a human invention, but it's also a concept without which NOTHING would work - not just computers. A "file" is just an abstraction of a blob, and i mean that both in the sense of a "blob" as in "a thing" and as in "Binary Large OBject". It's a piece of data that represents something. That's exactly the same thing as looking at a house and saying "that's a house" or looking at a car and saying "that's a car". It's just a way to categorize a bunch of photons/atoms/whatever into something we can readily communicate and understand. This is HUMAN, this is how we reason. If we "saw" the universe as a bazillion photons, we'd never get anything done, because we couldn't "here is a car", we'd be describing each photon individually, which would take up millions of human lifetimes. It's a human limitation, and i don't see any way that we could just up and ignore it.
Don't get me wrong, i think what this guy is talking about is fascinating, but i also think it's got more of a place in some theoretical branch of math than in real life development.
I got a sig so you would remember me.
Macintosh launched January 1984 (link).
Windows 1.0 released November 1985 (link).
Not to mention that what he's saying is waffle... where do they dig up these guys?
Virtual reality-based applications will be needed in order to manage giant databases
"Phenotropic" is the catchword I'm proposing for this new kind of software.
Oh, those are good signs.
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.
Phht, I want my computer to be more predictable, not less.
we need to create a new kind of software.
No, what we need is an economic model that doesn't include a bunch of pointy haired bosses forcing tons of idiot (and even good) developers to spew crap.
And we need consumers to up their standards, so that crap programs can't become popular because they look shiny or promise 100,000 features that people don't need. And we need to get rid of pointy-haired bosses that choose software because of all the wrong reasons.
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.
Sounds like AI and another great method of using 10,000 GHZ CPUs to let people do simple tasks with software written by morons, instead of simply writing better code and firing and putting out of business the morons.
Basicly, the problem with his argument comes from his vague use of the word "nature." Sometimes nature behaves in such a way so that little changes make a difference. Sometimes it doesn't. It all depends on what level you look at. The same goes for a computer. Change the voltage at a chip pin from 5V to 4.9V and it still behaves fine. Change the value of a key variable, and it crashes. Modify the input to a face recognizer slightly, and it will gracefully recover.
A while back it seemed like he was in every single issue of Wired.
Just goes to show you that genius doesn't guarantee the ability to produce worth.
He thinks pattern recognition-based methods like neural networks and genetic optimization are the solution to the complexity of traditional software.
So do lots of naive people. HE has a fancy new word for it.
Yes, fuzzy computing has its place -- there are certain applications for which it's much better than traditional programming -- but it took so many millions of years for our brains to evolve to the point where we can use logic and language to solve and express problems. It's ridiculous to think we should throw that all away.
Small perturbations often have disproportional large consequences, as your DNA example illustrates. Paradoxically, as Lanier suggests, complex systems can also be amazingly fault tolerant. This is in fact the nature of complex, or chaotic, systems and some say life. However, we cannot, in general, predict which sort of behavior a complex system is likely to exhibit. Lanier seems to miss this entirely. So while his ideas are intriguing I don't think he has a good grasp of the real issues in designing "complex" software systems.
Maybe his thinking is being affected by the 10 millions miles of dreadlocks coming out of his head. :)
-MT.
The answer to all of this might be to role the concept of generative programming, with better pattern matching. Therefore companies can more intelligently apply existing, tested, debugged code to their problems and the problems of others.
Why do we need programs with more than 10 million lines of code?
Has anyone ever noticed that every time Jaron writes an essay or does an interview he tries to coin at least one new word? Dude's better suited to the philosophy department.
"It's like... chaos, man. And some funky patterns and shit. Dude, it's all PHENOTROPIC. Yeah..."
All kings is mostly rapscallions. -Mark Twain, The Adventures of Huckleberry Finn
Just looking at his picture and reading his pretentious bio, this guy annoys the crap out of me.
Obviously you "can" write mammoth programs with 1 billion lines of code without crashing. It's the kind of program you are writing that becomes critical.
Generally, serial programs are the simplest programs to write. Most serial programs control machines that do very repetitive work. It's possible to write serial programs very modularly so that each module has been checked to be bug free. Today's processors execute code so that the result is "serially" computed. Yes, the instructions are pipelined, but the result is that of a serial process.
Where we go wrong is when we start writing code that becomes non-serial. Threads that execute at the same time, serial processes that look-ahead or behind. Most OOP languages tend of obfuscate the complexities behind the code. Huge class libraries that depend on large numbers of hidden connections between other classes make programming a real pain.
Mr. Lanier might be right, but I doubt it. Seems to me that a line of code could be as simple as that of a machine language command, in which case we are already using high level compilers to spit out huge numbers of serial instructions. Does that count? I think it does. Scaling code comes only at the expense of time. Most people simply don't think about the future long enough.
My 2 cents.
I wrote the following on Dec. 20, 2002 about phenotropics. Jaron Lanier is mostly known for being the guy behind the expression "virtual reality." For its special issue "Big [and Not So Big] Ideas For 2003," CIO Magazine talked with him about a new concept -- at least for me -- phenotropics. "The thing I'm interested in now is a high-risk, speculative, fundamental new approach to computer science. I call it phenotropics," says the 42-year-old Lanier. By pheno, he means the physical appearance of something, and by tropics, he means interaction. Lanier's idea is to create a new way to tie two pieces of software together. He theorizes that two software objects should contact each other "like two objects in nature," instead of through specific modules or predetermined points of contact. Jason Lanier also talks about software diversity to enhance security. Check this column for a summary or the original article for more details."
When Virtual Reality first became au courant, I thought it was almost completely wacko, with the rare exception of a few genuine applications relating to telepresence in dangerous or remote environments. Now that we know he thinks software the size of a planet is a *good* idea, it is impossible for me to take him seriously for any purpose.
The sound of 10,000 slashdotters missing the point.
Who modded this up? A single base change in DNA is almost never fatal. For a start, considerably more than 90% of the human genome is junk that has no expressive effect anyway (according to some theories it helps protect the rest of the genome.) Even point mutations in coding sections of the DNA often do not significantly alter the shape of the protein it codes for, and many proteins are coded for in several locations in the genome.
True, single base changes can have dramatic effects, but this is rare. As an example, the human genetic equipment is so fault-tolerant that humans can be even born with 3 copies of a chromosome and still survive (Down's Syndrome).
Isn't that him in that Nissan car commercial (I think it's Nissan). It shows a shot of him pretty quickly riding in the car with some mild electronic music playing over the top, but I'm pretty sure it's him. Can anyone back me up on this?
And that's one of the advantages diploid organisms have, allowing heterozygous organisms for even a deleterious mutation to be able to live normally.
So in a way this guy's right about nature's built in error tolerance methods. But he still throws around words like "chaos" and "unpredictability" without really saying anything remarkable.
This is only part 1 of what will supposedly be a series, but this looks nothing more to me than an artist's view of a computational problem. From a pragmatic perspective, it makes obvious observations, weak statements that only cite impressive concepts (out of dynamical systems theory, computer science and biology) and proposes no answers.
To wrap it up, he suggests the reader should question where Turing, Shannon and von Neumann were wrong. Well, guess what: these were all mathematicians and even though one may question why they studied particular topics, their mathematics isn't and never will be wrong because it's logically sound.
I'm not impressed.
I think if more people get turned onto pure component-based development, then the current object-oriented paradigm could carry us much further.
You have chaotic errors where all you can say is, "Boy, this was really screwed up, and I guess I need to go in and go through the whole thing and fix it." You don't have errors that are proportionate to the source of the error.
In a way you do. Right now it's known as try() {...}catch(...) {}throw -or- COM interface -or- whatever other language you might work with that has a way to introduce error handling at the component or exact source-area level, and to handle errors gracefully.
"protocol adherence" is replaced by "pattern recognition" as a way of connecting components of software systems.
That would mean a whole new generation of viruses that thrive on the new software model. That would certainly stir things up a bit. Of course any pioneered methadology is subject to many problems.
But I'm not putting down his theory, just commenting on it. The guy's obviously a deep thinker. We need people to push the envelope and challenge our current knowledge like that. Overall the theory is extremely interesting, although the practicality of it will have to be proven, as with all other new ideas.
It's the hair.
This guy reminds of Ira Einhorn , the hippie guru who BS'd his way into lots of "adjunct appointments" like Mr. Lanier's page says he has. Lots of companies thought he was some eccentric genius because he said freaky things and dressed weird.
we will not be writing programs bigger than about 10 million lines of code no matter how fast our processors become.
You can only drink 30 or 40 glasses of beer a day, no matter how rich you are. -- Colonel Adolphus Busch
There really is a hard limit to just about everything...
These guys want to weed out all code which is not perfectly flawless and fullfills 100 percent it's obejctives.
They want to use genetic meta-programming algorithms to create new code from the old one. But only the "pure code" is allowed to recoded, evolve and grow on. Code with even minor bugs is subjected to oblivion.
Besides the obvious fact that this "superior" code is an evolutionary cul-de-sac, it's also a crypto fascist agenda which should be not toleranted in the open source movement. Imagine yourself that the code would be humans that people like RMS or Linus Torvalds would never have been bred for their anchestors having a long beard and no shower or even wearing glasses. This is morally flawed, even it's just lines of C sources. And note that Linux would never have reached it's modern state for having lot's of bugs in this infancy.
Owner of a Mensa membership card.
and the full text of the interview. I'm starting to think he's onto something, given such newer areas of research as chaos theory and complexity . For the uninformed, these are the folks who bring you such things as fractal generation and the "butterfly effect". (I have purchased hardcopy/books a few years ago). I hope he will correct me if I'm wrong, but I think that what Jaron's question really is, is "At which point can we not use complex computations/computers to model the "real" world (FSVO $REAL)? If our computational mechanisims and models approach the complexity of the "real", how can we validate our results against a third-party?" Just an idea.
C|N>K
Give him a break.. He's got some points. And at least he's thinking about real and genuine problems. I see a lot of people commenting with the 'who needs 10 million lines of code?' shtick. Sounds familiar.
We're going to need to do things in a decade or two that would require 10 million lines of code (measured by current languages), just as the things we do now would require 10 million lines of code in 1960's languages.
The new languages and techniques that we have now provided ways for us to reduce the apparent complexity of programs. This guy is just looking for a way to do that again. Certainly there is room to disagree with his techniques for accomplishing this, but it is shortsighted to deny the problem.
Sumarry: In order to duplicate the features of a biological organism Jaron Lanier finds desirable, you'd end up with a programming language maybe something like Lisp, but a lot like Malbolge. Malbolge, the programming language of the future, is a free download!
There's something about the way complexity builds up in nature so that if you have a small change, it results in sufficiently small results; it's possible to have incremental evolution.
Firstly, that simply isn't true at all; as someone who understands both computer programing and genetics (my degrees are in Biochemistry and Computer Science) I can say with confidence that this is all hogwash.
The same is true of most of what supposedly imports biological concepts into computing. Neural nets and genetic algorithms are very useful tools, and they have been inspired by what we see in nature, but in terms of how they really function, under what circumstances they function, what sorts of problems they are suited for solving - a neural net is nothing like a real nervous system.
As a biologist I put it this way - a neural net is a very poor model of a nervous system. Genetic algorithms are utterly dreadful models for natural selection.
So, in this (utterly stupid) comparison between computer source code and living genomes, Jaron Lanier asserts that a living organism is somehow fault tolerant while a program is not. Let me disassemble this assertion.
Firstly, a living organism is far larger than any single computer program, even windows. Living organism == computer is far more appropo. The Genome (analogous to source code) of a living organism runs up to the billions of bits; the proteome (the concentrations and structures of the proteins that do the actual work of the living organism) would map, even in a single celled organism, to some vastly larger and more complex structure, terrabytes of data at LEAST. You can say, "that's his point!" But this level of complexity is CONSTRUCTED FROM SMALLER PIECES; individual genes. We can duplicate the complexity of a living organism in a computer without duplicating the complexity of a living organism within a single program. If each program can be as complex as an individual gene (thousands of bytes? Easy!) and produce executable code as complex as an individual protein (this is actually harder, but I believe it is possible) than your program construct can mimic the level of complexity of a biological organism.
So, how IS it that all of this complexity (a human organism) is bug free, while a computer program is not?
Firstly, the human organism is NOT "bug free." There are all sorts of inputs (chemicals) that cause aberrant behavior of every sort. Bugs happen with some random frequency, anyway. Over time, even if nothing else did, the accumulated errors in your biological processes would kill you.
Secondly, to the extent that the human organism is, in some abstract sense, more fault tolerant than a computer program, recall that the human organism is NOT designed (warning: science in progress. All creationists are asked to leave the room.) BILLIONS OF YEARS of trial and error have gone into the selection of the protein sequences that give us such problem free use (or not!) every day of our lives. With a development cycle that long, even Windows could be bugfree.
Thirdly, there is another consequence to our having evolved (rather than having been designed) - inefficient use of memory. Most of the "junk DNA" probably serves some purpose, but brevity is barely a consideration at all (in a larger organism, such as you are I. In fast replicating organisms, such as bacteria or yeast, there is far less genetic packaging.) We are extremely tolerant to mutations in these regions of junk DNA - there are analagous regions in a computer memory were substitutions are tolerated; bit flips in the picture of autumn leaves displayed as my desktop would not crash my machine - in fact, this image is a bitmap, I wouldn't even NOTICE the changes. If we applied natural selection to our computer programs, some regions of high-fault tolerance code might eventually evolve into something functional; my desktop picture might evolve into awk (Okay, now I'm being silly.)
In something which has been DESIGNED, you short-circuit all of that. The code of your computer program is not filler, pictures or stuffing; it doesn't, it CAN'T share the properties of these dispensible DNA sequences - it isn't dispensible! There are a number of single-nucleotide substitutions (equivalent to flipping a single bit) that will kill you stone dead! Your computer program is not less fault tolerant than the core sequences of the ribosome, the structure which you use to convert nucleic acid sequences (your genome) into protein sequences (proteome.)
Now, it is true, there are other places in your DNA where a bitflip will alter some chemical constant in a non-fatal (possibly beneficial) fashion. Might we not duplicate this property in a programming language? A computer language with this property would have certain desirable properties, if you wanted your computer program to evolve toward a certain function through a series of bitflips. Indeed, there are computer languages which have this property, to some degree or another. LISP does. Do you know what programming language really EXEMPLIFIES this property? Malbolge.
Who wants to program in Malbolge? Raise your hands, kids! A protein does one job, instead of another, because it has affinity for one substrate/chemical, instead of another. In a computer, you'd duplicate this sort of thing by fiddling with constants, and not by changing the source code at all. Small, low order changes in these constants would have incremental effects on what your program actually did.
Malbolge duplicates this property very nicely.
To me, this complacency about bugs is a dark cloud over all programming work.
Personally, I believe that this problem is fundamentally solved, and has been for some time. Heap on more degrees of abstraction. If I wanted to write a program that would take 1 billion lines of C-Code, I'd write a higher level language, and write in that, instead.
The good and new comes from no quarter where it is looked for, and is always something different from what is expected.
Would you buy a CPU which is full of bugs?
No? Why? Because it wouldn't be very usable?
Would you use software which contains bugs?
Yes? Why? Because it remains usable...
It is possible to write bugfree software,
but there's no need to for the average joe market.
Seriously, has there ever been a need to write a program of 10 million lines?
Exactly. I don't care how many lines of code there are in the kernel or glibc or glib or gtk or Xlib or SDL -- I happily use them without worrying about them. If you sum all of them up, you can probably get some insane LOC count...but it's modularized.
May we never see th
The analogy to the universe is important. The whole approach to physical sciences has been to simplify the rules (analogous to the lines of code) to as simple equations as possible. So the universe can be described with just a few equations with the rest just being data.
I think Jaron is onto something, but his conclusions are off. I think current methodologies are just where we need to go. Keep the code as simple (small) as possible and put the data in some database or something.
Just think of Microsoft... our favorite whipping Mega Corp... when separate groups work on millions of lines of code and try to piece it all together then the result is not always ideal. But when the goal is simple code and simple protocols then we get better software.
There seem to be only two ways to break the need to write code line by line. Either it evolves (and it is possible that evolved software will work exactly as this article suggests, living off fuzzy patterns rather than black/white choices). Or it is built, by humans, using deliberate construction techniques. You can't really mix these any more than you can grow a house or build a tree. We already use evolution, chaos theory, and natural selection to construct objects (animals, plants), so doing this for software is nothing radical.
But how about the other route? The answer lies in abstracting useful models, no just in repacking code into objects. The entire Internet is built around one kind of abstract model - protocols - but there are many others to play with. Take a set of problems, abstract into models that work at a human level, and make software that implements the models, if necesary by generating your million line programs. It is no big deal - I routinely go this way, turning 50-line XML models into what must be at least 10m-line assembler programs.
Abstract complexity, generate code, and the only limits are those in your head.
Sig for sale or rent. One previous user. Inquire within.
This guy obviously knows nothing about biology. A single base change in DNA can result in mutations that cause death or spontaneous abortion. As little as a change in a single 'character' can be lethal. That's a pretty "small change" that results in a pretty big "crash."
I think most of the data in DNA requires multiple base pair changes to have a major impact -- I'm not a biologist, though. Otherwise, radiation from the Sun would mutate the bejeezus out of everyone all the time.
May we never see th
You're certainly right that it's hard to change, but I don't even think we need to go that far. It's hard to *make* a system like this. Nature used brute force, a massive computer, and bazillions of years to do it, and didn't get to specify much about what came out the other end.
May we never see th
A friend recently got a $90 plane fair to France. Business class. And got bumped up to First because it was oversold. There was a computer error, but the airline had to honor the offer. Much of that flight was sold at the $90 price.
Right now, if that error's there, and the sale goes through, you can in principle track it back to whose error it is. If it was in an agent's system rather than the airline's, for instance, the airline could recover from the agent. So in Jaron's tomorrow, when things are matched by patterns instead of precisely, and an error happens, is it the case that no one exactly is responsible? Would you want to do business with someone whose systems just approximately, sort of matched up with yours? If yours are running on rough approximation rather than exactitude too, can a determination ever be made of ownership of a particular error?
Maybe it will all balance out. Maybe large errors will become less frequent as Jaron claims. But small errors, in being tolerated, will become an overhead of corruption. Perhaps a predictable overhead, as he claims, but what's to keep it from inflating over time, as programming practices become laxer because nobody can really get blamed for the errors any more, because they'll be at best even more difficult to localize than now, and at worst totally impossible to pin down?
"with their freedom lost all virtue lose" - Milton
This is a thought that had been crossing my mind recently. I mean, look at the games industry. Look at the complexity of games as they have evolved over the last 10 years or so. The manpower to produce a commercial game now is exponentially more than it was then. Programmers, testers, artists, 3D designers, musicians, management....there is already a barrier to complexity there...cost, time to market, talent?
Complexity is definitely becoming a problem but arbitrarily picking 10 million as the magic barrier is a little naive. He discounts the evolutionary process of development. Tools, languages, libraries get richer every day (slowly).
IMHO, the solution lies in the development of testing tools. When you can write an automated test harness that can fix the bugs that it finds, then we are making progress!
"I have been around the world and found that only stupid people are breeding" -- Harvey Danger
*sigh*
I thought my life had moved beyond this.
That tired old training cockroaches to open a pickle jar example has just been beaten to death.
Let it rest Viking Coder, let it rest.
Looking at this I don't see anything revolutionary in what is proposed, just something hard to do. Of course we work hard at signal processing, pattern recognition and clustering algorithms. They are used for everything from Medical Imaging, Radar, Oil Exploration to trying to automatically call balls and strikes. What I see being proposed here would be to look at interfaces between hmm... modules for lack of a better term in a similar way. If you want it is a far out extension of the idea of Object Request Brokers.
For example, a very large system would have a goal seeking component creating a plan, it would inquire as to what modules are available, look at the interfaces around and classify them (here is where the clustering and pattern recognition might help) and then choose ones which fit its plan. It would then check results to see if this worked closely enough to move it along its plan.
This implies a database of types of modules and effects, a lower level standard protocal for inquiring and responding, and another means of checking results and recognizing similarity to a wanted state - a second place where the recognition and clustering algorithms would be useful. This is obviously not easy to do...
The novel "Night Sky Mine" by Melissa Scott comes to mind as an example of this taken way out. There is an ecology of programs that is viewed by "programmers" through a tool that re-inforces the metaphor of programs being living organisms "trained" or used by the programmers to get what they want. I cannot see this being generically useful - many times we really do want a "brittle" system. It is certainly a way to get to very complex systems for simulation or study or games!
i think comparing computer science to nature is a pretty unfair comparison. Nature is analog, computers are digital. You can make computers seem like they are fuzzy recognizing, but underneath it all, it is, it is a very strict set of rules. Also, faults tolerance for an entire ecosystem is very high, but for the individual is very, very low. So if there is a small defect in my heart, the human race will continue without a hitch, but i won't and neither will my family... So putting fault tolerances into software might make an entire system stay up and running, it might behave slightly differently every time it adjusts for an error. After a while it might behave completely differently than what it was designed to. and IMHO, that's bad.
The reason computers are so powerful and useful is there strict adherence to the rules, and the fact that it should be able to reproduce exactly repeatable results, no matter how often it is ran.
Nature and computers play two completely different roles in our society, and trying to make one to be like the other seems for non-logical and detrimental.
Amazing to read such conservatism from people working in such a dynamic, versatile industry, who owe their very jobs to people considerably more imaginative and gound breaking than they are.
." Nonsense. Computers pretty much can be whatever we want - that is the whole essence of the Turing Principle.
The very visionaries you castigate *invented* the computer partly because they were interested in whether machines could simulate human thinking.
People like Turing and Von Neumann for example.
You wouldn't even have a computer if it wasn't for these 'visionaries' who 'want to make computers operate like the human mind'.
"They aren't brains and shouldn't be.
I get the feeling that this hippie was smoking a little bit too much of something right before he gave this interview.
NATURE IS ALL JUST PATTERNS MAN! I TOOK SOME MUSHROOMS AND THE WHITE RABBIT TOLD ME ALL ABOUT IT, MAN.
Mr Lanier doesn't tell us how to do this... hmmm interesting, does his "research" has any results? Think about it. We can have components that communicate with each other not by explicit interfaces like now, but some fuzzy way. I don't find it a great idea. :)
Or we can have components which do their work using some more fuzzyness than they use now and keep very strict interfaces. I don't know... It's up to the programmer to use fuzzy logic or AI or whatever.
Also the underlying hardware will remain binary, very fault intolerant, so with Mr Lanier's thinking shouldn't we design "phenotropic" hardware? Meanning everything in It so far was a dead end street? I don't think so.
I think he should ellaborate on his idea otherwise he'll be the only one who understands what he's trying to say - in the best case
Actually pad're, he's right & you're wrong. Organisms express powerful monitoring systems to STOMP single basepair DNA errors. Those errors are identified, chopped out and re-built. Fast. When such built-in repair systems fail, an organism dies in it's "native" environs. 'Course that also explains why evolution occurs only at the fringes.
This completely ignores the kind of non-linearity we mean when we talk about chaos theory. Small changes in initial conditions can create huge variations in output, which is why it is incredibly hard to predict the weather, the random motions of a billiard break, or even the exact positions of the planets thousands of years from now.
This dude is so far divorced from reality that he doesn't even realize how non-virtual his virtual reality is. He thinks there are no bugs in real life. He thinks any bug in computer programs (he isn't much of a programmer) can crash the net. Maybe a serious bug in Exchange, IIS, or SQL Server can slow it down a bit, but a very minor problem, like a loose wire on a 747 can kill hundreds of people. A security oversight in the same plane can kill thousands. On a less morbid note, has anyone here ever had their car break down? I've got a linux system running gnome using gcc, star office, mozilla, which is computing with websites, chat servers, and clients, email, and more on windows, linux, and other servers. I'd say that's more than 10 million lines of code all working together.
I somehow fail to see what Lanier is contributing to any of this, other than picking up some buzzwords and trying to make a name for himself.
The problem with software design can be traced to the problem of a business design that we are trying to describe in our software. And business is a result of evolution (business evolution) so it is just as complicated as some biological systems.
The problem with software implementation is that all business rules need to be converted into machine language with full understanding of effect of every line of code upon every other line of code (good coding practices and different paradigms help with that), of course we also have deadlines that nature seems to know nothing about. I suppose that to get one feature right the nature can spend thousands and millions of years, and that feature still was not designed, it was evolved. With software we do not have that kind of luxury.
We cannot yet compare software design to evolution, we can only compare software design to hardware design that is also done by humans. And hardware is complex and software is complex, only for software there are more expectations - it always solves a new problem, where for hardware the problems are limited - increase speed, increase memory size. Software seems to be the most complicated out of all artifficial systems ever built by humans.
Will we ever simplify the way software is written? Will the simpliffication be based on pattern recognition? Will software have properties of nature - will it be satisfied with similar results as opposed to precise results? I have problems with that - software has to describe a business system and if it does not describe a business system precisely than we are changing business rules. I don't believe that business software will be written to accept results that are just close enough unless the business specifies that as a requirement. Normally (from what I've experienced in 5.5 years of professional programming, and in total of 14 years of programming) business requirements are quite precise and if they are not, they are incomplete.
Creating another paradign or another language for software development only seems to delegate the problem and shift it from one layer to another, but at some point the code has to be written (some software 'architects' like this delegation thing, but they forget that it has to be written somewhere, you cannot delegate infinetely.)
I believe in componentized software systems with well designed APIs between them, nothing more nothing less. Good luck.
You can't handle the truth.
As long as day to day coding is made up of tasks like preventing one-off errors and null pointer references, then the really big and great programs like an artificial intelligence or a _full_ natural language interface, will never be written. Computers are virtual machines - their ability to model anything is their amazing strength - so, why as coders, have we chosen to make the development of code so brittle? Perhaps we didn't "choose" this, perhaps we just failed to choose something else, but we code in the fashion that we do because we made it that way, and as Jaron Lanier points out, it doesn't have to be that way. Coding is the rendering of ideas into machine executable form. The process of coding is ours to construct. Fast proceessors, cheap memory and storage and ubiquitous network connectivity are around the corner, if not here today. These have traditionally been the shackles that held coding back. But they are gone now (or will be soon), we can change the way things are done.
And Lanier's comments that nature is robust? no way. A divorce is an OS crash. The extiction of a species is the obsolesence of a program. A still born baby is Windows ME. The universe has bugs.
Bullshit, More Shit, Piled higher and Deeper.
;).
Doh, I can spout BS too.
If he's talking about following nature then he should know that nature tends to reuse old code a lot. So what if grocery carts/filesystems are dumb ideas, evolution won't throw them away if they aren't totally terrible. So you don't write 10 million lines from scratch. You write a little every now and then.
The main problem with scaling is copyright and patent laws. Such artificial monopolies (especially with those 120+ year terms) mean you often have to reimplement stuff from scratch even if a decent solution already exists.
Why is the article associating lines of code with complexity? Complexity has little to do with lines of code. And why is he talking about complexity and big programs almost as if they are good things? And why does all this seem so apt coming from a Sun Java site?
As for one bug killing an entire complex system. No that doesn't happen on my system or I'm sure many slashdot readers.
If he really believes what he's spouting, then he really needs to learn how to design systems.
Has he _really_ any idea how complex existing real world systems are? And why they still mostly work? If my web application has a bug, that doesn't kill my webserver, RDBMS, etc. Neither does it kill my microprocessor, caches, RAM, northbridge, southbridge, HDD, vidcard etc. If one custom server goes, my web app can still work without it, albeit it could use more CPU and response isn't as good.
He says: "You don't have errors that are proportionate to the source of the error. And that means you can never have any sense of gradual evolution or approximate systems"
Much software (including Linux) has progressed through evolution (with some leaps here and there).
I sure hope what he's spouting won't encourage all those idiots to reimplement browsers, clients, servers, RDBMs, legacy systems as one huge "distributed enterprise application".
Maybe I disagree because my degree is in Engineering not CS.
But it's like talking about a single blueprint detailing 10 million _different_ moving parts. Sure maybe NASA/JPL can implement those (doubt they would tho), but the rest of us will just have to resort to designs that can be implemented in the "real" world.
If you want something gracefully error-tolerant, soft and fuzzy and able to do pattern recognition, why don't you just get a dog?
Jaron's concepts are vaguely stated but still interesting. If you imagine a computer having a central intelligence that is modeled after human intelligence with a certain amount of pattern recognition and iterative learning behavior, there are some potential immediate applications of this.
A simple example would be the computer's parsing of HTML (or any other grammar/vocabulary-based file format) as compared to a human's parsing of the written word. The human mind has a certain amount of fault-tolerance for ambiguities and grammar-deviations which allows it to make some sense of all but the most mutated input. An example of this would be your own ability to grok most Slashdot posts, however rife with gramer, spelin, and logik errors they may be.
The computer could also potentially do this to less than perfect input - smooth over the "errors" and try to extract as much meaning as possible using its own knowledge of patterns. It could make corrections to input such as transforming a STRUNG tag to STRONG, since this is probably what was intended and is the closest match to existing grammar.
Obviously this is a very simple example, but I think this kind of approach could lead to new ways of solving problems and increasing the overall reliability of computer systems.
Real Lessons:
1) Jarod Lanier is a talented, but vastly overhyped individual. Think of the geekiest person you know. Chances are, that person is better qualified to render a decision than this guy.
2) No one will ever write more than 10M lines of code.. Yeah, ok. After all, nobody will ever need more than 640K either, right? Come on. Every decade, someone comes up with one of these nearsighted and baseless claims. Its a common trap. Just a million lines of code in a single program would have been inconcievable to someone just 10-15 years ago. Nowadays, its common. Every generation thinks theyre the top of the heap, when in reality, history proves them wrong every single time. Its fact. More importantly, the fact that Lanier doesn't notice this pattern sort of underscores point #1.
Cheers,
Bowie J. Poag
Program Evolution: Processes of Software Change.
M.M. Lehman and L.A. Belady.
It's obvious few of you or JL have ever read it(chapter 9).
I agree. Pattern recognition, fuzzy logic, fault tolerance etc are all necessary pre-requisites for artificial intelligence. Currently software is shackled (and vulnerable) by strict adherence to rules.
Its pathetic to see so many bozos here commenting on Lanier's appearance (which is ironic considering the 'uncool' stigma attached to geeks). The man may be a dreadlocked mulatto....so what? Debate his ideas if you got the brains for it.
A single base change in DNA can result in mutations that cause death or spontaneous abortion. As little as a change in a single 'character' can be lethal.
Pentagram replied:
Who modded this up? A single base change in DNA is almost never fatal... True, single base changes can have dramatic effects, but this is rare.
Where did cmason imply that single base changes being fatal was common?
Next time, before attacking someone, try reading what they wrote instead of your interpretation of what they wrote.
Fucktard.
Very good point.
;-)
To convert it to the software-world equivalent - With enough knowledge of the specific hardware platform it will run on, a good programmer can write a 100% bug-free, "perfectly" robust "hello world" program.
(Anyone who thinks "void main(void) {printf("hello world\n");}" counts as a perfectly bug-free program has clearly never coded on anything but well-behaved single-processor PC running a Microsoft OS with a well-behaved compiler).
However, extending your idea, how do you get 100 "hello world" programs to work together to, say, play an MP3?
Yeah, it sounds absurd, but seems like exactly what the parent article suggests. Trained on enough "patterns" of input, even a set of "hello world" programs should manage to learn to work together the play MP3s.
That *might* work if we started writing programs more as trainable functional approximation models (such as neural nets, to use the best currently known version of this). But, as much as it seems nice to have such techniques around to help learn tasks a person can't find a deterministic algorithm for, they *SUCK*, both in training time *and* run time, for anything a human *can* write straightforward code to do. And, on the issue of training... This can present more difficulties than just struggling through a "hard" task, particularly if we want unsupervised training.
I really do believe that, some day, someone will come up with the "killer" software paradigm, that will make everything done up to that point meaningless. But, including this current idea, it hasn't happened yet.
But to end on a more Zen note... Phenotropic development already exists, in the perfected form. When a rock touches the ground, all the atoms involved just intuitively "know" where the balance of forces lies. They don't need to "negotiate", they just act in accord with their true nature.
Where did cmason imply that single base changes being fatal was common?
when cmason said "This guy obviously knows nothing about biology" in response to lanier saying "if you make a small change to a program, it can result in an enormous change in what the program does. If nature worked that way [...] there wouldn't be any evolution or life"
generally lanier was correct and got insulted
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.
But the file makes a pretty decent photon. Plan9
I think the whole way we write and think about software is wrong. ... we will not be writing programs bigger than about 10 million lines of code, no matter how fast our processors become
I manage the development of a product that has over 1m lines of code (excluding comments before anyone asks) today. It deals with a small corner of the processes a business needs to follow. I see no problem in it growing to be over 10m lines at some point in the future.
Systems like SAP etc must be more than 10 times this size if you count all the components, so this is nonsense right now.
I do believe that software will start to share some of the characteristics of a biological organism - if you prod a random piece of DNA you get some random change from blue eyes to spontaneous abortion. if you amend a random piece of code you might not be able to log in or the background colour of a window may (embarrasingly) be buttonface.
Aren't bugs just a limitation of human minds?
No, no, they're not.
Rubbish. Bugs are a failure in communication, at some point in the chain between a requirement of the orginal requirement and the end product.
If the human mind can express the requirement clearly, and an algorithm for the solution, but not produce a solution then he may have a point.
If nature worked that way, the universe would crash all the time.
I read that the majority of conceptions for women over 45 do not make it to term. (no sources I am sure someone can expand) I would call this the universe crashing in a most upsetting manner.
We need to be very careful before call something a success or failure.
In the same way that cities are built on the ashes of older civilisations and they just seem to be getting larger, noone says cities are broken as a concept (now they may not be nice if you live in one but that is different - failure for the individual, success for the city).
could you design a search engine that would encourage people to do more complex searches than they can do on a service like Google today, but still do them easily?
Sit behind your mum or dad and watch them use IE, wince, and think well, yes. I hoped something more than the obvious from a good mind.
fuzzy results aren't good enough for ALMOST EVERYTHING we use computers for. If I want to calculate a number I want that same result EVERY TIME I do the same calculation and not something in the ballpark.
The author describes a paradigm where computers give results that are good enough. For most problem spaces good enough means 'exactly what I want' Most of computing is scientific (for some definition of the word) and will be for a long time to come. It is simply what computers do well, so it is what we use computers for.
'Phenotropic' programming might be great for artificial life/AI or pattern recognition. I wouldn't recoment it for calculating payroll.
-spred
.sig Karma out the wazoo, better to spend points elsewhere if this is above 2 or below 0
[about files] It just happened that UNIX had them, IBM mainframes had them, DOS had them, and then Windows. And then Macintosh came out with them.
That's an interesting order he has there.
Why are we saddled with low-level languages? 10 million lines should almost never be necessary.
....
t : {?,/&:'m@x}/p
Even the highest level language used in industry, Java, is pathetic: test a value, if it is equal to something then skip forward a few line, if it isn't then go to the next line, multiply another value and assign it, increment the first value, skip back a couple of line,
That is horrible! Even your geeks beloved beloved Perl (including the upcoming Perl 6) falls into the same traps. You have to deal with explicit control flow; you have to manually program things as simple as finding all the unique elements in a list or grouping them.
Why is it that everybody is content to use these pieces of crap when not necessary? Developers cling to their beloved C++ writing hundreds of times more code that they need. Of course hitting 10 millions lines if going to be difficult, but why should you never need to write that much. The fastest relational database that I know of is rumored to be written in just a thousands of lines, instead of millions. Why? Because it is written in something that allows abstraction and not of the Object Oriented kind! Think about your tools. Find betters ones that push your limits and the limits of expressiblity. Don't be happy to sit and pound out 2000 lines of Java one day when you could have done it in 4 lines of something else.
ten_rows_of_Pascals_triangle: 10{+':0,x,0}\1
transitive_closure_of_map_at_poin
that most of this code will be in rule-sets, which really don't qualify as part of the program but as a part of the program's data. Of course, as another poster pointed out, today it is pretty obvious that knowledge and rule-based style AI is only good for expert-systems style intelligence, largely due to the limitations of first order logic. Self-organizing agent based systems and neural networks seem to be the next approach to making a more useful, general-purpose AI, but those largely consist of dynamically created entities, and their code size can sometimes be surprisingly small. Of course, there is a limitation to those two, so if I can pull some speculation out of my ass (this seems to be a pretty safe thing to do when talking about AI), the two approaches of knowledge-based and agent-based systems will have to be combined to make something truly useful. Now, as to how (if) that's going to be achieved reliably and usefully is a whole other story.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
The functioning of a multi-celled organism such as a vertebrate has incredibly high fault tolerance and would be a better analogy.
For example, if you stick a pin or needle in your finger, all that happens is you have a moment of pain and lose a drop or few of blood. There is zero impact to your life, health or functional abilities (except in the 0.0001% of cases where a serious infection occurs). The equivalent damage to a software system might be something like changing one bit in a 100-megabyte program. Such a tiny amount of damage can easily bring the whole system crashing down or spitting out gargage information.
Unlike software systems, animals (and plants, for that matter) can have multiple major components of their body damaged by disease or injury, yet not only do they survive, but they can recover well enough that their functional abilities and lifespan aren't damaged. You can lose your spleen, a kidney, or a good chunk of your liver, and eventually enjoy the same quality and quantity of life as those who have undamaged organs.
For mere survival, the tolerance is far higher. People have lost multiple limbs, taken a bullet in the head or abdomen, had a lung collapse, or broken several bones and recovered to live to their eighties and beyond.
It is very difficult to inflict a tiny damage that kills a large organism; the damage would have to be precisely directed at one of its weakest and most vital spots. But it is very easy to essentially destroy a large program by making a small random change.
---------
There is inferior bacteria on the interior of your posterior.
So how many lines of code do people think it takes to run the Web now?
I think the problems with our current model of programming that Jaron is describing can be seen mainly in the idea of Leaky Abstractions. With software abstractions, we try to do exactly what Jarod is talking about; we try to simply make things interface with one another fluidly. What he's pointing out, and what leaky abstractions prove, is that our programming languages just don't work this way. Everything assumes the pieces it interacts with will interact in a specified way. The system depends on every piece to follow it's assumptions and often falls apart completely if one doesn't.
There are questions to be raised about a flexible system like this:
What about misinterpretation? Would software now behave like a human and "missread" another component's piece of information? (as people missread each other's handwriting)
Would "fuzzy" interpretations lead to databases full of occasional false information? Could the same system still operate effectively with these kinds of errors? (a very tricky question)
Could we still make secure systems with this kind of software interaction? Would secure systems still require the strict standards our current systems have? (ie. your password must still be entered with the correct capitalization)
Obviousely, information passing wouldn't work in this model. Think of the party game where you sit in a circle and whisper a message in each other's ears to see how garbled it gets. We would just have to avoid that type of system.
These (and the others I've read) are the kinds of immediate questions that one will make of this concept. I guess Jarod is proposing that these are things that can be worked around conceptually; they're implementation details.
Personally, I think he's brilliant. I think he has stumbled onto what will be the foundation of the future of computing. Here is the big bold statement he is putting on the record for us:
"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."
My question is this: Would any of you openly challenge this statement? If he were to more rigourousely define this bet and enter it here, would any of you put yourselves on record saying it was bunk?
I know that's alot harder than simply not challenging him, but think of the ultimate outcome of his work. Do you truly think computing systems will still be cooperating the way they do now 100 years from now? If the answer is no, but you still don't think he's on to something, then what will change things? Genetically altered super-humans whose brains operate as our computers? The "Mentats" of the Dune novels?
If I had $2000.00 to spare, I'd bet it on his idea.
Feel free to quote me on that 100 years from now.
'He theorizes that two software objects should contact each other "like two objects in nature," instead of through specific modules or predetermined points of contact.'
Odd, I notice that I contact the Universe through a specific module called my skin, which only allows predetermined types of molecules through.....
Besides, all this talk of going 2D is great, until you realize that any remote stuff will be done through a serial interface - a wire.
In the interview Lanier says that on the first version of macintosh, before it was released, they were experimenting with a version that did not use files. Is there anywhere I can find out more information about how this worked?
Of course, if you have worked with ABAP before, then you will know why this is so....
The problem with most computer systems is that they are like a finely tuned watch. Except the watch has a million parts, not 100. And just as a finely tunes machine breaks completely when one part is slightly out of alignment a program croaks if one small thing breaks.
Organic systems are not like that. The results, however are also not exactly precise. Perhaps what Lanier is saying is that we sould move away from the whole extremely brittle finely tuned machiens where all the parts fit exaclty or pretty much not at all to more organic sort of things.
Search google for "Feyerabend Project" for more on this.
One thing mentioned there is that software modules should communicate more with protocol streams than exactly correct rigidly typed structures that break if you cough close to them. In this way thow different pieces of software do not need to be recomiled if something changes on one side.
As an example, a HTTP server does no go south if an extra HTTP header is plugged into its interaction, while a function call would probably go bonkers if you add another parameter in a call to it.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
What drugs is Jaron on, anyway?
The important thing is for our programming languages to not adhere to some gimmic paradigm, but instead the language should be WYSIWYG on a syntactical level. This is obtained by having many of the same properties found in languages such as the various Lambda-calculi:
1. Referential Transparency: equivalent pieces of code can be swapped by simple cut-n-pasting the code
2. Church-Rosser Property: programs aren't just deterministic, a program does the same thing no matter which parts are evaluated first
3. Curry-Howard Isomorphism: statically typed programs have a logical behavior
Note that I am not advocating functional programming, as other programming paradigms can still use these language properties.
Surprisingly, these 3 properties are NOT found in most programming languages. This is why small changes in code can cause things to fall apart.
Without these properties, small changes can have a domino effect and react badly with other far off pieces of code.
For example, without the first property, referential transparency, two pieces of code that do the same thing can't necessarily be interchanged by simple cut-n-paste. With modern languages such as Java, this isn't as much of an issue, but you can still have problems, especially with regards to multiple threads. In languages such as C, however, unless the code is extremely well written, you can't swap out one piece of code for the other. Global variables, goto statements, etc... Referentially transparent languages would always 100% garrentee that equivalent pieces of code could be cut/paste swapped.
Without property 2, programs tend to be extremely nondeterministic! C and C++ are two languages that are extremely nondeterministic. For example, not initializing variables, multiple threads, referencing deleted objects, etc... Java has similar problems, especially with regards to multithreading, garbage collection, etc...
The lack of a logical interpretation (property 3) means you can compile code that just flat out don't make sense in the terms of describing an algorithm. C, C++, and Java allow use of generic pointer variables, so you accidentally pass meaningless things to functions. In C and C++ it is a void*, and in Java it is an Object reference.
It is still possible to keep nondeterministic behavior, concurrency, and mutation in a language with the above 3 properties (relaxing property 3 though). The above 3 properties also don't necessitate a functional paradigm.
Anyway, silly paradigms that sound all nerdy might be fun, but they aren't useful. Instead, we should work to make our programming languages well behaved! Subexpressions in the language should be "what you see is what you get"!
It is a major problem of 'half intelligent' partially autonom systems to get the to meet a specific goal or behaviour.
The man has got many things wrong.
1. The number of lines of source code in an application may well exceeed ten million, albeit the vast majority of that number being part of libraries, the operating system and so forth. Great engineering comes from *simplifying* the problem, not throwing complexity at it (which, IMHO, is where so many bugs come from today.)
2. Oil rigs and planes are *much* simpler things than large software projects. For a start, physical objects generally behave in well understood ways. You tend not to get strange emergent behaviour from piling bricks on top of one another. More to the point, physical objects do not share state (another major source of bugs.)
3. Pattern recognition is actually harder to get right than correctly implementing a protocol. A key problem with PR is working out exactly what it is your system has learned (cf. the case of the military system that was trained to spot tanks, but instead merely learned the difference between night and day.) PR is also currently very poor at dealing with structured input, which I would have thought would be a major showstopper for any realistic application in software development.
4. I'd argue that it's easier to work harder on getting things right in the first place (and let's face it, software engineering is pretty much a joke at this stage of its evolution) rather than taking on yet another approach about which we understand comparatively very little indeed.
5. Stateful computation and (sorry to say this, but) the woefully inadequate abstraction tools available to today's commercial programmers (and no, OO does not cut it, despite the hype and despite the fact you've been using it for years -- if it did work as advertised, code would be much less buggy) are major contributors to unreliable software systems. Oh, and the fact that any monkey can become a programmer these days.
6. The best programmers often stick around academia because that's where the hardest challenges are taken on. Academic programming language designers (who do have bags of experience in the sort of thing commercial programmers get up to every day) have been advocating declarative languages for decades. For years now the compilers and tools for these languages have been industrial strength. Declarative programming *does* require you to change your way of thinking, but the pay off is programs that are an order of magnitude shorter and very, very often run correctly first time.
1. Take an existing technology (fuzzy logic)
2. Redefine it with a cool-sounding name (phenotropic)
3. Profit!
The Natural laws of the Physical Phenomenon of our creation and use of abstractions is what he is trying to nail down.
/. posts for more information.
But it has already been identified and being developed as a general user based automation tool. Useful in many ways, including in teh development and use of an autocoding environment.
See Virtual Interaction Configuration and even some of my journal listed
It's nice to know..... exactly where many seem to be headed. Unfortunate for them that they seem to be, in one way of another, off course, even just a little over a long ways makes a big difference.
Gerry Sussman (one of the authors of the famous 'Wizard' book taught in beginning computer science classes) has been working on biology-inspired programming paradigms over at MIT. The correspondance between the structure of living systems and computing systems was pointed out by John von Neumann quite at the dawn of both fields, and these notions seem to be alive and well today. In this view, the genome is like the assembly code of a program which, when run, is capable of replicating itself, developing from a single cell, maintaining and healing itself. Wouldn't it be great if we could write computer programs that had these same characteristics? It's an inspiring conception of biological systems and an incredible vision for a future for programming.
Jarod is a bit of a galactic gas-bag, having stated publicly that 'nothing good at all will come from biotechnology', but that information technology is 'almost all good' (interview on NBC, as I remember), but in this interview, I think he's on the mark.
My friend! Prepare to contain your joy 'cos mega-porcessor technology is already here - see press release below.
Porcine Technologies
Press Release
April 1, 2002
Porcine Technologies Inc, is pleased to announce, after 14 years of continuous research and development, the first public offering of it's mega-porcessor computing technology.
Mega-porcessors are a completely new approach to computing, directly incorporating the exciting new worlds of genetic engineering and pattern recognition or phenotropic computing.
Professor Clive Bacon, Porcine Technologies Chief Research Officer explains the technology:
Paul Jamon, CEO of Porcine Technologies, in launching the first three models (already dubbed the three little pigs) of this exciting and promising technology, also announced that development was nearing completion of it's second generation of the technology (BIGSOW) and that several large global enterprises were already testing the unique power of this larger body mass porcessor
I remember this guy gave a guest lecture when I was at university. He'd dropped the Virtual Reality schtick and was waxing lyrical about Tele-Immersion. He was also unable to make a very convincing argument about why he was so vehemently opposed to the idea of strong AI.
So, he's just found a new buzzword to blather on about. Yawn.
(If you're familiar with The Fast Show, he is basically Denzil Dexter.)
we must dare to challenge our small-minded notions of "computer", "bit", "byte", and indeed our entire category of "digital".
they are simply crutches that we've been leaning upon for too long.
these pieces of received wisdom had their day, but are now doing more harm than good.
i'm sure jaron has a suitable replacement in mind.
found in his manefesto
...the Great Shame of computer science, which is that we don't seem to be able to write software much better as computers get much faster. Computer software continues to disappoint. How I hated UNIX back in the seventies - that devilish accumulator of data trash, obscurer of function, enemy of the user! If anyone had told me back then that getting back to embarrassingly primitive UNIX would be the great hope and investment obsession of the year 2000, merely because it's name was changed to LINUX and its source code was opened up again, I never would have had the stomach or the heart to continue in computer science.
You know the Microsoft destroys the night, Linux devides the day...
though may it should have been 'pig iron' rather than 'big iron'.
Some drink at the fountain of knowledge. Others just gargle.
After I wrote the parent post, I recalled something douglas adams wrote about. He described a big desk that was actually a computer. You sat at the desk and tried to solve you problem. the computer watched you and after a while figured out what the problem you wanted to solve was. then it solved it. Nearly all the computer power was spent wathcing you and infereing your problem. Not quite the same as what I was saying but a remarkable instance of it.
Some drink at the fountain of knowledge. Others just gargle.
My opinion of Slashdot readers plummeted after reading these comments. The tone and content of the critisims range from childish (look at the funny hair) to stupid name calling (it's just a lot of BS that anyone can make up) to mindless bragging (I work on XXX million lines of code all the time). Very few of the negative comments were well reasoned or based on reference to any solid information. I think you are all scared shitless by the mere suggestion that your programming skills might not be the final word in technology. Jaron may be right or wrong, but he is taking a radical look at how well we do our jobs. Only a self satisfied smug idiot would accept the current state of the art for software development. Personally, I cringe whenever I am called a "Software Engineer." Engineers build reliable system based on well understood principles that are on time and on budget. Software development does none of these things, and we are lying when we call ourselves engineers. I think that the Slashdot readers who mindless flamed this posting are a big part of the problem, and to make matters worse, are happy with the current sad situation.
Thank you for the entirely appropriate and completely new term for a very lightweight (intellectually) and insigificant substance with similar properties the bullshit.
The fact is that computers are, by definition, a generic machine... ergo, software is a method by which a generic machine is made into a more specialised machine while still being a generic machine.
Nature, on the other hand, doesn't build generic machines - it makes machines that are very, very good at certain specific things... if it's a fish, it's very good at extracting oxygen from water and swimming. If nature builds an owl, it's very good at spotting prey and flying. Put either animal in the other animal's environment and you're going to have "crashes" because they aren't suited to those environs.
As a developer, I *KNOW* we aren't doing it right... but we're getting better.
Look out any discipline that's barely 50 years old and I don't think they'll be in much better shape; It took over 5000 years for structural engineering to get to where it is today... but buildings still fall down; that too, can improve.
Comparing software to other forms of engineering is silly... in a few years (decades? centuries?) perhaps... but compare that scale to the one nature uses and even 5000 years is so tiny a speck that it's not even on the map. Comparing software development to nature is complete nonsense.
Is an aeroplane better at flying than a bird? Is a submarine a better fish? Is a car a better horse? Not really, but then, it doesn't really matter because the comparison is invalid.
I think in all of the discussion, too many people are focused on this "10 million lines of code" issue. The heart of what he seemed to be talking about was exactly what you just said - combining systems in an intelligent way. He just wants the interface between systems to be fuzzy instead of rigid.
A very simple example I can think of is imagining a system where you write XSL with references to properties of an object (a javaish wording), and then a physical (you know what I mean) instance of the object itself. These are tied together only by words - the Java code has property "yearlyRecurringCost" and the XSL also has "yearlyRecurringCost". But the interface is rigid - when you change the name of the property to be something like "YRC", then any of the XSL you have must also be changed. Traditionally problems like that have been solved by typechecking, but you can only get so far - like when the property is now mapped to XML and used in another company where the typechecker cannot reach.
Now imagine a system that would just "know" (or be "pretty damn sure") that "YRC" and "yearlyRecurringAmount" were the same. It would function longer and through more changes, without fixing or failure. That is a simple example of the kind of thing I think he's imagining. However, I'm not entirely sure if the kind of bugs such a system brings on (the system "knows" that "recurringAmount" must mean monthly when it really means yearly) are going to be less limiting.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Jaron you are wrong about your focus on bugs. If you read code (or poem) you see bugs or feel them and you see they are good. Bugs are not a constraint for complexity. Our perception is. The surface between you and the computer. This is where protocol adherence fail, your brain simply fuck all these stupid rules. It wants see patterns, beautiful colors, curves, hear sounds, it wants enjoy provocative metaphors. It is bored by coordinates and tags.
Bugs are cliche. Protocol maniacs are sick, don't mind them...
yours Santa Claus
It's like all the debates a long time ago about what the best computer/parrallel computer hardware/software architecture would look like..the answer depends upon what task you want to perform (be it model something, design a game, build a computer system etc). The answer is dictated by what resources (tools, your experience, etc),you have at your disposal and the time frame at hand. Nature can build complex biological systems because they are essentially made from self-reproducing nanomachines (build lots of them cheaply). Like most things, nothing is perfect, it usually gets the job done..if you have all the time and resources, you could build a computer system that uses biology etc as models and simulates most anything and can deal with unexpected inputs etc, but using current echnology, that would be expensive and be sort of like a big smart emulator system..
You could build systems that incorporate the CYC system..(www.cyc.com)..to put a system(s) like CYC into your system so that it could look for faulty conditions etc...I think that CYC is use in the Ask Jeves search engine..of course, fuzzy, neural networks and traditonal AI could be used too..all this stuff (AI, Comp hardware/software languages, complexity theory) has come out of the last 60 years of comp sci research and math and physics and now biology and chem etc will determin how we make future technologies (like nanotech), it's clear that may people have worked on these problems and there is no single quick solution to the program complexity/reliability issue and probably not one person asking these questions or soving them..perhaps there are more than one good answer and that existing languages and protocols are good enough with correct use and mabey some tweaking too...
Christ, what incredible amount of venom in the posts in this subject!
/Lars
I thought the article was pretty interesting. Sure, I thought there were points that could be discussed in the article, but why all this flaming and disgust? Even if you disagreed completely with his ideas, can't you at least appreciate his argument that it's worth thinking about a more revolutionary change in computer science? Isn't this a more interesting topic than the millionth "ooh, Microsoft is eeevil!" post on Slashdot?
He doesn't give any examples. None of the interview is more than subjective waffle.
I am not knocking this man's ideas, its just he's going to need to do more than talk vaguely about a "paradigm shift" to sell his ideas to me!
SURELY NOT!!!!!
Certainly we need more people thinking outside the box, at least being able to see that there is a box and some other things are maybe outside it.
Another example of this kind of thinking to me is Damian's Perl Module Quantum::Superposition which lets you take a swing at a totally new way of formulating algorithms.
When I read Lanier's article I thought (as he noted on his homepage) that 10M is small, but the difficulty of writing good code by professionals is true (Microsoft, NASA,
I've already started getting some new ideas.. and though that $2K seminar in February he's going to be at disappointed me (hallway conversations probably will be most interesting?) I say THANKS to Jaron (and a couple of Slashdot posts..). Catalysts and cell receptors jumbling in my head.. and meanwhile got me thinking positively about how to make my current programming jobs less arduous.
Phenotropic? I think this guy meant "phenotypic," as in "the phenotypic expression of the genotype". And if I think about phenotypes in software, then that would be the actual behavior of the code. And yes, indeed, when I'm working on code (the genotype) I often think about what the executable program (the phenotype) should do in the end. It's time that this guy stops blahing.
I'm wondering if maybe he's occluded due to drugs. Listen, you can't take visions from the prankster shroom or acid elves as gospel.
At least, that's what the DMT elves say.
Show me the code
The REAL idea he is getting at isn't physical lines of code, although this is a good judge, but how complex the programs are, and what we are modelling, how many interfaces, relationships and ideas we express in the code, and how we can reduce the process of managing bugs.
x ception();
The ideas of creating fuzzy relationships (erk, interfaces) between components is fascinating. Although, it seems by definition for one component to be tollerant to another, it must have a preconception of the inputs to expect, therefore it might be like
if (reasonableResponse)
return reasonableResponse;
else if(someNewIdea)
return myFuzzyWarmIdeaOfAReasonableResponse;
else
throw new HeySomethingHappenedDoSomethingAboutItGracefullyE
I do however like people conceptions of the 10 Million limit, and code reuse. After all, most systems in the world is a collection of small systems, reused and repeated. The most complex behaviours and unpredictable systems can be broken down into a handful of simple rules or sequences, which is what programming is, or what we think it is.
Who would want to model one single behaviour in so much code! Lets work at Javaesque ideas of modelling and code reuse, which have really matured recently.
However, the aim isn't to give us the chance to make really big programs of billions of lines, but to give us the chance to model far more complex systems RELIABLY, including all the little connections between the rocks and grounds of our program.
Yes Windows 2000 is a biiiiig application/system, but hands up who would say it is realible? Who wants to trawl through it bug finding? That is why they have to throw away and start again (heck they dont, they just leave the shelled out carcase of the code to bloat the system - and further downt he line programmers will reuse methods which look the same as well tested 2 year old code, but this is 2 year old code that want tested, and will call is Windows 2004, and we will all enjoy the lovely exploits which ensue)
Can you imagine if the code base, or complexity of this beast doubled? And it will, they are trying to squeeze all manner of bits we don't need in there, to sell it as new.
He also mentions how difficult it is for someone to write an operating system. We can imagine what it does, but it is quite an achievement. It seems that here we are talking about not MORE lines of code, but LESS. If 10 M was some cognitive limit (lets just say for example) we would need people to be able to model a complex application quickly and reliably with ideas, huge masses of code. Yes, reusing many components, but think outside the rect here and how can these bits of logic, these processes, interact in an error tollerant way.
He wants people to compete more easily and quickly, new software ideas to bring power to those who have the real ideas. Brain grease over elbow grease.
We all know the power of an interface, or contract. We abstract the idea of an 'application' and it runs inside the 'operating system' and we have a contract of resources and interaction.
But if one element goes fizz, the whole house of cards goes down, especially if we are talking win32.
Now you could argue, whatever happens, if a component goes fizz, for some reason, we NEED the application to understand this, rather than continue, as processing the data further with this inconsistency could be more damaging. (missiles landing in your back yard)
So either we concieve some perfect system for creating programs (arguably impossible since we are only human) or just bring in ideas to MODEL and ABSTRACT the code process through strong contracts, and identify patterns (not the same patterns he talks about) in the code, and give us, as humans, the chance to drag little safety nets around each area, and say, if this part fails, I want it to decide to go here.
I have been developing this way for well over 3 years, it wasn't natural, it was a developed skill, of course, I THINK like this naturally, but to bring it into the code was a process I had to enforce. (please, tell me you know all this already, and show me all your 100% bug proof applications over 300,000 lines of code)
Back to this impossible model - which doesn't allow for errors, a strict rule based language which predefines all acceptable states as it is coded, and can see where errors can occur. These chunks can then be fitted together like Lego (tm), and if they don't fit, they don't fit, if they do, then they work together, and the behaviour is something only we can decide upon, ie through interpretation. Our interpretation would be the failing factor in any system now matter how strict, the legal behaviour of that system in itself might not match what we wanted to model, and is as much of a bug as one that goes fizz
Now Java is getting there, I should say the Java ethos, and best practices and eXtreme Programming, and team based development practices, there are so many built in ideas, and certain powerful tips beknown to developers give us systems which 'cannot' fail. Of course, this is only based upon what we could identify at the time as a failing criteria.
This person has posted an interesting response (even if I don't agree). As an AC, it will probably end up being ignored!!!!
Calling the library meant that what you were building a layer upon something that was already debugged. However, the library routines contained sanity checks of their own, so if you supplied a null rather than a pointer where one was needed, you found out about it quickly.
We have a series of different library tools now. Unfortunately, not all try to check what the caller is doing (it does cost performance to be paranoid). What is good though is it means tht you aren't building pyramids on quicksand. Yes, the RDBMS is a layer, but there is nothing to stop us from creating distinct layers within our own systems - layers that can be tested and debugged independently of the application as a whole.
It has advantages too, because it means that you can come back and reengineer something fundemental at a low cost. You can even change the layer itself.
However, in the end I don't worry about debugging a large program because the compile/link/debug/edit cycle takes too long. I don't mind large systems (one I have recently worked on is over 30 million LOC on the backend alone) - but I prefer the programs and modules to be smaller.
See my journal, I write things there
- Chaos
by Jame Gleik. People have made the construction analogy but lets take the Tacoma Narrows bridge for example. One small oversight and an entire bridge is destroyed by the wind. 3. In a lot of ways, absolute perfection is not only a requirement of some parts* (see above) of a program in order so they will work, it is also a functional requirement. I wouldn't want my tax preparation software using fuzzy pattern recognition to calculate what I owe. In a lot of ways the precision of computers and software is their greatest strength. If a program is written correctly, you can depend on it giving you the right answer ever single time you use it. I don't know if that is true for what he is proposing. All of this smacks of the "drag and drop" programming concept of the late 90s. A couple years ago someone was telling me that we wont need programmers anymore because we will have software that allows anyone to write a program. That has happend on a very superficial level but the real work of computing is still done by expert geeks.... be that as it may, it's not the only dark cloud. Here are three more that, each in its own way, address some of the issues raised by Mr. Lanier:
Cloud 1: Information
Let's go back to the middle of the 20th century, to a very brilliant, first generation of serious hackers that included people like Alan Turing, John von Neumann, and Claude Shannon. Their primary source of coding experience involved coding information that could be sent over a wire. - J. Lanier
Claude Shannon, in his paper A Mathematical Theory of Communication (PDF version) begins with the oft forgotten statement that, and I'm paraphrasing here (badly), of course he doesn't really mean "information" as that would imply a whole host of semantic issues he doesn't need to deal with but, what the heck, it's a nice word.
It's certainly an interesting word, but when it comes to what can be stored and/or transmitted, it's the wrong word. That Shannon used it and no one seems to mind speaks volumes about the "programmer's mindset" in the past 50 years and goes a long way towards explaining why GOFAI (good old fashioned AI) has failed so completely.
Information is a phenomenological experience of the mind's response to stimuli. You may find what you're reading here informative, but that does not mean this arrangement of dark and light pixels on your screen is information or that, when I posted this message, information was transmitted. The illusion of information is very real, so real that it makes it difficult to see that behind it is a mind doing some incredibly complex processing and that without mind, there is no information.
The illusion of information is borne on the wings of assumption. Call this a message or posting or whatever, but it is really a designed encoding of data, its design intended to evoke particular responses and guided by my assumption that you read and can comprehend English (one of many assumptions). We are so adept at language that most of what goes on when we speak and listen (or write and read) goes on below the level of consciousness. It takes effort to see that the illusion of information requires mind and even more effort to see that mind requires society (i.e., that minds are social -- they require the shared conventions and knowledge represented by the society they are immersed in).
Anyone who's written even a simple program has experienced the "absence of mind" in the wonderful world of Information Processing/Technology. Without mind, programs are required to simulate particular mind-like functions in order to simulate "information." We state or assume conventions and knowledge (e.g., protocols) in some subroutine so it can "think" about the "information" passed to it. We spend an inordinate amount of effort and time trying to design and follow conventions in our programs. In the "human interface" areas of our programs we expend even more effort trying to get the "stupid" user to supply information according to the conventions our programs are expecting and to decorate (format) information for human consumption.
To the extent that the knowledge and conventions within a program are complete and consistent, the current "art of programming" works surprisingly well. The larger the program, the more difficult the completeness and consistency becomes and the more dangerous the fallacy that information is storable and transmittable becomes. It becomes too easy for a programmer to assume that "information" produced or consumed by some subroutine they're working on is, and will remain informative. One can easily imagine someone at NASA working on a subroutine that transmits thrust information to a spacecraft. Would they ever imagine that what they have encoded in Pounds will be interpreted by another subroutine in Newtons if they believe their subroutine actually transmits the information? (Not that anything like this would really happen, of course.)
Cloud 2: System Boundaries
We need a system in which errors are more often proportional to the source of the error. - J. Lanier
How do we know what is and isn't part of a system? We look outside and see a car, a tree, a person. The tree has a root system. The car has a brake system and an exhaust system. The person has a cardiovascular system. And yet, the best definition I have for a "system membership function" is: Anything that affects and is a affected by a system is part of that system.
A little thought in that direction will get you to the conclusion that it's pretty much all one system and everything we deal with is a subsystem. We haven't evolved to look at the world this way. In fact, we try not to as such a holistic view is far too complex. We'd be stuck in analysis paralysis before we ever got started. We have a tendency to begin with the smallest version of "system" we can get by with and expand its domain only when it's the only way to accommodate some "outside" fact.
In my experience with programming (and technology, in general), the "source of the error" is frequently outside of the "system" we thought we were dealing with. It's not unusual to find that the destination of the error is outside of the "system" we thought we were dealing with, as well. Programmers are all very aware of the effects of system boundary errors (although most would not recognize them as such). These errors manifest themselves in usually annoying, and sometimes frustrating problems. But the consequences can be far more devastating.
In December of 1996, The Bright Field (a 763-foot freighter loaded with 56,380 long tons of corn) was positioning itself to navigate a turn in the Mississippi River when a primary oil pump failed. Automation software detected the failure and attempted to start a secondary oil pump but it wouldn't start so the automation shut down the engine. When viewed from the perspective of the "engine system," the automation behaved in a perfectly reasonable manner (and had this occurred on the open sea, everyone would congratulate the automation designers for a job well done). But if you jump up a level you see that shutting off the engine makes it impossible to steer or stop the "ship system." Jump up another level and on that day in December you see that you now have an extremely heavy ship drifting straight towards a New Orleans wharf. (The crew was able to finally get the engine started but not in time to stop the ship. It destroyed 200 feet of dock, tore the front off of a hotel and shopping mall and injured 116 people.)
Cloud 3: Complexity
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. - J. Lanier
Note: I assume (and hope) Mr. Lanier meant: "we can deal with their complexity much more effectively than we can with software's."
There is a hint in Mr. Lanier's comment of the belief that complexity is somehow undesirable or problematic. In common usage, complexity seems to share some of the semantic space occupied by complicated. Let complicated handle all things messy, difficult and hard to use. Complexity is about connections (physical, social, ideological, ...) between things and it is the source of power in anything we think productive or capable of fending off entropy.
Having lived near an oil refinery that blew up I have my doubts about our ability to deal with their complexity, and no one needs reminding of what commercial aircraft are capable of. You may be tempted to come to Mr. Lanier's defense here, stating that this isn't exactly the kind of "dealing with" he meant. To which I would reply: yes I know, but that's exactly why complexity seems like such a problem, often times in very surprising ways.
People, it seems, like to forget that: a) complexity is no less productive just because we didn't intend to create it, and b) complexity is not constrained in any way by our good intentions. Programmers are also fond of thinking of their code as something that simplifies things, but new software always increases the complexity of the system. In fact, when it comes to adding complexity, nothing is faster or easier than software (and this is most likely at the root of Mr. Lanier's comment). It's rather interesting to consider how programmers try simplifying something and end up making things more complex... Some guy named Tim tries to simplify the exchange of scientific documents and, voila! out pops amazon.com.
It's worth noting that all or most of the significant "events" in human history have resulted in (or enabled or supported) huge increases in complexity. Language, agriculture, population expansion, civilization, transportation (roads, ships, etc.), writing, the printing press, electronic communication, and so on; they have all increased the connections (usually both in number and frequency) between people. (It's possible that Kurzweil's theory of exponential growth of technology is focused on an effect rather than a cause. It seems more likely to me that complexity is growing exponentially and, for the moment, technology is a parallel effect of that growth.)