Enzyme Language

How about a language based on molecular biology? Possible features:

The basic element wouldn't be an object, it'd be a cycle, a threaded IterativeFunctionSystem.
Operators would work to catalyze, inhibit, cleave or join cycles
Conditionals would work like membranes, limiting possible interactions between cycles
Signals could work like ligands, binding two cycles until they auto-cleave.
Parallelism would be based on metabolic relationships. You don't get enough metabolites, your thread don't get serviced ...
And OrganicThreads, naturally ...

Such a language wouldn't necessarily have to represent such other bio-metaphors as neural nets, genetic algorithms, cellular automata and so on. If those things occur, great. Otherwise, let's see what's out there ... --PeterMerel

Q: Okay, but what would the syntax look like?

A1: See CocoaWorld, LittleSimulatorInCocoa, http://c2.com/~ward/cocoa/

The "cycle" isn't explicitly represented in Cocoa, but many programs exhibit behavior easily described as cycles.

Refutation1: No, sorry, go to the back of the line. Read the link on IFSes and think again. It would be trivial to implement a BarnsleyFern? in Cocoa. It would also be trivial in C. But the fern-ness wouldn't be made explicit by the syntax in the way that, say, an int or a char* is. Question is, what's the language like when IFS cycles are first-order constructs.

A2: One of the views would be very C like. You would rarely chunk down to that detailed a view, just as you rarely chunk down to assembler when working in C. The normal view would be of a 'life cycle'. These would have a graphic representation AND a purely textual version. The cycles show the resources an 'entity' interacts with and the sequence in which it does so. The (textual) syntax for a cycle would represent the sequence of interactions enzyme-substrate (function like) enzyme-enzyme (function modifying a function) enzyme-other (function interacting with a resource, such as memory or CPU time). This view hides detail of interactions, but shows 'regions of influence' well.

Refutation2: Very sorry to be so negative, but you need to think deeper than this. Think about attractors, phase spaces, and emergent behaviors.

A3: Answer a question with a question! What syntax do you need to document the datflows in a program, to make the data pathways explicit? One route to an EnzymeLanguage is take real world C programs and 'fit' this new(?) view structure on as a documentation tool. Find and fix the problems in this context. Once this mode is proven, point out that this presentation is tail-wags-dog, and start turning the process around. I'm not sure that the ideas of EnzymeLanguage are all that new really.

Refutation2: There are no new ideas, just old ideas in new combinations. But if you can point at an exemplar of such notions (not Cocoa ... nor SmallTalk ...) then please do. You might start with something more like FractInt?, though that misses the point as well. You need to start with the ontology of the biological systems, not just these traditional representation games.

Q: What you are suggesting is to layer a view in terms of cycles or flow of data on top of a conventional program. I can see syntax that can make the parallelism explicit in a program. What syntax do I use to express a cycle?

A: Nope, that's not what I'm suggesting. Think about PrologLanguage - the built-in unification makes coding in prolog completely different to conventional coding. The aim here is to take advantage of the features of cell biology, especially the notion of mutual promotion, inhibition, amplification, and other enzymatic games, and see what we can do with that. Begin with understanding, not with syntax - that's the end, not the beginning.

A cute idea but please don't get carried away with this notion. The differences between biological systems and computing systems are more compelling than their similarities. In particular, biological systems are self-organizing; not "written" by some nerd with an enzyme language, genesis be damned. And they are self-powering; there's never a power cord trailing behind. I could go on and on. See http://virtualschool.edu/mon/Bionomics for much more along these lines, or anything about NanoTechnology for the contrarian view. --BradCox

Don't go messing around trying to invent airplanes; birds already do a great job of flying ...

Airplanes are self-organizing like birds?'

Biological systems are not self-powering; they require an external source of energy, which they convert to a usuable form. If you had a computer with a built-in solar energy panel, then it would meet that requirement. Building a "self-powered" computer (to match the above description) would not be a huge obstacle for us.

Um, we call for a language and you give us a solar cell? Deeper ... think deeper ...

One of the interesting things to me about how a cell works is how fast and how much material is bouncing around inside a cell. And that there are standard paths to follow within a cell that are dynamically created and destroyed on the fly. Reactions happen because the activity level is so high surfaces have a chance to bind. It's not planned. It's not organized. By varying the quantity of material you can control the likelyhood of certain reactions. The "state machine" is created by this varying of materials and the production of new materials that continue the cycle. The book EnergyOfLife paints a very vivid picture of how active the inside of cell is.

Cells are highly organized. The crucial diffierence is that they are self-organizing systems, unlike computers which are centrally planned; e.g. designed and written by some nerd.

I've thought seriously about how to "program" systems in this way. It is so very different than how software works today.