18

I recently ran across an idea put forth by Jaron Lanier called "phenotropic programming."

The idea is to use 'surface' interfaces instead of single point interfaces in computer programs utilizing statistics to winnow out minor errors that would typically cause a "classical" program to catastrophically crash.

The two-line description is here:

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.'

The slightly longer explanation is here. And the even longer explanation is here.

So, the question, looking past the obvious robot-overlord connotations that people tend to pick out, how would one actually design and write a "phenotropic program?"

adv
  • 347
  • 1
  • 9
  • 1
    No offense but the articles you linked are very vague & naive. Could you be more precise about what you understand by `phenotropic program`?. – Simon Bergot Jan 07 '14 at 16:12
  • Read through the ever longer one. It describes it in gory detail. – adv Jan 07 '14 at 16:16
  • 4
    I think only way to answer this is to define what "phenotropic program" is. In which case the answer becomes opinion-based. So before asking how to write a "phenotropic program", ask what is "phenotropic program". – Euphoric Jan 07 '14 at 16:22
  • What is his definition of a program? Isn't the goal to write less code? – JeffO Jan 07 '14 at 16:23
  • 1
    @Simon: The question is basically asking the very same thing, so I don't know that your request is possible without the OP actually answering the question himself. – Robert Harvey Jan 07 '14 at 16:38
  • @RobertHarvey I thought the OP had a clearer idea about this topic, and was asking about an architecture. – Simon Bergot Jan 07 '14 at 16:43
  • I am not clear on how one would implement it, and only guessing at my concept of how it would work. I am hoping to tap into the collective understanding and intelligence of this community in the hopes that I might be able to implement something like this in future projects. The goal, as I presently understand it, is to make more durable programs that can take fuzzy inputs, as someone else mentioned. The part of this concept that still confuses me is: How can you program without a clear interface, a.k.a. "program off of the wire" – adv Jan 07 '14 at 18:02
  • 1
    Related topic (consider the author of the text): https://www.mail-archive.com/fonc@vpri.org/msg03808.html – Thiago Silva Jan 07 '14 at 18:12

4 Answers4

26

Lanier has invented a 50 cent word in an attempt to cast a net around a specific set of ideas that describe a computational model for creating computer programs having certain identifiable characteristics.

The word means:

A mechanism for component interaction that uses pattern recognition or artificial cognition in place of function invocation or message passing.

The idea comes largely from biology. Your eye interfaces with the world, not via a function like See(byte[] coneData), but through a surface called the retina. It's not a trivial distinction; a computer must scan all of the bytes in coneData one by one, whereas your brain processes all of those inputs simultaneously.

enter image description here

Lanier claims that the latter interface is more fault tolerant, which it is (a single slipped bit in coneData can break the whole system). He claims that it enables pattern matching and a host of other capabilities that are normally difficult for computers, which it does.

The quintessential "phenotropic" mechanism in a computer system would be the Artificial Neural Network (ANN). It takes a "surface" as input, rather than a defined Interface. There are other techniques for achieving some measure of pattern recognition, but the neural network is the one most closely aligned with biology. Making an ANN is easy; getting it to perform the task that you want it to perform reliably is difficult, for a number of reasons:

  1. What do the input and output "surfaces" look like? Are they stable, or do they vary in size over time?
  2. How do you get the network structure right?
  3. How do you train the network?
  4. How do you get adequate performance characteristics?

If you are willing to part with biology, you can dispense with the biological model (which attempts to simulate the operation of actual biological neurons) and build a network that is more closely allied with the actual "neurons" of a digital computer system (logic gates). These networks are called Adaptive Logic Networks (ALN). The way they work is by creating a series of linear functions that approximate a curve. The process looks something like this:

enter image description here

... where the X axis represents some input to the ALN, and the Y axis represents some output. Now imagine the number of linear functions expanding as needed to improve the accuracy, and imagine that process occurring across n arbitrary dimensions, implemented entirely with AND and OR logic gates, and you have some sense of what an ALN looks like.

