Data and Fungibility

Fungibility is an important concept in economics. Basically it states that:

A given unit of some commodity is completely interchangeable with another unit the same commodity.

That is, if one has a given number of units of some or other good, it is equivalent to substituting these for a different lot of the same quantity and type.

Ultimately, this loose coupling makes large scale trading plausible, because, when the trade is finally cleared, clearly any tonne of wheat will suffice (I don't specifically need the tonne of wheat harvested from some particular farm in Argentina or Australia).

In the world of computers it is almost assumed that data is fungible. That is, clearly one does not actually move the bits from one process to another. Rather, the actual data representation in one process is precisely communicated to the receiving process. Within the address space of the receiving process an equivalent representation of the data is constructed. Clearly, any such reconstruction will suffice.

So, it would seem that clearly networked computing processes already benefit from the fungibility of data.

However, when it comes to actual implementations, while this idealistic world view sketched above does hold partially true, even this state has generally only been attained via the painstaking efforts of the developers and is often a very tedious undertaking. It is not an implicit artifact of computing. Various technologies try to simplify these efforts (e.g. RPC, CORBA, Web-services, OR-mapping etc.), however, when using these it seems that often the underlying problem is simply being hidden by additional layers rather than fundamentally solved.

It would seem to me that in order to address these issues we need to strive towards true fungibility of data. That is, we need data that can be automatically moved from one process to another where it can be used directly even when these processes have been developed completely independently of each other. Equivalently, we need data that can be repeatedly passed through different computing layers (communication, logic, persistence) automatically rather than relying on any additional efforts on the part of the developers in order to map the data between layers.

More plainly, data fungibility should be an implicit part of computing and should be efficient and compatible across all computing layers and span all cooperating processes.

Within a world where data is truly fungible, the efforts of developers can then be turned to focus on the real computational problems and not on the task of moving data between systems.

How we get there is left as a cooperative exercise for the reader...

Modern Society and Story Telling

It seems that as a society our process of story telling is broken. The majority does no tell stories, rather they watch stories, record stories but do not really share stories.

There is no explicit feedback between the story tellers and the vast consumers of those stories. As a result our societies capacity for learning is impaired. In a sense, it seems that our society has degenerated to have a lower level of awareness.

The flow of views, concepts and feelings is one directional and is guided by commerce rather than passion.

Again, it is as if the speakers in our world are so self absorbed that there is no feedback from other parts of 'the self' or from the 'reality' outside of 'the self'. In this case 'the self' referrers to the entire society and to an onlooker it would probably seem as if the whole society was simply completely absorbed in it self - sometimes in a manic way, and at other times in a depressed way.

This process of self absorbed behaviour has become institutionalised in our top-down hierarchical chains of command. In many countries there is democracy, but the common instantiation merely plays lip service to the need for feedback, while being careful to not really respond to the feedback.

It seems that before the industrial revolution there were various levels at which this feedback still functioned. At the community level, there would be an oral tradition of telling stories. This allowed many different narrators to subtly and gradually influence the stories with their own views and the views of the communities to which they responded. Similarly, because there where many, loosely connected towns, each one could specialise the stories in ways that where important to them. Once in a while these evolved stories would cross over to the next town or community and the process would continue. Slowly, social truths and values would be distilled out.

However, through the use of written forms this evolution of stories becomes less fluid. Through the use of movies, even the room for interpretation has all but been removed. Simultaneously, the written form and other means of communication allow for more explicit and rigid top-down control from those in power.

In is no wonder that modern society has been pushed back to nuclear families and that there seems to be an increasing sense of disconnectedness and meaninglessness in the world. Slowly, but surely the reach of our feedback has actually been pushed back to within the boundaries of the individual.

However, this push back seems to have created an increasing need within the individuals for being self aware. For, the individuals are not confined in a dark world, rather it is as if they have each been put behind one-way glass where they can see and hear the world but nobody can see or hear them. With all this information raining down on them, they still need to process it and make sense of it. Yet, the only means for this is via increased internal awareness.

Recently, it seems that we have started to see the tell-tail signs of individuals beginning to push back with their individual feedback, for the same technologies that have enabled the top-down rigid control, have finally begun to be accessible to all the individuals in our society. In a few short years we have seen as explosion in personal web pages and blogs . Soon afterwards we saw the inclusion of comment mechanisms enabling the story teller to obtain feedback from their audience.

Now, we need to start growing the processes for meaningfully assimilating these stories and retelling them so that, once again, values and concepts can be distilled out. So that, once again, society can learn from its own experiences and recreate its internal awareness.

Only, this time it will be impossible to do this without simultaneously being aware of context of all of humanity and the environment of our entire planet.

My Event Driven Life

Asynchronous message passing seems to be the ideal way to implement large scale distributed systems with high internal concurrency.

Maybe, then, it should come as no surprise to me that I sometimes feel that I am merely an "active object" cooperating in an event driven existence:

• I leap into action when an e-mail arrives
• I respond to bills when they arrive in the post
• I set reminders on my phone
• I queue messages in my inbox for later processing
• I leave post-its on the wall
  

In a way this seems like the perfect adjunct to the "browser existence" where I surf the net for new events. When I see something of interest I leap into action again...

Now, is this a "bad thing"^TM? Should I be worried that I should be taking a more considered approach to my interactions? Or, should I rather be taking a second order approach and looking for optimisations in my response time to events and improved heuristics for evaluating the relative priorities of queued requests? Maybe I should be spending time to identify gaps in the my event processing highlighted by event stimuli that I don't act on, or only partially handle? Maybe this is the great search for closure.

Furthermore, maybe I should really be looking for large scale patterns that relate the set of actions and events that I manage, to those of the other people around me. In this way I might find ways of enhancing and improving my life and those around me as I interact with others who share in this cooperative complex system that makes up our civilisation.

Misconceptions regarding Science

There are a number of common misconceptions regarding science and the scientific method. Both proponents and opponents of science fall into these traps.

Very simplistically the key points can be summarised as:

• science is not equivalent to reductionism
• holism is not equivalent to mysticism
• creativity is not equivalent to art

Together with:

• the scientific process is fundamentally creative
• the scientific process includes both reductionism and holism

Many fields, and indeed humanity as a whole, would benefit greatly from realising that an unnecessary wedge has been driven in between reductionist though and holistic thought. Both of these modes are essential for a thorough and complete analysis or any field, and both benefit by being brought together with the rigour and openness afforded by the scientific method.

Seeing Systems

• When we want to change the world, where do we look to make the change?
• When we want to change our lives, where do we look to make the change?
• When we want to change ourselves, where do we look to make the change?

Time and again we watch movies, read books and come across stories of great battles. The story of the good-versus-evil. The hero who rises up to meet his nemesis and be the victor over his opponent.

Why then do we make such poor progress in the real world, with our real lives? Surely all we need to do is uncover the one point of weakness, find the one person to blame and then eradicate the problem once and for all.

But that is where the world of stories and the real world diverge. Here in our real world there is no one single problem. There is no one dragon to slay so that the world will suddenly resound triumphantly.

Instead there are a million little pieces. Under each stone there is a slightly different story. When we change one part of the puzzle, other parts seem to rewrite themselves. When we stab defiantly at the "cause" we shriek out in pain, not realising that we are actually attacking another part of ourselves.

This is the complex world we live in. These are the types of interwoven lives we share. These are the intricate and unique selves we see in the mirror.

Should we want to change these? Definitely. Life is change.

Should we be fighting these? Probably not.

How do we tackle this then? I do not know. However, maybe we should be telling different stories. Creating new metaphors. Expanding our repertoire by seeing the systems for what they are and not trying reduce them to a single point, a single villain, a single mistake.

In changing how we see the world, there is once again hope. A breath of fresh air as we gain perspective and right ourselves for the next joyous step.

Why create Models?

Models are abstract representations of some system. This abstraction needs to capture some useful essence in order to be valuable. However, why do we really create models?

The standard answer generally seems to be that we create models so as to predict the behaviour of the system in the future - and this in turn relates to our process of reaching a point where we can justifiably say that we feel that we understand the system in question.

While I do not refute this motivation, I believe that there is an equally important reason that is simply overlooked in most cases. That is, a model is an abstraction that is created so as to act as a scaffold that enables a particular pattern to become embodied within a newly forming or created system.

That is, the process of modeling is fundamental the creative process.

In a sense, this means that the models really are the bridge between holism and reductionism, between creativity and rationalisation, between development and understanding.

However, what is a model. To the creative artist the model can be a few broad brush strokes or underlying constructions that capture the essence of an image or the center-line and gesture of a figure. Whereas, to the physicist the model is a well defined set of equations or algorithms that enable the key measurable behaviour to be reproduced, with sufficient accuracy, based on a smaller set of initial conditions.

To the pure mathematician and the abstract artist the models are a thing of beauty in and of themselves that, in their own right, are worthy of being pursued.

What we seem to see is that at the one extreme the models are highly rigorous and exacting, whereas at the other extreme the models are very descriptive and free form. However, there is an application where models need to encompass, albeit a milder expressions, of all of the above attributes: the development of complex systems. These might be complex computer software systems, socio-political systems, large scale engineering feats.

Part of what characterises these systems is that after the designing and implementing these systems, they need to be concrete functional (working) artifacts, yet at the same time these artifacts are new creations that did not exist before and that have been built up from simpler parts. In this setting the model becomes the bridge between the process of creating and the manifestation of a completed functional product. As such the model needs to incorporate a degree of the rigour and closure present in sciences, yet it needs to be simultaneously sufficiently flexible to match the creative process of exploration. Finally, this rigour and flexibility needs to combined into a single process that enables its application to be viable and effective. Additionally, in order to understand the development and evolution of complex systems (natural or man-made) we need to understand how models are related back to the systems.

Thus, it seems that models are the bridge enabling us to direct the creative process so as to move from a blank canvas to a responsive and functioning concrete artifact. The corollary being that understanding how models are related back to their complex systems will be the bridge that enables us to gain insight into how systems evolve, change and develop.

The Death of The Stack

The Death of The Stack is the gateway to asynchronous computing and high concurrency applications, and thus will ultimately enable higher complexity in software.

Currently all major programming languages are stack based: C/C++, Java, .Net, Smalltalk, Perl, PHP, Python etc. The importance of the stack concept influenced the development of the underlying CPUs which generally have special segment registers and corresponding op codes to facilitate stack manipulation.

The use of a stack in a procedural language like C makes sense in terms of the basic metaphor - call a function and, on returning, continue where you left off. However, it begins to show its age in any OO language and doubly so in the development of multithreaded applications or distributed applications.

In OO languages an object cleanly encapsulates its own data and functionality, yet the actual execution is still delegated to the underlying machine, be that a physical CPU or a virtual machine. Thus the metaphor in OO does not extend to the encapsulation of execution.

Viewed differently, the stack is inherently bound to the current thread of control, yet the thread of control can cross over from one object to the next as new functions are called. This breaks the illusion that objects are autonomous entities. Instead there is always the need for creating an object and then, independently, a thread of execution.

This makes it cumbersome to implement asynchronous execution. Synchronous calls are obviously modeled well by a stack, where the return is handled by popping off the current frame. Yet, an asynchronous call requires explicitly using an API to create a new thread and either initialise the thread with a closure (runnable, delegates, anonymous object etc.), or trigger a method via a message queue (or trivial blocking latch). To get information out of a thread we need to explicitly create listeners or additional message queues.

Thus, while languages facilitate thread synchronisation (e.g. Java monitors and the synchronized keyword). None of the mainstream languages actually encapsulate a suitable model for asynchronous calls.

To escape this short fall we need to build languages that are stackless. Stated out of context this seems like a bit of a jump in the line of reasoning. But lets ask the question: what does this mean and why will it support the changes needed?

Languages like Self talk of activation records. Thus, when a method is invoked, an activation record is created. This is essentially an instance of a small object that holds the local variables and method arguments together information about execution of method instructions. Using this paradigm, the record could actual be allocated on the heap along with all other short lived object instances and recycled via garbage collection.

If these activation records are chained together in a linked list, and the activity in the current one is suspended when a new activation record is created, then clearly we are modeling the same synchronous call path that the stack models when the equivalent information is stored in a stack frame.

However, if the underlying (virtual) machine serviced all activation records simultaneously as they where created, then every activity would execute concurrently - on current CPUs and operating systems this could be implemented by having a number of underlying service threads that carry out the work.

Unfortunately, this is clearly an over simplification. For one, a given object could be carrying out two different actions simultaneously (since the calling object could simply invoke the object twice in succession). This would generally lead to undesirable behaviour unless the object performed explicit internal locking for synchronising manipulation of internal state. Instead, I would suggest that a more sensible default is that any given object can only perform exactly one task at a time. If the object wishes act as if it was performing multiple concurrent operations internally, it could simply delegate tasks to a number of inner objects.

Furthermore, there is still a need for "returning" data. However, this could be achieved by utilising a callback mechanism - which would now be safe since there would be no growing stack in the case of mutual recursion (A calls B and B calls A).

Finally, there is still the need for serialising certain tasks into a clear sequence. However, this could be easily achieved by using a simple state machine to manage instructions. That is, the language construct implicitly creates lightweight objects that act as state machines that, upon receiving a completion callback from one instruction, would trigger the invocation of the next instruction. Instructions would generally be akin the the Smalltalk metaphor of message passing.

Thus, in the end, by removing stacks we open up the path towards true asynchronous, high concurrency languages that will be able to take advantage of increasing number of underlying cores being made available in modern CPUs.