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?"

  • 1
    No offense but the articles you linked are very vague & naive. Could you be more precise about what you understand by phenotropic program?. Commented Jan 7, 2014 at 16:12
  • Read through the ever longer one. It describes it in gory detail.
    – adv
    Commented Jan 7, 2014 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
    Commented Jan 7, 2014 at 16:22
  • 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. Commented Jan 7, 2014 at 16:38
  • 1
    Related topic (consider the author of the text): mail-archive.com/[email protected]/msg03808.html Commented Jan 7, 2014 at 18:12

4 Answers 4


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

  • 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<Cone> cones) (where each Cone is independent from each other), yes? Commented Jan 7, 2014 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. Fault tolerance is also part of the equation. Think "smarter Interfaces." Commented Jan 7, 2014 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
    Commented Jan 7, 2014 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
    Commented Jan 7, 2014 at 19:17
  • 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 Commented Jan 7, 2014 at 21:30

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.


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.

  • This looks very nice. Perhaps I will take a stab at designing a library for Java that does similarly.
    – adv
    Commented Oct 15, 2015 at 15:13
  • @adv how would we find it, if you do? Commented Oct 15, 2015 at 19:32
  • 1
    I'll post a link to a github repo when I do get around to creating it.
    – adv
    Commented Oct 17, 2015 at 6:33

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.

  • how does this answer the question asked?
    – gnat
    Commented Jan 8, 2014 at 6: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
    Commented Jan 8, 2014 at 14:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.