NHI1 - the FOUR crises

From NHI1
Jump to: navigation, search


This is the history of the libmsgque library, as extension for several programming languages:

  • C, C ++, C #, VB.NET, Java, Python, Ruby, Perl, PHP, Tcl or GO

The problem has always been to keep the code in sync, as each programming language has its own individual approach to extension programming, which ultimately results in a very small amount of shared code. This causes huge programming effort and slows down the development of libmsgque considerably.

   I called this the EXTENSION CRISIS.

To solve this problem, the code base for the extensions was synchronized and finally merged into a programming model with a focus on TWO independent "styles".

  • The "C" style for code written in "C-like" languages (C, C ++, C #, Java, and Go)
  • The "S" style for code written in "SCRIPT-like" languages (tcl, python, php, ruby)
  • And the special languages with special effort (VB and Perl)

The "C" and "S" styles share the MANAGED OBJECT Technology but use a different TOKEN STREAM compiler.


The next serious problem was the different life-time and life-cycle of instances in the different programming languages. This is closely related to whether or not there is a garbage collector.

   I called this the LIFETIME CRISIS.

The life-time and life-cycle of an instance varies from:

  • infinite, an instance is never deleted. (e.g. C, C++, Tcl)
  • immediately, (hard refCount) an instance is deleted immediately when the last reference has disappeared. (e.g. Python, C++ reference)
  • later, (soft refCount) an instance will be deleted at some point but it is difficult to predict when that will be. (e.g. Java, C#)

There are also aspects such as:

  • an instance is deleted but probably in a completely different thread.
  • an instance is never deleted but at the end of the program, at least sometimes.
  • an instance is actually NEVER deleted but it is OVERWRITTEN (deleted and newly created) if a NEW instance is created under the same NAME.

In order to combine all these imponderables, the MANAGED OBJECT Technology was developed and the STORAGE MANAGEMENT implemented.


The next serious crisis was ultimately due to the fact that resources (working time) are finite. The more successful something becomes and the more extensions to a programming language have been implemented, the greater the effort to keep it completely in sync. Every new feature in libmsgque required a post-implementation in 10 other extensions along with the necessary tests.

   I called this the UPDATE CRISIS.

In order not to endanger the whole development of libmsgque, the TOKEN STREAM COMPILER Technology was introduced.

  • Ultimately, something was created that reads the definitions of the leading project (libmsgque) and then automatically implements it in the various programming languages.


The next serious crisis was ultimately based on the fact that a carefully maintained project should also be carefully documented. Now it is difficult to find something that 11 programming languages are equally well documented, with the additional requirement that Close-to-Code should be documented. Close-to-Code means that if the programmer detects a documentation bug, he should be able to fix this bug immediately and WITHOUT any auxiliary means. The threshold should therefore be set very low in order to eliminate a documentation bug.

   I called this the DOCUMENTATION CRISIS.

From the request, the TOKEN STREAM COMPILER was linked to the DOXYGEN, so that the following was achieved:

  • All languages that are supported by the TOKEN STREAM COMPILER can be documented by DOXYGEN
  • The DOXYGEN code for the documentation is generated by the TOKEN STREAM COMPILER in the same way as the code for the extensions.