Here is a list of events and enlightening ideas that have
influenced the development of CYBOP.
Early Study Phase
Although having difficulties, my father manages to cross the
border to West-Germany by visiting some relatives. He also manages to
come back into the East :-) and a present I get is a brand-new
Commodore 64 home computer. I mostly play games on it but also
do my first steps in programming with BASIC.
In the late days of East Germany, new computer subjects are
introduced at schools. So I take part in them and continue learning
BASIC and some dBASE.
At the Technical University of Ilmenau, one of the first
subjects in my study is Algorithms and Programming where we learn
structural programming in Turbo Pascal.
During my year abroad at Sussex University in Brighton,
England, I come in touch with the Internet (email) and
Back in Germany, I start administrating the information
infrastructure in my parents' medical practice, learn about
Computer Hardware and wonder about how doctors are cheated with
overpriced products and services.
In the German c't computer magazine, I develop an
announcement of a new operating system called Linux. I order and
install my first distribution, SuSE November 1995.
We have a quite theoretical lecture on
Object Oriented Programming in Smalltalk. However, that
is the first time I hear about those (then still new) programming
During my student's research project and diploma work, I
implement parts of a Neural Network in Object Pascal
First steps in C++ at my first employer
At OWiS Software, I learn to change my thinking away
from only the source code -- towards the actual Concepts and
Architecture behind a software. I also learn how to use the
Unified Modeling Language (UML).
Recognising the opening of the SourceForge developer
portal in 1999, I set up the Res Medicinae project in April 2000.
It aims at creating a Medical Software for physicians.
Preparation, website, investigation on similar projects and so on take
My Java knowledge can be manifested at
Intershop Communications where we are building solutions for
e-commerce (Web Client-Server Applications).
I visit my first Free and Open Source Software Developers'
Meeting (FOSDEM) in Brussels, Belgium, where Richard M. Stallman of
the Free Software Foundation (GNU project) holds a talk.
Returned to my former university, I start active coding on
Res Medicinae in April 2001. It takes some time to handle the
Concurrent Versions System (CVS).
Following the standard approach and several Java Tutorials,
my first application is nothing more than a main method which
creates a Java Swing JFrame.
Stepwise, I start moving out code into special classes, like
for example all GUI code into a class Frame.
Soon I loose overview and realise the need for some clearer
structure. I remember the Design Patterns applied at my former
employers and start using the Model View Controller (MVC) and
Since flexibility is one of the most important aims of my
efforts, I realise the shortcomings of MVC and the
Observer pattern (bidirectional dependencies), especially when
it comes to web applications. A good solution I find is the
Hierarchical Model View Controller (HMVC) design pattern,
applied by the Scope free software project.
My disposedness to style guides, clean and well-documented code
lets me structure and order every method and attribute and check them
all for NULL pointer errors and other exceptions. I find out
that every attribute not only needs a set and get method,
but also a create and destroy method. Class names as type
information are handed over to the create method in form of a string.
Following the idea of create and destroy methods,
I come across the Component Lifecycle, described by the
Apache-Jakarta project. I change all code by applying
Having read the OpenEHR Design Document, I know that
classes should be grouped in layers with clear dependencies, called an
Ontology. Higher-layer objects consist of objects from lower-level
layers, but not the other way. I restructure my code by moving all
classes into new packages (directories), each representing an
Apache's lifecycle Concerns turn out to be useless. They
only break the ontology rack and violate its dependency rules by
connecting otherwise strictly separated system parts. Moreover, concerns
encourage the inheritance of redundant or overlapping properties. The
same counts for variations like Aspects and Interfaces in
general. I replace them all by pure Classes, following the
I begin to realise that not only View (MVC) and
Controller (HMVC) are hierarchical, but also the
Model (Knowledge/Domain) is. In many days and weeks of intensive
thinking I find that -- as in Universe -- actually every other
software component is hierarchical, too. Consequently, I introduce one
top-most super (meta) class Item that represents a simple
Tree (Map container). Inheriting classes do not need to
implement create, destroy, set or get
methods any longer since they inherit them from Item. This saves
me hundreds of lines of code, at once, and improves clearness a lot.
And this is my personal Break-Through. From now on, I first think
about nature and its concepts and then implement software source code.
Suddenly, everything seems easier, I have an Example, a
Way-to-go: Nature. There aren't less (rather more) tasks to solve
now, but at least the direction is clear.
By applying the new concepts, one difference gets very clear:
System Control- and Domain Model code are both hierarchical,
but different ontologies need to be defined for them.
An active system works on a passive model, that is it
depends on it. While a system provides the means for input and
output and controls the Action (Workflow),
a model just represents domain data. Searching for parallels in nature,
I find that Human Body and Human Brain correspond to
System and Model. What humans (possibly unconsciously)
want to do is to imitate themselves, with robots as with computers as
with other machines, tools or abstractions.
The overall structure of the Framework seems clear now.
There will be three major parts, Basic, Model and
System. Model and System both depend on the
fundamental abstractions of the Basic package which encapsulates
programming language types. In addition, System depends on
Encountering difficulties in synchronising Frontend and
Backend, I come to the conclusion that they are actually the
same, passive data models that have to be translated into each other.
It is not necessary -- even badly wrong -- to apply different design
patterns for their implementation. I change inheritances and
dependencies of many of my framework classes so that finally
Knowledge-/Domain-, Backend-, Communication-
and Frontend models are of the same super type. This decision
opens unforeseen new possibilities. All kinds of frontends, all
communication and backend mechanisms can now be implemented
modular and flexible.
Java's event handling using ActionListener interfaces
ignores the dependencies between ontological layers and is thus improper
(just like the concern interfaces mentioned above). I implement a new
Signal Handling mechanism which is oriented on parts of a
sentence in human language like Subject, Predicate,
I realise how far I have moved away from my original aim of
writing a small medical application. While implementing the new signal
handling mechanism it gets clear that I move more and more towards the
operating system and its hardware input/output handling code which
scares me a bit. But there seems to be no other way to go when aiming
at the creation of clear, easy, modular, flexible, correct systems.
Exceptions are system-internal Signals. It is not
necessary to use an extra signalling mechanism for exception handling.
And it is dangerous for security if an instance knows about its parent
to bubble up an exception. For now, I remove all exceptions besides the
standard one, which again saves me many lines of unnecessary code.
An abstract model has multiple properties. Not only it keeps
references to its parts (attributes) and procedures (methods), but also
it knows about the Model and Position (and possibly more
Meta properties) of each part.
After difficulties with the item meta model, I realise that I
actually want to replace the standard Class Concept offered by
Java and other Object Oriented languages. It takes me some weeks of
thinking to find the reason and way out: Traditional programming
mixes Knowledge with the Handling of its instances. Both need
to be separated. I move most classes to XML-based Model files and
call their specification Cybernetics Oriented Language (CYBOL).
Here begins a New Era. From now on, business domain Knowledge
and hardware-close System Control code are stored separately and treated
differently. The concepts to store static knowledge are very different
from those that are used to dynamically control a system's hardware.
Central Application Knowledge Tree
Later comparisons with biology support my theory. The genetic
information is static knowledge that gets forwarded from one cell to
another, during Cell Separation. The dynamic processing of that
knowledge, that is the creation and functioning of organelles is a
completely different issue. In a similar manner, application knowledge
has to become transportable between different platforms and absolutely
independent from hardware.
Since the time when I first experimented with lifecycle methods
'a la Apache Jakarta, I had used a configure method in
my code which could read external configuration files and configure
internal items accordingly. Nothing different was needed to read CYBOL
files. They represented the whole application configuration knowledge
and only had to be interpreted correctly. The remaining Java code
therefore not only had to contain system control functionality, but
also had to be able to read and write knowledge in form of CYBOL files.
For that reason, it was called Cybernetics Oriented Interpreter
In search for new concepts and ideas, I also read about a
number of philosophical theories from Aristotle, Leibnitz and others
and can identify a mistake in my thinking: the important separation is
not between Body and Brain as presumed before, it is
between Body/Brain and Mind! Neural Networks try
to imitate the functioning of the physical brain, but what I wanted to
do is to imitate concepts of the logical mind, of human thinking.
Reading a magazine about psychology and neurology, I come to
reflect the principles of Human Thinking. I see parallels to
basic concepts of software modelling and try to connect them. As result,
I can identify three fundamental kinds of abstraction that our brain
uses to understand its real-world environment: Discrimination,
Categorisation and Composition. Software developers apply
these concepts all the time.
From previous reflections I recall that a Whole item
knows about the properties of its Part items. I try to identify
such meta properties, read about Shape, Depth,
Movement as well as Colour in my Psychology literature
and finally stumble about Dimensions as known from physics. The
position and extension that part items span up within their whole item
do not only exist in Space and Time, but possibly also in
other kinds of dimensions like Mass or Force.
Since CYBOL contains all concepts that are necessary to model
knowledge, including Categorisation (inheritance), a CYBOI written
in Java causes unnecessary overhead. The interpreter's main tasks
(input/output- and memory handling as well as processing instructions)
are anyway situated close to hardware so that I start to reimplement
CYBOI in the C programming language.
An open problem that had caused me many headaches was the
handling of instructions. I remember the unification of communication
models which represented States that could be transformed into
each other by help of Translators. Journeys into
Systems Theory and a consideration of the Black Box
concept show the solution: State and Logic knowledge need
to be separated! The logic contains the rules (algorithms, operations)
after which an input state is translated into an output state. It takes
considerable thinking to figure out a common CYBOL structure capable of
representing states as well as logic.
The early CYBOL definition turns out to be insufficient. In hot
but constructive discussions with Rolf Holzmueller, one of my students,
the reason gets clearer and clearer to me: CYBOL must consider two
different hierarchies in just one model. One Model Hierarchy
represents the compound model as such. A second Meta Hierarchy
holds meta information that a Whole knows about its Parts.
The old CYBOL tried to put everything into XML attributes. The new CYBOL
uses XML attributes to link to parts and XML tags to model meta
information such as Properties and Constraints.
A lot of time goes into the implementation of CYBOI. Techniques
that have to be considered are, among others: signalling, threads,
UNIX and TCP/IP sockets.
While implementing a CYBOL prototype application, standard
programming constructs such as for Branching and Looping
are badly missing. It takes some reflexion to decompose these into
their actual elements and to provide the corresponding CYBOL operations
by using simple flags.
A further problem is the automatic indexing of Parts
belonging to a common list within a Whole model, for which a
special Name Structure has to be defined and additional CYBOI
routines have to be written.
It turns out to be problematic to use existing
Graphical User Interface (GUI) frameworks for input/output
(i/o). Many of them base on OOP principles; all require the adoption of
special structures. Since the first version of CYBOI is developed under
the Linux Operating System (OS), low-level
X Window System Libraries (Xlibs) functions are used instead of
The reception of signals (input) is moved into special threads,
one for graphical-, one for textual user interfaces, one for sockets
etc. But how can CYBOI handle these signals, if it has no application
knowledge? The solution is to, as property of the receive
operation, hand over a node of the knowledge tree containing possible
commands to react to, which are mapped to their corresponding handler
operations, in CYBOL.
The CYBOP theory is handed in as dissertation thesis.
The Theoretical Basis seems pretty clear now. Future work will focus
on the architecture and implementation of the CYBOI Interpreter.
Within two months of being unemployed, I review the CYBOI
implementation of input/output (i/o) threads, and can correct open
conflicts by using Mutual Exclusion (Mutex) flags.
Also, Central Processing Unit (CPU) busy states are now avoided.
Branches of the runtime knowledge tree are pointed to in CYBOL
by dot-separated names. Since sometimes, it is necessary to address meta
information (such as the colour of a menu item) directly, the knowledge
path gets extended by a second separation character, which allows to
distinguish between whole-part and meta elements.
The CYBOP theory is published in form of a book.
One mistake leading to conflicts with CYBOI memory handling was
that too much functionality had been put into the thread functions,
e.g. the handling of a signal, reception and conversion of data.
All that is now done in the main thread instead. What remains for the
input threads is just the setting of an interrupt flag in a
"sense" function, whenever data arrive.
All CYBOI source code gets adapted to using wide characters/Unicode.
CYBOL abstraction constants now follow the MIME type schema.
All constants, no matter for which kind of model or format,
get categorised into "abstraction", "channel", "model", "name".
This was not easy to figure out, since at the beginning,
it was not obvious to me that all kinds of formats (xdt, html etc.)
and even composed primitive structures (fraction, complex etc.):
use some kind of name/index/key/identification to identify the parts;
know about the abstraction/type of their parts (even a file system knows
about whether it deals with a directory or file, and which kind of file);
contain the actual model/data/value.
Various converters get implemented, e.g.:
xml, tcp socket, http request/response, uri, html.
Array functions are unified for all primitive data types.
The whole container framework gets refactored and simplified.
It is based on three fundamental structures: array, item, part.
The array is the basis holding primitive data.
An item consists of three arrays: data, count, size.
A part has four items: name, type, model, properties.
A part now has nine items: name, channel, encoding, language,
format, type, model, properties, references.
The references item counts the number of other parts which are using the part.
This is used to implement rubbish (garbage) collection,
i.e. automatic clean-up (deallocation) of parts that are not used anymore.
A CYBOL knowledge path is now capable of handling not only part names,
but also indices.
The CYBOL Application Programming Interface (API) specification
is now defined in CYBOL syntax itself and generated as HTML page to be
published on the website.
CYBOI compiles under Windows OS so that
CYBOL applications can use the win32 console and graphical display.
The German xDT medical data exchange format gets parsed and
interpreted successfully. A CYBOL application "xdt2html", displaying
xDT content as HTML page, was written for the "Res Medicinae" project.
Date and time handling turns out to be a complicated subject,
in whose investigation a lot of time has to be spent.
Nested knowledge path names are now possible using parentheses.
The cybol syntax gets simplified further from four tags
to now just one tag called "node".
Sockets are working fine and may be used to realise web applications.
The implemented stack memory is essential for processing
data structures with unpredictable tree hierarchy depth.
An easy solution based on recursion gets found for cloning
functionality (deep copying).
The capabilities of knowledge paths get extended tremendously.
They now offer easy access to nodes in heap and stack memory,
via name or index or reference. Also, redundant code for processing
compound state/logic models gets avoided thereby.
A new unique mime type "text/cybol-path" is used from now on.
A uniform input/output entry structure is used internally
for all communication channels.
The functionality for deep part comparison, lexicographical
comparison and sort operations gets implemented.
The cybol base library gets started, in order to provide
The input/output channel handling gets improved.
An interrupt pipe is used to communicate between blocking
input/output threads and main thread to avoid busy waiting with endless loop.
Blocking sensing threads are woken up by an awakener that sends
a fake input to the system itself, so that the input/output threads
can exit themselves.
Any kind of message language (protocol) may be used
thanks to length prefix and end suffix detection.
The communication architecture gets redesigned using
a standard cybol operation lifecycle. It also considers asynchronous
input/output using buffers. Standalone clients as well as server-side
client stubs are processed in a uniform way.
A cybol editor as development tool becomes imaginable,
since all cybol files represent a table with four columns:
name, channel, format, model. The parts and properties are the rows.
Several de-/serialisers get implemented (json, csv, joined string, numeral).
The cybol models can now be saved not only as xml, but also using json arrays.
A general stack handler with push and pop functions gets implemented
and used for storing stack variables in the signal (event) handler.
That way, cybol properties may be given when calling a primitive operation
directly but also when calling a compound logic via cybol knowledge path.
Thanks to a refactoring of the cmake configuration files, cyboi can now
be provided as both, a monolithic executable and a version with shared libraries.
In the wake of this, header files got finally introduced.