replicator.org ... incoherent code

Believing in Moore’s law and seeing that computer speed really doubles in around a year or two, reasonable linear slowdown of computer programs do not actually make it worth to create complex programs with lots of repeating code.

Instead I recommend creating simple data objects and the associated micro interpreters. Both are mostly small but always manageable units of code.

In current computer languages like C++ or C#, you can easily create any kind of acyclic directed graph describing domain language by implementing data objects which may include or refer to each other.

Doing this, you are able to nail down a language for which you are able to create actual instances directly inside your code. Then write an interpreter that executes the data objects and accesses the resources and facilities of your existing environment.

Managing multiple projects at a time is probably one of the more challenging requirements these day. I am personally struggling and found a lot to learn about procrastination and doing time management. The most influential sources for me were:

43Folders

Michael Mann presents very interesting tools and organization schemes essentially targeted towards ‘getting things done’.

The Now Habit – Neil Fiore

collects a number of rules against procrastination which work – at instant. I tried it!

The essentials are:

1. Try to prepare everything and aim for 30 minutes of quality work.

As pointed out by Andrew Koenig, “abstraction is selective ignorance”; Suddenly, abstraction feels like bad thing. Probably Andrew is right: abstraction is a very limited mean to reduce complexity. But reducing complexity at all is not a bad thing, so where is the difference?

Abstraction provides a simplified view to an initially more complex concept. Purposely ignoring some features that may avoid overwhelming clients. Not essentially bad, or?

The problems begin when clients start living in the abstraction world. That is, like living in a world without telescopes, microscopes and most doors closed, feeling like in a computer game where the movement space is limited to the paths the inventors created.

Today I finished reading a very interesting book about design: “Universal Principles of Design”. You might find it interesting, even if you are primarily interested in software design. This book covers many aspects and is a must read for every software architect. The 100 design concepts are cross-disciplinary and present good design examples of well known applications.

I would like to see more examples of this kind of interdisciplinary lectures.
By recognizing that our surrounding world is mainly based on concepts which are mostly based on the physical constraints we are living in, we may some time find out that all these concepts are all derived from a limited number of meta-concepts. This book is an inspiration for helping us (humans) to discover them.

Today, one of the more relaxed weekend day in these hectic – every day the time runs out – IT business, I thought about naming conventions and the ones I already use in my projects.

In the last few month I have written lots of production code in different programming languages and recognized that besides of all the conventions we use to format source code, I am missing naming conventions for identifiers.

It is not about writing the first letter in lower or uppercase, it is more about specifying a general terminology so that identifiers express more clearly what we can expect from a source code construct.

So, knowing that creating stable software is a hard endeavor, it is one of our responsibilities to build the means and concepts to make this possible without growing paranoia. And this is when formalisms come into play.

A formalism can be formulated as a concept and a concept can be implemented as a piece of software. Concepts are the most basic building blocks of software, and so they can be applied universally. Most of them even exceed their intended scopes and cross boundaries leading to unexpected applications.

Concepts are like lego bricks, they can be combined to create new ones with new capabilities that were never intended or predictable. Concepts are software patterns that can be formalized.

Well, not expected that it really works out, I was very impressed: 1500 lines of code of the state machine engine made it possible to replace all (around 20) hand crafted switch/case based state machines in one of the asynchronous frameworks I am working at. The state machines are specified by a syntax directly reflecting the UML state chart terminology, making the state machines much more transparent and extensible.

Yet, the state machine module is not finalized: missing are history feature and a proper documentation. If you know UML state charts and would like to try it out, please drop me a note.

But that’s not actually what I wanted to write about today. As the title implies, this post is more about object orientation and object models.

It was about time: David Harel and the Rational/IBM/UML gang fully specified state machines syntax and semantics and its graphical representation. Combined with a network transparent asynchronous messaging system based on Robin Milner’s Pi Calculus, the justification to model state machines to be used in C++ component development is reborn.

As Alan Cox pointed out
“A computer is a state machine. Threads are for people who can’t program state machines.”
creating a statemachine is not always that easy. But with a little help, we – the small group of 3 million C++ hackers – might get it right for the first time modeling a state machine by breaking it down into states, events and transitions instead of creating chaotic switch case monsters.

So after the Pi-Calculus engine was finally working, I realised that I need to rewrite a large part of the Paramatrix object model.

Before starting this endeavor and to avoid any disappointments, I have decided to create a portable 2D user interface engine based on the Pi-Calculus workflow engine for client side programming and the Qt4 framework from trolltech for server side widget display.

Happy detouring!

So, now it is time to explain the ongoing silence here.

First of all, I had many smaller projects which had a tight time schedule.

Secondly, I took a detour on the road to the perfect information visualization tool. As you might know from my previous blog entries, I was very enthusiastic implementing a workflow engine based on concepts from the Pi-Calculus and inspired by ROOM. The initial version was preemtive and multithreaded but not very convincing to me, the second version was directly implemented into the paramatrix client user interface and was cooperative, and now I decided to collect together all of the experience I made, to create a generic, cooperative one.