Interview with Jaron Lanier on "Phenotropic" Development 264
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.'"
Full of it. (Score:5, Insightful)
<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.
10 million lines of bullpucky (Score:5, Insightful)
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 ->
Big Programs (Score:5, Insightful)
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*
Evolution and Core Dump (Score:4, Insightful)
Re:10 million lines (Score:4, Insightful)
Now, the extent to which the pieces that you're building are called "programs," or whether the whole system is called "a program" is questionable.
I mean, I've worked on programs of 10 million bytes, and they've seemed to work okay. It would surprise me if 10 million lines is out of my reach using the methods that I'm familiar with.
-Chuck
Unfortunately... (Score:2, Insightful)
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.
and another thing (Score:4, Insightful)
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.
My favorite quotes (Score:2, Insightful)
"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.
Re:Full of it. (Score:4, Insightful)
This means that natures has got an excellent error catching and correction system, rather than letting buggy code run and produce flawed result it catches the worst cases and prevent them from running (spontaneous abortion) while code with less bugs (say, a congenital disease) has less chance to run (early death, lesser sexual attractiveness to mates...).
It is only with the advent of modern society and modern medecine that the evolutionary pressure has dropped enough to make it less relevant to humans. Maybe in the future and with genetic engineering we will be able to correct congenital diseases in the womb.
Even beyond DNA I am convinced that nature has a good recovery system and that if humans were to disappear tomorrow most of the damages it did to Earth would eventually be healed (but how long before we reach the no return point?).
Now if software could have similar damage control mechanism and if it could still function while invalidating the buggy code, that would be something.
Did he actually say anything? (Score:1, Insightful)
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.
Jaron, lose the dreadlocks and get a job. (Score:2, Insightful)
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..."
Just plain silly... (Score:2, Insightful)
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.
Re:"Robust" versus "goal-oriented" (Score:2, Insightful)
I don't want my computer to be fuzzy and robust. I want it to be precise and brittle. I don't want computers to become "life forms". The whole point of the computer is to solve problems, not to be a little organism that "mostly works". Life forms already exist.
That's what I hear all these "visionaries" talking about: they want to make computers operate like the human mind, but they miss the point that we ALREADY HAVE the human mind! We know how it can solve amazing problems quickly, but can also fail miserably. Why do we focus on this, and not on making computers simpler and more effective tools!
It's good to always question the design of our computers. The stored program concept, files, all that stuff is arbitrary. But let's not miss the point that computers are tools, assistance, calculators, etc... they aren't brains and shouldn't be.
not that bad... (Score:4, Insightful)
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.
Re:10 million lines (Score:5, Insightful)
You're modded as funny, but what you said is insightful. The whole point of moving to ever higher levels of abstraction - from ASM to C to C++ (or CXX as we called it on VMS) to Java to <whatever comes next> is that you can do more work with fewer lines of code. The fact that programs aren't getting any longer is utterly irrelevant to any experienced software engineer.
I don't think programs will get longer, since why would anyone adopt a language that makes their job harder? I bitch about Java's shortcoming's constantly, but given the choice between Xt and Swing, I know where my bread's buttered. Or sockets programming in C versus the java.net classes. I'll even take JDBC over old-skool CTLib.
We have plenty of apps these days that in total are well over 10M lines, but you never have to worry about that because they're layered on top of each other. Someone else worries about the code of the OS, the code of the RDBMS engine, the code of GUI toolkit and so on.
In short, pay close attention when someone from Sun tries to tell you anything about software development - he's got some hardware to sell you, and you'll need it if you follow his advice!
Re:10 million lines (Score:4, Insightful)
There are other very large systems out there. LOC never factors in expressivness though. I know of multimillion line 370 systems that were done in 370. I believe that they could be much much shorter if they were done in PLx or Cobol or Java or something else.
Re:Evolution and Core Dump (Score:3, Insightful)
However, even though I think Lanier's observations are valid, they're not particularly groundbreaking. His "wire-bound" vs. "interface" argument is basically a minor revision of the old procedural vs. OO debate. The problems with coding in terms of objects and their interactions continues to be the same: It's never going to be the most efficient(in terms of information content) possible description of a problem, and it's hard work to write extra code for a level of robustness in the future, when most developers are paid for performance in the present. I strongly believe that the roadblocks in development of more robust software are not technical, but are mostly economic.
Programming evolution (Score:3, Insightful)
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.
Re:This is an interesting concept... (Score:5, Insightful)
or is it? how does 'nature' do it. well the answer in nature is that everything is done in parallel at the finest level of detail. when a rock sits on a surface every point on the rock is using its f=MA plus some electomagentics to interact with the surface. each point is not supervised, but the whole process is a parallel computation.
so although his ideas are of no use to a conventional system, maybe they will be of use 100 years from now when we have millions of parallel processors cheaply available (maybe not silicon). So one cant say, this is just stupid on that basis.
indeed the opposite is true. if we are ever going to have mega-porcessor interaction these interactions are going to have to be self-negotiating. It is quite likely that the requirements for self negoitation will far out strip trying to implement doing something the most efficeint way possible as a coded algorithm would. spending 99% of your effort on pattern recognition on inputs and 1% of your processor capability fuulfilling the requested calacultion may make total sense in a mega scale processing environement. it might run 100x slower than straight code would but it will actually work in a mega scale system.
The next step is how to make the processor have a history so that it can actually recognize what to do. That's where the idea of recognizing protocols comes in. At first the system can be trained on specific protocols, which can then be generalized byt theprocessor. superviser learning versus unsupervised.
Cellular systems in multi-cellular organism mostly function analogously. They spend 99% of their effort just staying alive. hugeamounts of energy are expended trying to interpret patterns on their receptors. some energy is spent reponding to those patterns. Signals are sent to other cells (chemically) but the signals dont tell the cell what to do exactly. Instead they just trigger pattern recognition on the receptors.
thus it is not absurd to propose that 'functions' spend enormous effort on pattern recogntion before giving some simple processing result. But for this to make sense youhave to contextualize it in a mega processor environement.
Reasonable especially for interfaces (Score:2, Insightful)
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!
Re:This is an interesting concept... (Score:5, Insightful)
But if his theory is, in fact, what you are describing... Why would we ever do it on the program level? As a programmer, it's actually easier to debug an application if you know exactly how each function is going to treat your arguments. Let's try to think it back to today's technology for a second:
And in turn our calling function will have to sit and think about the return and what it probably is, etc, etc. What benefit can be gotten from programming like this? Yes, it means we could randomly fire something into a function that wasn't intended for it... for example (in Java): SomeUnknownObject.toString() and instead of getting "Object$$1234FD" we get a true string representation of whatever it is... but we programmed it in the first place! We programmed it, so we know precisely what the object is supposed to be, and precisely how to display it. Why have a computer guess at it when we KNOW?
"Ah", i see you saying, "but won't it cut down on LOC if a user gives unknown input and the app can figure it out?" True indeed, but then why doesn't he talk about making these abstractions at the GUI-level? It is far, far more practical to keep the fuzzy logic on the first layer - the input layer. And in fact this is already done to some extent. Love him or hate him, Mr PaperClip Guy pops up and guesses when you're writing a letter and tries to help. Love it or hate it, most every text widget in Windows has an auto-complete or auto-spell-fix function. Hell, even zsh and i believe bash do it. This is where fuzzy logic is useful - making sense of input that is either not what you expected or something you could "lend a hand" with. But in the core API? In the libraries, in the kernel, in the opcodes of the CPU? I don't think so. It's in those places where 100% reliability/predictability are vital, otherwise it defeats the point of using a computer in the first place. You don't want your enterprise DB suddenly "losing a few zeros" because your server farm "thought it made more sense that way".
Re:10 million lines (Score:5, Insightful)
I think you just proved how greater than 10 million lines of code has already happened.
How many lines of code is a 10 million line C program in assembly? 50 million? How many lines of code can a 10 line 4GL statement amount to in C or assembly?
What I think we really need to advance is another way to express logic in a computer system. New languages seem to be getting more focus these days with the popularity of open source, and I think that's a great step in the right direction since more people will get to try out new ideas.
Vague, But Interesting (Score:2, Insightful)
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.
Re:10 million lines (Score:3, Insightful)
If people are going to build something like that without being able to understand it, they might as well not - there are 6 billion existing humanoids already. Why rewrite existing code? Why reinvent the wheel?
Without understanding, those AI folk might as well give up and switch from CS to GM and breeding animals.
Which is what some of them are already doing albeit virtually.
You're forgetting (Score:2, Insightful)
DNA is not such a good analogy (Score:4, Insightful)
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.
Keeping the leaks contained (Score:2, Insightful)
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 [longbets.org], 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.
Re:Full of it. (Score:3, Insightful)
However, I don't see how this insight will lead to a better way of programming. Unless, maybe through sophisticated evolutionary / genetic programming techniques. I see many problems with rational design of stable complex systems like life or 10 million+ lines of code. Sorry Dave, you know I can't do that.
Scared, Stupid and Petty Slashdot Readers (Score:1, Insightful)
Re:and another thing (Score:3, Insightful)
On the specific case of files, one thing he may be discounting, however, is that we ended up with disk files by choice. I'm not sure what the criteria were for making the decision, but other ways of arranging data on a magnetic disk (and tape) were used in the old days, and somehow, files and file systems ended up ruling the day. It may just be a waste of time to try the old ideas again. I mean, you wouldn't build a square wheel just because you think that we may have settled too quickly on round ones...
Anyway, this thread is dead, so I'm probably wasting my keystrokes.
MM
--