Phenotropic Program Design

An answer I made on StackExchange wrt ideas for Phenotropic Programming.

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.

Update : OTOH, I don’t know why I bother, because StackExchange is no fun at all these days. Already downvoted because it didn’t fit their narrow ideal format and someone couldn’t join the dots between what I was saying and what the question was asking. Here’s me spelling it out for them :

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

Of course, I may be wrong in my answer and that’s fine, but I think the main problem here is that I just demanded a slightly more “creative” level of reading from SE, and that’s obviously a down-votable offence. :-/