CellularProgramming

LionKimbro tells part of AlanKay’s vision. The vision is rooted in the concept of the biological cell. LionKimbro doesn’t understand AlanKay; Rather, he speaks to his interpretation of AlanKay, interpretations rooted in thought, conversation, and experiment.

Summary

The vision can be summarized in the metaphor of the cell. 1

This is a good starting point for my telling, of what may, or may not be, a part of

Each Cell Contains the Whole Code

In conventional modern ObjectOrientedProgramming, we have a great diversity of classes.

A small program might have 5 classes, a medium sized program may have 100-200 classes, a large program may have 1,000s or 100,000s of classes.

On the contrary, by cellular programming, a program has once class.

Just one.

We could call it “Object,” but we’ll call it “Cell,” to avoid confusion.

For anything you want done, you just program it into Cell.

Only Part of the Cell is Active

To make “something,” you take a bunch of cells, and you say, “Okay, you are the line leader, and all of you are the followers,” to take a common “manager-managed” situation.

Or you poke flags in the cell, to turn on or off particular variations in behavior.

Or the cell looks to its neighbors, to see how it should interact.

“But that’s crazy!”

Why?

“Won’t it take up too much memory?”

First, understand that Cell is not written according to traditional OOP (or even UNIX) wisdom.

In traditional OOP wisdom, the class is made to “do one thing, do it well.” There are a lot of smarts written into this Cell class.

Which enables us to answer the question: (Two,) the cell is written to not allocate memory for whatever parts are unused.

“But… How can you fit all that in there…”

You’d be surprised, just how much you can fold into there..!

You’d be surprised, just how reusable these cells are!

Example of a Wiki

Let’s briefly envision cellular programming, with a concrete example: A wiki!

The central substance of a wiki is, … a page! (Duh.. ;) )

So, now, everything is a page. Instead of calling it “Cell,” we’ll call it “Page,” for our program here.

Put as much as you reasonably can into pages. (How far would Alan Kay like us to take this? A bit on this towards the end of the post!)

“Reasonable? But this is lunacy!

How come?

“Well, look… For example, I can see how you could put an HTTP POST body into a page, or perhaps the full text, but… Isn’t that kind of hard to work with?”

What do you mean?

“I mean, – I like to work with the POSTed form as key-value pairs, rather than parsing the whole text every time I want to refer to it.”

Ah, quite right.

The answer to this, is, we extend the model of the page.

So, in this case, we need to add a dictionary 2 to the Page class.

So, perhaps Page now looks like:

So when the cgi script gets stdin, it parses the form values (and perhaps other details) into that Dictionary.

There you go.

“But wiki pages don’t need that!”

Ok, so just don’t use that part, on the wiki pages.

It’s worth noting, though, that it might be useful to let users attach arbitrary key-value pairs to wiki pages.

“Hm, … OK, … I think I can start to see it. What about versions, though? Wiki pages have multiple versions.”

Ah, quite right.

We need to extend our Page, it seems.

Maybe this will work?

So, when you are trying to resolve a page “Foo,” you look for the first page titled “Foo,” and then you find the “Future” id, (if it’s set,) and get that page. Then keep following up further to the next Future card, until you get all the way up to the present.

Index all the pages by id, and you have a linear time op. Work the code a little bit more, and you can easily have it in O(1) time, after you’ve found a card by title.

So now we have “Future” and “Past,” and so we have the versions of the wiki page.

But look!

Not only did we get Future and Past for wiki pages, but we also got it for HTML templates, and configuration data..!

See some other benefits, here? When you write the code to load/save pages, you are simultaneously, automatically, writing the code to load/save everything. Wiki pages, configuration data, page templates, … It’s ALL the same. Anything you code for one, you code for everything.

Note that, if we want to log our GET requests, we could just not delete the GET request pages. Voila: They’re stored! Isn’t it amazing?!

Contemplate This

Think about this for a while.

Take a program you’re working on, or some computer medium, or anything. Ask yourself, “If I had to write 90% of my functionality using a single class, how would I do it?

Play around with it. Look for patterns of recursiveness – can you embed cells within cells, to make it do what you want to do? Can you connect cells in a way, to make it do what you want it to do?

For example:

I think I have an idea about how you could do all of these in the model; It is fairly clear to me that all of this can work, and that it’d be very valuable after it was.

In my experiments with programming cellular systems, I’ve been amazed at the interactions that I’ve encountered.

I realized that the ability for my cells to perform name lookups in a tree-like fashion could have also been used in a work project’s hierarchical caching system, could have also been used to perform shadow binding in an interpreter.

