History

Early Study Phase

1986

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.

1988

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.

1990

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.

1993

During my year abroad at Sussex University in Brighton, England, I come in touch with the Internet (email) and UNIX machines.

1994

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.

1995

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.

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 concepts.

1996

During my student's research project and diploma work, I implement parts of a Neural Network in Object Pascal (Delphi).

1998

First steps in C++ at my first employer HM Informatics.

1999

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).

2000

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 months.

2000

My Java knowledge can be manifested at Intershop Communications where we are building solutions for e-commerce (Web Client-Server Applications).

2001

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.

Project Start

2001

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).

2001

Following the standard approach and several Java Tutorials, my first application is nothing more than a main method which creates a Java Swing JFrame.

2001

Stepwise, I start moving out code into special classes, like for example all GUI code into a class Frame.

2001

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 further patterns.

2001

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.

2002

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.

2002

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 Lifecycle Methods.

2002

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 Ontological Level.

2002

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 ontology structure.

2002

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.

Hierarchy Everywhere

2002

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.

2002

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 Model.

2003

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.

2003

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, Object.

2003

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.

2003

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.

2003

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.

2003

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

2003

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.

2003

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 (CYBOI).

2003

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.

2003

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.

2003

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.

2003

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.

2004

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.

2004

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.

2004

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.

2005

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.

2005

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.

2005

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 a toolkit.

2005

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.

2005

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.

Advanced Improvements

2006

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.

2006

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.

2007

The CYBOP theory is published in form of a book.

2008

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.

2008

All CYBOI source code gets adapted to using wide characters/Unicode.

2008

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.

2008

Various converters get implemented, e.g.: xml, tcp socket, http request/response, uri, html.

2010

Array functions are unified for all primitive data types.

2011

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.

2011

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.

2012

A CYBOL knowledge path is now capable of handling not only part names, but also indices.

2012

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.

2013

CYBOI compiles under Windows OS so that CYBOL applications can use the win32 console and graphical display.

2013

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.

2013

Date and time handling turns out to be a complicated subject, in whose investigation a lot of time has to be spent.

2014

Nested knowledge path names are now possible using parentheses.

2015

The cybol syntax gets simplified further from four tags to now just one tag called "node".

2015

Sockets are working fine and may be used to realise web applications.

2016

The implemented stack memory is essential for processing data structures with unpredictable tree hierarchy depth.

2016

An easy solution based on recursion gets found for cloning functionality (deep copying).

2017

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.

2018

A uniform input/output entry structure is used internally for all communication channels.

2018

The functionality for deep part comparison, lexicographical comparison and sort operations gets implemented.

2019

The cybol base library gets started, in order to provide standard functionality.

2020

The input/output channel handling gets improved.

2021

An interrupt pipe is used to communicate between blocking input/output threads and main thread to avoid busy waiting with endless loop.

2021

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.

2021

Any kind of message language (protocol) may be used thanks to length prefix and end suffix detection.

Consolidation

2022

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.

2022

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.

2022

Several de-/serialisers get implemented (json, csv, joined string, numeral).

2022

The cybol models can now be saved not only as xml, but also using json arrays.

2023

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.

2023

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.