Difference between revisions of "The nodal model"

From Organic Design wiki
m
m (Summary)
 
(19 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
<noinclude>{{glossary}}{{legacy}}</noinclude>The [[nodal model]] is a [[w:Distributed computing|distributed computing]] environment which has been designed for [[the project]] in accord with its [[:Category:Philosophy|philosophical foundations]]. These philosophies claim that all change in the universe, right down to the functionality of space and time, work in accord with a single unified principle. Distributed computing is a perfect context in which to work with these philosophies, because distributed computing is all about creating an actual real space and defining the laws that determine how its content changes.
 +
 +
In the [[nodal model]], the philosophy is used to [[unifications|unify]] the [[w:runtime|runtime environment]] with the [[w:class hierarchy|class hierarchy]] yielding a single global, [[self containment|self-contained]] network of concepts (classes, prototypes, templates, forms) and their occurrences (instances), each a unique [[node]]. The physical resource aspect of this network is similarly unified; from RAM, file system and WAN, so all applications, data and their persistent storage are all part of a single changing space of [[node]]s called the [[nodal network]]. The nodes play a similar role to [[w:Object (computer science)|object]]s in the common [[w:object-oriented|Object-Oriented]] paradigm.<noinclude>
 +
 +
Any object is related to other associated objects ([[association]]s a.k.a key-value pairs, attributes, properties, etc), which can represent active threads operating on a schedule. Active threads consume processing resources to manipulate various resources within their context in accord with their scheduled workflow. Processes at all levels are built from these workflow rules whether they're part of an application or a real-world organisation.
 +
 +
This functionality, which is common to all the objects of the [[nodal network]] is called the [[nodal reduction]] and is essentially a scheduler that replaces the traditional [[w:control flow|program flow]] system. Even though the nodal network is a complex application in terms of its functional requirements, it yet is able to be modelled completely as a [[nodal reduction|nodally-reducible structure]] of [[node]]s, which means that any other application or organisation can also be modelled in this way. In fact, the components of the nodal network are specifically designed as a re-usable universal template called a [[generic organisation]], which can be extended and refined for the needs of any context.
 +
 
== Summary ==
 
== Summary ==
{{:Nodal Model Summary}}
+
In the [[nodal model]], the items that make up the [[nodal network]] content are more similar to [[w:Object (computer science)|object]]s in the common [[w:object-oriented|OO]] paradigm than to files, because they exist and undergo change at [[w:runtime|runtime]] and exhibit persistent, globally unique [[identity|identities]] that are independent of their state or content.
 +
 
 +
They are also more akin to objects because they take the form of a container of [[association]]s that are like an object's ''properties'' and ''methods'', and they define a [[w:runtime|runtime]] environment consisting of special properties like ''this'', ''name'', ''parent'', ''type'', etc, which are available within the context of any object's methods while they are executing. This allows the executing code to navigate and manipulate the object structure from the point of view of the executing method.
 +
 
 +
The main difference between a [[node]] and a traditional [[w:Object (computer science)|object]] is in the way the ''parent'' and ''class/type'' properties have been handled. In the nodal modal, the two form an axis with the current working context (usually the ''parent'') called ''down'' below, and the type/class aspect containing all the node's processes and knowledge above called ''up'' (these have also been called ''father'' above and ''mother'' below after the [[:Category:Philosophy|philosophical principles]] from which this [[dialectic]] method is derived).
 +
 
 +
In addition to this ''vertical'', hierarchical dimension formed from ''up'' and ''down'', there is also a ''horizontal'' dimension formed from ''left'' and ''right,'' which allows the description, navigation and manipulation of sequences of content or processes purely through nodal structure, which is geometric- rather than syntax-based. It means processes all have a common way of talking about order and time, and can be used to build the next layer of common functionality called "generic organisation".
  
 
== Foundations ==
 
== Foundations ==
Line 12: Line 26:
  
 
At first glance that seems like a futile idea since having both layers defined in terms of the other is a paradox. But it's actually not a paradox because each is using the the description for a different purpose; the node-space executes it's list-space functions in "real time", but the list-space uses it's node space definitions only at compile-time. The semantic web is all about connecting with existing software in a context-independent and service-oriented way, and this used in conjunction with self-description allows a running node-space to build other node-spaces in any environment that implements its compilation process as a semantic web service. Our first priority is for each node-space to be capable of using a local C compiler to maintain it's own binary, then later we would extend this functionality to allow compilation for foreign environments and/or remote locations via SSH etc.
 
At first glance that seems like a futile idea since having both layers defined in terms of the other is a paradox. But it's actually not a paradox because each is using the the description for a different purpose; the node-space executes it's list-space functions in "real time", but the list-space uses it's node space definitions only at compile-time. The semantic web is all about connecting with existing software in a context-independent and service-oriented way, and this used in conjunction with self-description allows a running node-space to build other node-spaces in any environment that implements its compilation process as a semantic web service. Our first priority is for each node-space to be capable of using a local C compiler to maintain it's own binary, then later we would extend this functionality to allow compilation for foreign environments and/or remote locations via SSH etc.
 
== Nodes ==
 
{{:Node summary}}
 
 
== Generic Organisation ==
 
{{:Generic Organisation/Summary}}
 
 
<table class=expandable title="System architecture diagram"><tr><td>
 
[[image:System-architecture.png]]
 
</table>
 
  
 
== Abstraction layers ==
 
== Abstraction layers ==
Line 28: Line 32:
 
In the case of the nodal model, each [[peer]] maintains a ''microcosmic'' version of the whole network called a [[node space]]. The node space is locally available in RAM resource and is essentially a cut-down cache of the network content. Each peer runs the [[Nodal Reduction]] algorithm which determines the way the node space content undergoes change, and these changes then propagate out from local RAM to other peers and persistent storage resource. This means that the network architecture can be (and is) a ''nodal application'' which is defined as ''nodal reducable structure'' and is executed by [[nodal reduction]].
 
In the case of the nodal model, each [[peer]] maintains a ''microcosmic'' version of the whole network called a [[node space]]. The node space is locally available in RAM resource and is essentially a cut-down cache of the network content. Each peer runs the [[Nodal Reduction]] algorithm which determines the way the node space content undergoes change, and these changes then propagate out from local RAM to other peers and persistent storage resource. This means that the network architecture can be (and is) a ''nodal application'' which is defined as ''nodal reducable structure'' and is executed by [[nodal reduction]].
  
== Function execution ==
 
 
 
;Parameters
 
The ability to pass parameters to functions and have them return a value is necessary in a procedural language, but in an object-oriented program environment the organised object hierarchy and the ability to read and write properties within it can replace the need for parameters. For example,
 
:<tt>a = triangle.calculateArea(b,h)</tt>
 
could be replaced with statements that fill the objects properties, call the naked method which reads and writes the properties in its local scopen then the result is read from that object:
 
:<tt>triangle.base = b</tt>
 
:<tt>triangle.height = h</tt>
 
:<tt>triangle.calculateArea</tt>
 
:<tt>a = triangle.area = b</tt>
 
 
== Node space ==
 
A [[node space]] replaces both the [[w:control flow|program flow]] aspects as well as the storage and communications aspects of application architecture.
 
 
----
 
 
== Node ==
 
== Node ==
 
A [[node]] is like a hash table or associative array. Another way of looking at a node is as a file folder. Internally, nodes are referred to by [[identity|GUID]]s or [[node references]], which are meaningful only by their distinction from each other. In the user interface nodes are referred to by names appropriate to the context in which they're being referred to. GUID's are used for referring to nodes persistently for storage and [[communications]], but direct implementation-specific memory references are used at [[w:runtime|runtime]].
 
A [[node]] is like a hash table or associative array. Another way of looking at a node is as a file folder. Internally, nodes are referred to by [[identity|GUID]]s or [[node references]], which are meaningful only by their distinction from each other. In the user interface nodes are referred to by names appropriate to the context in which they're being referred to. GUID's are used for referring to nodes persistently for storage and [[communications]], but direct implementation-specific memory references are used at [[w:runtime|runtime]].
Line 49: Line 37:
 
Like a hash table, nodes are containers of keys and values, but because all runtime [[node references|node referencing]] is direct, the keys and values are references, not textual names like usual.
 
Like a hash table, nodes are containers of keys and values, but because all runtime [[node references|node referencing]] is direct, the keys and values are references, not textual names like usual.
  
== Nodal Network ==
+
== Tree rewriting ==
The Nodal Network is formed from communications between all the [[Peer]]s. Each Peer applies the [[Nodal Reduction]] process to its local [[Nodal Space]], resulting in the organisation of globally unique nodes [[Identity|identities]] and the [[Storage and Distribution|propagation of change]] throughout the network.
+
{{quote|It is perceived that one of the biggest problems in maintaining software quality is the above linear growth in complexity compared to the size of a program, resulting in the programmer's cognitive loss of an overview and ultimately the degradation of the quality of software. This thesis tries to counter that by introducing a language ([http://strlen.com/aardappel-language Aardeppel]) with a new sharing model that makes dependencies in a program explicit at the language level, and local to one specific language construct (the tree space). We introduce the language which is based on tree rewriting and Linda style tuple spaces and comes with a graphical programming notation. We discuss the worth of its design, precisely specify it using a formal semantics, and report on experience with the model using a real world implementation.|[[w:Wouter van Oortmerssen|Wouter van Oortmerssen]] (abstract from PHD thesis)}}
 
+
[[Category:Nodal Concepts]][[Category:Legacy Projects]]
[[Communications]] is a [[:category:Nodal Organisations|nodal organisation]] which extends reduction out to form a single harmonic ''global reduction space'' called the [[nodal network]].
+
</noinclude>
 
 
Large organisations involving the process and resources of many individual nodal peers rotate on larger loop cycles which are the globally known harmonics of [[spectrum]].
 
 
 
*DHT-like
 
*Routing & Discovery methods
 
 
 
== Nodal Reduction ==
 
{{:Nodal Reduction/Summary}}
 
 
 
*Function bindings and references
 
*Nodes have a common method of describing the sequence and scheduling of processes
 
*Reduction
 
*Event model & schedule
 
 
 
;Persistence
 
*Serialise & Deserialise
 
*Serialise builds a textual representation of a nodes structure, this is not an atomic process
 
 
 
;Interface & Content
 
*Renderable structure, including interface event represntation
 
*Applicational content
 
 
 
 
 
 
 
 
 
 
 
----
 
''old intro text''
 
 
 
Why do we need to start at such a basic level, when powerful high-level data-structures already exist in most programming environments that can easily support this? because:
 
*[[Wikipedia:Mutex]]
 
*[[Wikipedia:Linearizability]]
 
*[[Wikipedia:Non-blocking synchronization]]
 
*[[Wikipedia:Lock-free and wait-free algorithms]] ''(a fragment extracted follows)''
 
:''Writing a program that uses lock-free data structures is not a simple matter of merely rewriting the algorithms you would normally protect with a mutex to be lock-free. Because lock-free algorithms are so difficult to write, researchers focus on writing lock-free versions of basic data structures such as stacks, queues, sets, and hash tables. These allow programs to easily exchange data between threads asynchronously.''
 
 
 
:''For example, consider a banking program where each thread represents a virtual teller. A lock-based approach to making a deposit could be to have one teller lock an account to make a deposit, so that two tellers don't try to deposit into the same account simultaneously. To make the process lock-free, rather than designing a lock-free "deposit" algorithm you might have the teller submit a "deposit" request asynchronously to a centralized thread that handled all deposits.''
 
 
 
Each different programming language has it's own strengths and weaknesses across many different contexts such as efficiency, portability, scalability, availability of programmers, application-vendor support, protocol/standards support etc. But one area which is common to all languages and benefits greatly from unification is the concept of ''program-flow''.
 
 
 
The concept of program-flow itself comes in many flavours which appear in all combinations across the different programming environments. Some of these program-flow concepts are subroutines, conditional-structures, looping structures, event models and multi-threading models.
 
 
 
The nodal model can completely replace the program-flow aspects of the environment with an organisational environment where functions and objects of other languages are managed and executed to a schedule.
 
 
 
The nodal model does not use ''methods'' as such, but rather is more of a ''code-snippet'' model allowing larger code-fragments to be made from executing threads of snippets. Snippets are organised by language and environment bindings.
 
 
 
This organisational environment is recursive, hence is not just about software, but also real-world organisations, by integrating the nodal organisational environment with our own goals, roles, and resources.
 
 
 
*'''Moment''': A moment is pure instance, e.g. ''now''. Each node exhibits a loop which passes through the ''current-focus'' of all the currently active threads in the context. In fact the only way a thread can ever execute is by being inserted into the active-loop of its parent.
 
*P2P and change propagation. [http://meta.wikimedia.org/wiki/Help:Edit_conflict Editing conflicts] are made more of a problem in P2P due to the slow update. In a Nodal environment, editing conflicts are practically non-existent, and are easily resolved if they do occur. This is because the difficulty of the conflict is related to the size of the "atoms" involved (the smallest indivisible units undergoing change). In the case of current Wiki, CVS and most collaborative document systems is that these atoms are entire articles or files.
 
;See Also
 
*[http://en.wikipedia.org/wiki/Aspect-oriented_programming Aspect Oriented Programming]
 
*[http://en.wikipedia.org/wiki/Prototype-based_programming Instance-Based Programming]
 
*[http://en.wikipedia.org/wiki/Self_programming_language Self Programming Language]
 
*[http://meta.wikimedia.org/wiki/Diff Diff]
 
 
 
== Applicable concepts ==
 
Here's a list of concepts from Wikipedia which all apply to this model helping to describe what it is. The peer software...
 
*is a [[Wikipedia:Object Spaces|Distributed Object Space]] ''(a.k.a Tuple Space)''
 
*is a [[Wikipedia:Prototype-based programming|Prototype-based programming]] environment
 
*is an [[Wikipedia:Aspect-oriented programming|Aspect-oriented programming]] environment
 
*is a [[Wikipedia:Metaprogramming|Metaprogramming]] environment
 
*is an [[Wikipedia:Intentional Programming|Intentional Programming]] environment
 
*is an [[Wikipedia:Integrated development environment|Integrated development environment]]
 
*has [[Wikipedia:Reflection %28computer science%29|Reflection]]
 
*is a [[Wikipedia:Dynamic programming language|Dynamic programming language]]
 
*is an [[Wikipedia:Internet Operating Systems|Internet Operating System]]
 
 
 
 
 
== Processing and Data Storage/Access ==
 
<s>Each "middle" list-item</s>The data structure can process, store and move information at the same time, rather than the more usual two roles (processing - data IO). The data-structure inherently handles both storage and processing. The nodal structure allows peers to use their processing ability as a generic resource.
 
 
 
This can happen because it is a data structure that requires processing to work, all you need to do is to call its reduce function with no parameters.
 
 
 
The reduce function is called to provide a quanta of processing to the system. A quanta may be thought of as the smallest unit of time/energy available to the system. Once the quanta is consumed, processing stops until the next iteration of reduction.
 
 
 
The functions that are executed are a set of core nodal functions that are implemented in all major languages. By analogy, in XML, the DOM allows you to implement the particular tree in runtime that is specified by the XML and offers a number of generic methods designed to analyse and manipulate trees of DOM form, i.e. you can match patterns in the tree and you can manipulate the structure directly.
 
 
 
The improvement we can see over the DOM object concept is not only in the efficiency of the process, but also that the notion of time is incorporated into the processing/data IO paradigm of the project, since the data undergoes change based on its structure. The programming, therefore, is replaced by collections of data that undergo change automatically due to their structure.
 
 
 
The efficiencies occur because the structure is inherently thin, i.e. the methods used are few and simple, as opposed to the myriad of complex methods need to manipulate DOM objects. This is because the conceptual structure of XML is far more complex than that of the project.
 
 
 
'''Resolve:''' ''(was called path-traversal, nodal-traversal)''
 
*Accepts a path-list of nodes and traverses each in series to arrive at a final target
 
 
 
== Peer-Space ==
 
*Harmonic Organisation
 
*GUID's
 
*[[Communications]] ''(aka storage & distribution)''
 
*Sessions (moments)
 
 
 
== To Add ==
 
//  instance.create/delete(class) calls class.create/delete(instance)
 
//  create inserts the instance into the classes instance-loop (list-aspect, next/prev)
 
//  ie. our list of current children (that our E divides amongst) is also our instance-loop
 
//      has or is are one, they're all just relationships that receive a portion of energy
 
//  laster: a chain of delegate classes is created between root and the instance
 
// - the class of any assoc requires a portion of the quanta
 
//  remember, next/prev and complimented by parent/current (parent is also class)
 
// - this allows alternate quanta be divided between parent and current, thus providing
 
//  energy for the class->instance relationship
 
// - get retreives from class value if no instance value at each step of a path
 
 
 
 
 
// - all instance-loops work by going cd this.current then assigning this.current.next to it
 
//  when a function executes, it can update the loop at that location (equiv to array.push)
 
// - a functions parameters (and even further methods and tools) are child associations
 
//  the structures necessary to build the fucntion are child assocs too
 
 
 
*'''Threads''': conversation, list of instructions, phases or cycles of operation. These phases can also loop in a cycle like seasons or days of the week. The items that make up these lists are in general called ''Moments''. Threads are not instances, they can only exist conceptually. There can never be any such thing as an actual thread because only one part of it can exist "in the Now". It's because the ''thread''-nature of it stretches along the dimension of ''time''.
 
*'''Moments''': A moment is purely instance. Each node exhibits a loop which passes through the ''current-focus'' of all the currently active threads in the context. In fact the only way a thread can ever execute is by being inserted into the active-loop of its parent.
 
*P2P and change propagation. [http://meta.wikimedia.org/wiki/Help:Edit_conflict Editing conflicts] are made more of a problem in P2P due to the slow update. In a Nodal environment, editing conflicts are practically non-existent, and are easily resolved if they do occur. This is because the difficulty of the conflict is related to the size of the "atoms" involved (the smallest indivisible units undergoing change). In the case of current Wiki, CVS and most collaborative document systems is that these atoms are entire articles or files.
 
*See also [http://meta.wikimedia.org/wiki/Diff Diff]
 
 
 
=== Schedule ===
 
The schedule is used at all layers; process execution, [[Schedule|application]], people and organisations. Here we discuss it in terms of the concepts and processes which make it up.
 
*[[Entropy & Potential]]
 
*Auto reduction
 
 
 
=== Resource ===
 
The nodal version of the storage concept is actually '''Resource'''; the general idea of allocating, or "booking" the use of any kinds of resources to a schedule.
 
 
 
----
 
 
 
<table><tr>
 
<td valign=top>[[Image:Nodal-scale.jpg]]
 
<td valign=top>[[Image:Nodal-potential.jpg]]
 
</table>
 
[[Category:Nodal Concepts|Nodal Model]][[Category:Projects]]
 

Latest revision as of 01:54, 14 April 2016

Glossary.svg This page describes a concept which is part of our glossary
Legacy.svg Legacy: This article describes a concept that has been superseded in the course of ongoing development on the Organic Design wiki. Please do not develop this any further or base work on this concept, this is only useful for a historic record of work done. You may find a link to the currently used concept or function in this article, if not you can contact the author to find out what has taken the place of this legacy item.

The nodal model is a distributed computing environment which has been designed for the project in accord with its philosophical foundations. These philosophies claim that all change in the universe, right down to the functionality of space and time, work in accord with a single unified principle. Distributed computing is a perfect context in which to work with these philosophies, because distributed computing is all about creating an actual real space and defining the laws that determine how its content changes.

In the nodal model, the philosophy is used to unify the runtime environment with the class hierarchy yielding a single global, self-contained network of concepts (classes, prototypes, templates, forms) and their occurrences (instances), each a unique node. The physical resource aspect of this network is similarly unified; from RAM, file system and WAN, so all applications, data and their persistent storage are all part of a single changing space of nodes called the nodal network. The nodes play a similar role to objects in the common Object-Oriented paradigm.

Any object is related to other associated objects (associations a.k.a key-value pairs, attributes, properties, etc), which can represent active threads operating on a schedule. Active threads consume processing resources to manipulate various resources within their context in accord with their scheduled workflow. Processes at all levels are built from these workflow rules whether they're part of an application or a real-world organisation.

This functionality, which is common to all the objects of the nodal network is called the nodal reduction and is essentially a scheduler that replaces the traditional program flow system. Even though the nodal network is a complex application in terms of its functional requirements, it yet is able to be modelled completely as a nodally-reducible structure of nodes, which means that any other application or organisation can also be modelled in this way. In fact, the components of the nodal network are specifically designed as a re-usable universal template called a generic organisation, which can be extended and refined for the needs of any context.

Summary

In the nodal model, the items that make up the nodal network content are more similar to objects in the common OO paradigm than to files, because they exist and undergo change at runtime and exhibit persistent, globally unique identities that are independent of their state or content.

They are also more akin to objects because they take the form of a container of associations that are like an object's properties and methods, and they define a runtime environment consisting of special properties like this, name, parent, type, etc, which are available within the context of any object's methods while they are executing. This allows the executing code to navigate and manipulate the object structure from the point of view of the executing method.

The main difference between a node and a traditional object is in the way the parent and class/type properties have been handled. In the nodal modal, the two form an axis with the current working context (usually the parent) called down below, and the type/class aspect containing all the node's processes and knowledge above called up (these have also been called father above and mother below after the philosophical principles from which this dialectic method is derived).

In addition to this vertical, hierarchical dimension formed from up and down, there is also a horizontal dimension formed from left and right, which allows the description, navigation and manipulation of sequences of content or processes purely through nodal structure, which is geometric- rather than syntax-based. It means processes all have a common way of talking about order and time, and can be used to build the next layer of common functionality called "generic organisation".

Foundations

The nodal model is designed to offer a high level environment appropriate for representing semantic networks and executing applications directly from high-level semantic definitions. Another important aspect is the ability for the nodal-model's definition to be as context-independent as possible. This is achieved by building the nodal model entirely from a small set of conceptually simple "atomic" components similar in nature to machine code instructions. There are two main abstraction layers involved, list space and node space.

The node space level is the high-level semantic-network like environment in which we can define executable models for organisations and applications. All the functionality required to implement a node space is defined in terms of the list space functions.

List space provides a small set of functions which operate on a binary address space and offer a generic associative array. Generic means that in any item in the space, the keys of it's key:value pairs (associations) can be any type such as URI's, MD5-hashes, names (i.e. sequences of items from a particular set of symbols) or most importantly references to other items. An associative array in which keys are references to other items in the array is fundamental to semantic networks, but very few modern programming languages allow their array keys to be object references which makes runtime implementations of semantic networks inefficient. List space provides an associative memory specifically designed for runtime semantic networks, and is defined to integrate with systems directly at the machine level. It has very few functions and all are simple to port to any executable environment.

Although the list space functions are very simple conceptually, they cannot be created directly out of list-space functions as these are specific to the building of a list-space, not to describing algorithms no matter how simple they may be. But the next level up, node space is designed to generically describe algorithms, so the implementation and interfaces making up the list-space functions can be implemented within a node space.

At first glance that seems like a futile idea since having both layers defined in terms of the other is a paradox. But it's actually not a paradox because each is using the the description for a different purpose; the node-space executes it's list-space functions in "real time", but the list-space uses it's node space definitions only at compile-time. The semantic web is all about connecting with existing software in a context-independent and service-oriented way, and this used in conjunction with self-description allows a running node-space to build other node-spaces in any environment that implements its compilation process as a semantic web service. Our first priority is for each node-space to be capable of using a local C compiler to maintain it's own binary, then later we would extend this functionality to allow compilation for foreign environments and/or remote locations via SSH etc.

Abstraction layers

Distributed spaces exhibit two fundamental abstraction layers called the logical and the physical. The logical layer is a set of unique nodes which conform to a unified addressing mechinism and make up the content of the network, this layer is akin to the objects at runtime, or the files in a filesystem or network. The physical layer is composed of a network of peers which together constitute the actual storage, processing and bandwidth resource from which maintains the existence of the logical content.

In the case of the nodal model, each peer maintains a microcosmic version of the whole network called a node space. The node space is locally available in RAM resource and is essentially a cut-down cache of the network content. Each peer runs the Nodal Reduction algorithm which determines the way the node space content undergoes change, and these changes then propagate out from local RAM to other peers and persistent storage resource. This means that the network architecture can be (and is) a nodal application which is defined as nodal reducable structure and is executed by nodal reduction.

Node

A node is like a hash table or associative array. Another way of looking at a node is as a file folder. Internally, nodes are referred to by GUIDs or node references, which are meaningful only by their distinction from each other. In the user interface nodes are referred to by names appropriate to the context in which they're being referred to. GUID's are used for referring to nodes persistently for storage and communications, but direct implementation-specific memory references are used at runtime.

Like a hash table, nodes are containers of keys and values, but because all runtime node referencing is direct, the keys and values are references, not textual names like usual.

Tree rewriting

Quote.pngIt is perceived that one of the biggest problems in maintaining software quality is the above linear growth in complexity compared to the size of a program, resulting in the programmer's cognitive loss of an overview and ultimately the degradation of the quality of software. This thesis tries to counter that by introducing a language (Aardeppel) with a new sharing model that makes dependencies in a program explicit at the language level, and local to one specific language construct (the tree space). We introduce the language which is based on tree rewriting and Linda style tuple spaces and comes with a graphical programming notation. We discuss the worth of its design, precisely specify it using a formal semantics, and report on experience with the model using a real world implementation.
Wouter van Oortmerssen (abstract from PHD thesis)