I was surprised to see that the proximity constraints in a graphics environment (“make sure that this word and that word are within 10 pixels of one another”) could instantly be visualized, merely by flipping on the “draw as a line” capability. Since everything that has coordinates is a cell, it can be immediately visualized, in a variety of ways, as well as named (because all cells can have names,) serialized (because all cells can be saved and loaded,) and so on. And then I realized, “wait, if I make the icon drawing code stretchable,…” …then I could even make icons have non-fixed size, and stretch, trivially, by just making their size flexible, like the constraint itself.

In a conventional OOP system, the constraint would be it’s own thing. We would be trying to make it do only the things that it’s supposed to do. It would require it’s own chance to touch the serialization stream. It would not be visualizable, unless we wrote special functionality for it, on how it should visualize itself. It’s ability to collapse or expand would be for it alone; it could conceivably be very tricky to figure out how to merge this behavior with other classes; Depending on how we did it, it could even lead to impossible circular dependencies in the class hierarchy.

Going Further In: Self-Hosting

You can go further in.

You can start to take the components of the system, and make them into actual parts of the system.

I call this “folding” or “self-hosting.”

For example, I found myself modeling the various attributes of my cells (“cards,” I called them, in this particular instantiation) in a table. They were pretty smart, after all. So, “BOD” was for Body. In error messages, it was called “Body,” and it had type “STR”, for String. “URL” was for a URL, and “TTL” was a Title. “CAT” for a category of a card. (This is for idea tracking, and SocialBookmarking.) All of these were STR (strings.)

I realized that I could model these attributes of cards within the system itself.

The advantage of doing that, is that I could partly extend the system, by just adding cards..!

If I figured out how to put code into the cards, (requiring a deeper understanding of Python’s eval function, on my part,) then I could put even more of the system, into the system itself.

Then you get into bootstrapping, gestation, but it’s a very interesting territory.

I believe I understand AlanKay to be talking about these concepts, what little I’ve read of him. (He speaks his own language, very much separate, outside of, contemporary programming, so I have to say: My understanding is probably very much a poetic understanding..! I need to find some books or papers written by him; All I can find are strange passionate lectures in videos, NSF grant papers, e-mail conversations, … But nowhere do I find his ideas spelled out very clearly.)

How Far?!

You might think, “Well, this is neat, but to take this really far, you’d take it to the Operating System level!”

After all, these cells can easily start to resemble files in the traditional filesystem..! Look, we’ve got a date, versioning info, contents, file metadata, and so on… …no?

We start thinking “prototype based,” and objects become “unique,” and oriented by the organ that they are part of, and…

But I think Alan Kay has something deeper in mind.

I’m thinking: He wants to figure out primitive objects.

And then (I think) he wants to code for them in hardware.

He said, (paraphrasing,) “The entire 1970’s Internet can be fit onto a modern chip. Why don’t we design our hardware like that? The 1970’s Internet was really amazing!”

And then he starts to talk about how chip design has closely locked with programming language design…

The secret of PARC’s success was to design the best virtual machine we could and then to build hardware that optimized that. We’ve got that concept backwards today.Phil Windley: Alan Kay: Is Computer Science an Oxymoron?

Things I Don't Understand

AlanKay puts a lot of focus on message passing, above and beyond objects themselves.

I think I can dig this message, because I have been interested in Actor based systems since I saw the movie Tron (when I was, like, 7,) and what I’ve called “Bus Architecture” systems, since around 18.

Actors is the idea that objects are all running concurrently, massively parallel. I learned the term after telling a prof my ideas, and that “I wanted to program like in Tron: Each part of a program doing it’s own thing, and interacting with other parts.” That’s the vision. He told me, “Oh. You want Actors.

Bus Architecture is the idea that you have tiny tiny components (or so I thought; I’ve been re-evaluating this lately…) who are all engaged in fantastic communication with each other.

A state machine, for example, is a single component. It’s talking on an open bus. Everything is “shouting” and listening to the conversation taking place on the local bus. A component gets a message, processes it, and maybe shouts something to a conversation, maybe not. Messages are queued, staged, relayed, agenda’d, all sorts of things. Tons of messages. You don’t so much as link pieces of code together (think: issuing function calls, passing pointers to other objects,) as you rather just “shout” out into spaces, and hear things and respond to them. The advantage here is that your systems are very weakly coupled, and so you can very easily get genuine reuse. If the FSM worked in one machine, there’s very little reason why it shouldn’t work, without any altercation, in another machine. If you need a transducer to translate from one environment to another, that’s fine, (just put it between the FSM and the bus,) – but you still don’t need to alter the original component, at all.