ALNs have certain, very interesting characteristics:

  1. They are fairly easily trainable,
  2. They are very predictable, i.e. slight changes in input do not produce wild swings in output,
  3. They are lightning fast, because they are built in the shape of a logic tree, and operate much like a binary search.
  4. Their internal architecture evolves naturally as a result of the training set

So a phenotropic program would look something like this; it would have a "surface" for input, a predictable architecture and behavior, and it would be tolerant of noisy inputs.

Further Reading
An Introduction to Adaptive Logic Networks With an Application to Audit Risk Assessment
"Object Oriented" vs "Message Oriented," by Alan Kay

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • " it would have fuzzy inputs and outputs, but a predictable architecture and behavior" Woudln't that just make normal program that uses soft computing to process the data? The articles sound like something more profound. – Euphoric Jan 07 '14 at 17:57
  • It would have a "surface" for input, not an Interface in the usual sense (sorry about the ninja edit). The fault tolerance arises from the predictable (in the logical sense) architecture. ALN's are "provable," in other words. – Robert Harvey Jan 07 '14 at 17:58
  • I see one simple problem. In the articles, they talk about designing the programs. But NN are about learning. To me that seems like a big difference. – Euphoric Jan 07 '14 at 18:04
  • The articles don't seem to offer a solution to the design problem. – Robert Harvey Jan 07 '14 at 18:04
  • I am all for departing from biology. I primarily am interested in creating more durable/scalable programs. I am going to wait a bit on marking your answer as correct, to see if anyone else can put it more clearly and/or completely. – adv Jan 07 '14 at 18:07
  • @adv: I didn't put this in my answer, but note that Lanier deals primarily in the domains of virtual reality and artistry. The computing problems in those domains are quite different from the more mundane problems software engineers routinely deal with. – Robert Harvey Jan 07 '14 at 18:10
  • @RobHarvey: Yea, that is the motivation behind this question: A practical way to take this from the realm of VR into the broader information science community. I imagine this will eventually end up on StackOverflow as more usable implementations appear (or as I come up with something that works). – adv Jan 07 '14 at 18:13
  • 1
    Correct me if I'm wrong, but a "surface" input sounds like a collection - of independent (or mostly independent) components. In the eye example, it might have looked like this `See(List cones)` (where each `Cone` is independent from each other), yes? – FrustratedWithFormsDesigner Jan 07 '14 at 18:24
  • 1
    @Frustrated You can obviously simulate a surface with a byte array, but go back to Lanier's definition, which replaces message passing and function invocation with cognition and pattern recognition. It ties in with the scalability problem described [here](https://www.mail-archive.com/fonc@vpri.org/msg03808.html). Fault tolerance is also part of the equation. Think "smarter Interfaces." – Robert Harvey Jan 07 '14 at 18:36
  • 3
    Re:"more fault tolerant". Has Lanier ever seen optical illusions? Has he ever looked into the psychology of the brain. The brain will ALWAYS attempt to make sense out of what its inputs are telling it, NO MATTER HOW WRONG THOSE CONCLUSIONS ARE. The way the brain works is extremely faulty. Thus, as long as it doesn't matter if the program malfunctions quite frequently, just like a typical human, then I suppose the model being referred to is fine. However, most of the time people expect computers to be correct. It will be hard to sell a computer driven car that avoids accidents most of the time. – Dunk Jan 07 '14 at 19:08
  • 2
    @Dunk: ... but it is still legal to build and sell cars for human drivers which manage to avoid accidents most of the time. – Doc Brown Jan 07 '14 at 19:17
  • It almost seems like the design problem is actually in the definition of "fault" than in the actual design of a fault-tolerant system. – adv Jan 07 '14 at 19:17
  • 1
    @DocBrown - it's still legal to have human driven cars that fail some times because we know who is responsible for damages. Computer driven/aided cars are going to create some interesting problems for the insurance industry. – JeffO Jan 07 '14 at 20:36
  • @Doc:LOL...yes, proves my point, human brains are very faulty. So would you be willing to sit in a car and leave it up to a computer that is mimicking a human brain or one with well defined REPEATABLE and exhaustively tested rules instead? I was just pointing out that mimicking the human brain is probably not where we want AI to go; particularly when mistakes are costly. However, if the end goal is to mimick the human brain then this sounds like an interesting area of research. – Dunk Jan 07 '14 at 21:13
  • @Dunk: thanks, you understood that my comment was intentionally meant funny with probably a grain of truth. Nevertheless, a system mimicking a human-brain, including the instinct of self-preservation, may show up to be better suited for such tasks than any other kind of system humans can build in a reasonable amount of time - who knows? – Doc Brown Jan 07 '14 at 21:25
  • 2
    @Dunk the point is not the presence of faults -- otherwise we would go the classical math route to prove everything. The point is 1: the scope of the failure impact (universe does not crash if I mistake a rabbit for a gorilla -- in fact, I still function as a human being after that, so does my brain, and so son), 2: the room physical/biological entities have to recover, provide feedback and probe alternatives that "keeps things going -- even in an unoptimal way"; and 3: the idea that those characteristics are compelling for us to want them in our artificial systems – Thiago Silva Jan 07 '14 at 21:30
1

I think we are at the very beginning of one of the steps it will take to get there and that is gathering lots of data in formats that can be analyzed. The Internet, Google searches, Fitbit (Every step you take, every move you make, I'll be watching you.), FourSquare, a smart phone geo location, Facebook posts and SO question data are all being gathered. We're no where near the amount of sensory data the average human is compiling over a life time, but we're getting close.

Start categorizing millions of pictures of birds and getting feedback from people telling you that's not a bird and you can start to create an algorithm. From there a fuzzier impression (I would call it a model, but that's too exact for what we're trying to code.) can be created. 

class Birdish

How does a pet dog know so much about the owner? Because it watches her a lot. The dog has listened to cars pulling into the driveway and correlating that with the owner opening the front door that it appears as of the dog can recognize a car by its sound. We could do this too, but we see no reason to attend to this. And that's what's wrong with current software, it doesn't pay attention to what the user is doing. It just waits for the user to do what IT expects the user to do.

Something as simple as setting an alarm clock could be done by a little observation/analysis of my current habits. We gave up on setting VCR timers before the technology was replaced by digital. And would that have happened as fast if we could have interfaced the TV Guide with the VCR? I've watched the same TV show 4 weeks in a row at the same time, but the 5th one I didn't even turn the TV on. Obviously I want it recorded. Can't you tell I'm staying late at work writing this post and with my typical commute won't make it home in time? You've got the data, do the math.

Gather more and more data and then you can come up with better ways to analyze, recognize and covert it. We're going beyond what can be input only from a keyboard with our phone cameras and soon eye glass cameras. It's just the beginning.

JeffO
  • 36,816
  • 2
  • 57
  • 124
1

Here is a slide set for defining a Probabilistic Programming Language in Scala.

It is the first decent implementation example for some of the core components to the system that Jaron Lanier proposes.

New Alexandria
  • 899
  • 9
  • 20
-1

A thought I had recently :

If you used high-level ideas like Haskell's Maybe Monad to wrap remote-procedure calls to other systems. You send a request to the server. But nothing comes back (server is broken). Or a Promise comes back (server is busy) and your programs continue working with those None or Promised values. That's kind of like the fault tolerance Lanier is looking for.

Maybe there are ways of encapsulating other eventualities. For example remote calls which come back with an approximation which is increasingly refined over time by some kind of background negotiation. ie. what comes back is something like a Promise but not just "keep holding on and working with this and a proper value will turn up shortly" but "keep holding on and working with this and a better approximation will turn up shortly". (And again, and again). This would be able to hide a lot of faults from the programmer, just as networking protocols hide a lot low level networking failure from the programmer.

interstar
  • 1,449
  • 10
  • 15
  • how does this answer the question asked? – gnat Jan 08 '14 at 06:36
  • If I understand correctly, Phenotropic Programming is a way to program large (often multi-computer), robust systems. The problem is, all the biological metaphors make it vague and difficult to translate into practical programming terms. Here I'm suggesting that certain programming constructs that aren't vague (ie. Monads, Promises etc.) might be a way to make some of those ideas of Lanier's concrete and practically progammable.) – interstar Jan 08 '14 at 14:53