PhenotropicProgramming

ThoughtStorms Wiki

JaronLanier's idea for code components which are loosely coupled, and which talk to each other, not through fixed and brittle protocols, but through pattern matching interfaces, which degrade smoothly if the components change. The idea is to allow the building of larger code through making it more robust.

http://java.sun.com/features/2003/01/lanier_qa1.html

discussed on Edge here : http://www.edge.org/3rdculture/lanier03/lanierindex.html

Thoughts

The criticisms (in the Edge resonses) that Lanier is off-track because he's basically advocating parallelism seem to me to be wrong.

To me Lanier is suggesting a continuation of the revolution started by AlanKay when he invented ObjectOrientation, inspired by cellular biology. That we should divide code into semi-autonomous modules.

: in fact, see this : http://c2.com/cgi/wiki?AlanKayOnMessaging

But that could go a lot further. What we need is a more robust, fault tolerant, context-aware, more intuitive and intuiting communication between modules / objects / agents / services, however we describe them.

We've been making some piecemeal improvements ...

LateBound variables who's type doesn't need to be specified by the programmer

Polymorphism, that makes a message's meaning more context dependend

Optional argument passing

Messages sent with bags of named arguments rather than strict order-based.

Event-driven systems rather than single flow of control calling functions.

All of these are loosening up the connection between the cells of our code. But Lanier is also right, it's a shame that we haven't tried to go much further. OO was invented in the late 60s, and no-one seems to have pushed the envelope much since.

For example :

Real pattern matching on messages.

As standard, a robust non-failing of code when messages are misunderstood or wrong

Stochastic firing of messages and returning of values.

Maybe even the idea that a function ends with a single return value has become a bottleneck and we need to think that messages start an aquaintance between modules, whose consequences are a multitude of feedback events, spread through time and code.

A better way to declare higher-level properties and constraints that cut-across or are woven throughout the code. AspectOrientedProgramming is a start, but I'm sure there's a better way of representing this higher-level parameterization of code just around the corner.

Now Lanier is wrong if he thinks the requirement for and possibility of a new programming paradigm imply a failure of the von Neuman model. Phenotypics should be able to sit on top of the von Neuman architecture as happily as object orientation does. But the critics are wrong, if they say that this isn't a question of radically shaking up how we think. Or who if they argue that because we've found these things hard to build using the current software paradigm, they are inevitably hard or doomed to failure.

OO is different from procedural programming. And phenotropic programming could be equally as radical a way of thinking about the organization of code and describing the interactions between modules. This higher level is long over-due.

Final thought, this really needs to be supported at the linguistic level. In the next programming languages. You can't bolt on these ideas as libraries to the current languages. That way you'll just demonstrate how hard and clunky it is to handle these features using the current paradigm.

Also note, it took maybe 25 years from the invention of OO to the beginning of documenting good practice as SoftwarePatterns. We may need an equivalent time to absorb phenotropic programming.

Counter-view

OTOH my theory about building bigger systems is still scepticism about abstraction. (DoesAbstractionScale)

JoeArmstrong has some interesting thoughts on making message passing protocols based on finite state machines in ErLang which might parallel this.

Interesting article on redundancy in programming languages : http://www.artima.com/weblogs/viewpost.jsp?thread=4536

ClojureLanguage's focus on use of maps, checking runtime schemas rather than Static types is in this direction.