What I haven’t figured out yet is how AlanKay’s vision and the bus architecture work side-by-side. The reason I say this is because, in each bus architecture I’ve worked on, messages were dramatically different than the objects that issued and listened to them. I would be very interested in seeing how the message passing system works with Alan Kay’s more cellular system. Are messages indeed “different things?” How does he do it?

One thing I want to try, is making use of cells (super-capable) instead of components (do-one-thing-only-do-it-well) the next time I work on a bus architecture. I think I can see how to do it, … Make the bus (message relay point) into a basic component of each and every cell, and perhaps make FSM parts (just arbitrarily chosen) into an internal actor network that receives messages from the FSM-as-cell, … Hm… Something to try.

But regardless: I feel I have correctly intuited the cellular / object part of his ideas, but I’m not sure I understand his message ideas, unless he’s referring to the bus-architecture programming vision.

We can note in passing that one of the biggest problems in the development of object-oriented SW architectures, particularly in the last 25 years, has been an enormous over-focus on objects and an under-focus on messaging (most so-called object-oriented languages don’t really use the looser coupling of messaging, but instead use the much tighter “gear meshing” of procedure calls – this hurts scalability and interoperability).Alan Kay, Steps Toward The Reinvention of Programming

He may well be.

See Also

ArticleMode?

Discussion

Very interesting idea, Lion, thanks for bringing it to our attention. I’m not enough of a programmer to know its full implications (and what the downsides would be, whether it’s been done before, etc); perhaps it should be posted to the PortlandPatternRespository? too? One downside I can think of is the difficulties of communication – what if, as you say, one company provides a program that used the “previous/next” attributes one way, and then another company provides a different program that uses the “future/past” attributes for that? I expect that it would be harder than desired to have these objects communicate with each other. In other words, as long as you are using an object’s capabilities in the standard, documented way, it will help, but once you start augmenting it with new capabilities that build on its previous capabilities in a clever way, there may be trouble if someone else then overrides the implementation of the previous capabilities.

I have a feeling that this might be useful for CommunityProgrammableWiki. After reading the Kay et al grant proposal that you posted on SuperObject, I think that stuff might be useful too. I wonder what RecentChangesCamp:KennethTyler? would have to say.

I wonder if CellularProgramming is stuff like JavaBeans, etc, taken to an asymptote; where you keep adding standard meta-capabilities to your code until everything literally has every capability.

I got attracted by the title, but I must admit it’s not the Wikipedia:CellularAutomaton programming I hoped for. Instead, you seem to be describing the implementation of a generic Object not very different from what Python’s objects are – only on a higher level of design than programming language primitives. Well, if it works well on one level, why not try it on a higher one? By the way, using some ideas from the cellular automata programming in the distributed wiki might be possible – I once had a project involving writing a distributed load balancing cellular automaton :)

I could see situations where you’d want Cell’s to be “neighbor-aware.”

Here’s a great "anti-objects" paper, describing the utility of such techniques.

Well, I have an idea about how to make it related to Wikipedia:CellularAutomaton programming…what if you could ask an EvolutionaryComputing? program, like Avida, to activate and deactivate different parts of different “cells” in an evolutionary way, to make a program try and solve a problem, or or adapt in complex ways to different conditions?

The basic theory behind this is that a program like Avida could apply rapid self-replication to the “cell” programs. These self-replications contain mutations, and they are systematically applied different working programs to see how they might be beneficial. The point is that the idea of “CellularComputing?” possibly enables EvolutionaryComputing? development of computer code.

If each cell conains the whole code, then an EvolutionaryComputing? program can crank out infinite variations of “cells”, and then it can plug these into different programs, either randomly or systematically, and the programs can duke it out and see which one comes out on top consistently.

Just crossread the page. A wikis are cells, B the base of life for cells is “neighbor awareness” C cool page :)

(I removed the part of my comment above about a communication bus between cells. I mean to delete it earlier.)

Footnotes:

1. See also: MetaphysicalCode, for ideas about metaphor, programming, and vision.
2. aka: key-value binding, hash table, associative array, …
(CommunityWikiFooter)

Define external redirect: CellularComputing KennethTyler ArticleMode EvolutionaryComputing PortlandPatternRespository

EditNearLinks: JavaBeans ObjectOrientedProgramming StrangeAttractor AlanKay

Languages: