The subject mentioned in the title of this short article does not seem, at first glance, to be a genuine research subject. Although there are, from time to time, some famous breakdowns of large computerized systems as, for instance, recently at SBB in Zurich, it seems nevertheless that these systems are working nowadays in a satisfactory fashion. As a consequence, their construction process must have been mastered, otherwise such disasters would have occurred more frequently. This was clearly the case at the beginning of last century with an emerging technology such as avionics. There were lots of crashes due to the fact that people did not know how to construct good airplanes. The main reason for this was that they did not understand yet the theory of flight mechanics, which was in its infancy.
In our case, however, the situation is a bit different from that of early avionics in that there is no clear theory (yet) related to large computerized systems. The most obvious indication supporting this fact is that, most of the time, experts cannot clearly explain why such systems indeed work correctly. When a serious breakdown occurs, the corresponding superficial reason is normally found after some time (not always however), and it is usually “repaired” in a very ad-hoc fashion. But people are never sure that another breakdown will not occur some time later, precisely because they do not know the more profound reason for that earlier breakdown. It is my belief that such a state of the art is not satisfactory.
From (almost) the beginning of Informatics, the main tools used to develop computer systems was a, so-called, High Level Programming Language and a corresponding Compiler. There has been many of them (far too many in fact) proposing new features that pretended to solve the problem of constructing better programs than the previous generation of High Level Programming Languages and Compilers did. It does not seem however to have solved the problem since, over the years, the famous “software crisis” is still with us.
An interesting research is then to investigate whether there could exist some other intellectual means and tools that could be used instead of High Level Programming Languages and Compilers. It does not mean of course that we believe that we can replace final computer programs by something else. But, we would like to investigate whether we could invent some other ways to obtain such final programs.
When High Level Programming Languages were invented in the sixties (i.e. Algol), the idea was to make abstract programming patterns such as conditionals, loops, procedure calls, and the like be first class citizens in the programming methodology. In the more restricted realm of Assembly Code, such programming patterns did not exist explicitly but were all implemented by means of a single feature, namely the conditional goto instruction. The High Level Programming Language was then an abstraction of the more concrete Assembly Code. And the Compiler was the tool that allows us to move from this abstraction to a concrete implementation. Note in passing that the goto instruction still remained for a while as a proper feature of High Level Programming Languages before eventually disappearing for ever (e.g. Eiffel).
An interesting statistics that can be obtained from high level source programs is the ratio of the number of lines of code devoted to “pure” algorithms over the total number of lines of code, excluding comments and the like. Of course, the figures differ from one application to the other but it is usually far less than 1/2. This means that such abstract “relational” features as components, classes, methods, inheritance, visibility, assertions and the like describing the objects, their properties, and their relationships are becoming far more important than pure algorithmic features such as conditionals, loops, and more generally “calculations”. It is my belief that such abstract relational features are not well handled in a High Level Programming Languages, whereas pure algorithmic calculations are in my opinion still well handled in such languages.
In other engineering disciplines (i.e. mechanical construction) people do not hesitate to use languages when they are clearly needed and other means when they are not needed. For instance, they use the language Mathematica to define the formal computations related to their usage of the Calculus. But they do not use languages to describe the complex relationships between the components of their future system, their properties, their links, etc.. In fact they store the various components of their product in one form or another and express the relationships that hold between them. We can consider that they thus build a Database of their future system.
What is wrong is to have the semantics of the High Level Programming Language being the medium defining the properties of the offered features. This is far more easily handled (and modifiable) as the invariant properties of a Database. Note that this Database could then be boostrapped formally. It might still be useful to have some “pretty printing” of the contents of the database. This would resemble a high level program but would be produced as an additional output of the construction process rather than as its input.
The Database approach can offer quite a number of other advantages over High Level Programming Languages. Here are a few of them:
In conclusion, we question the present usage of High Level programming Languages for constructing large and complex computerized systems. We propose instead to partially replace it by defining and using a System Construction Database. As a matter of fact, this proposal is not really new: EiffelStudio is a proposal that has been made for a number of years and that goes clearly in that direction.
Diese Website wird in älteren Versionen von Netscape ohne graphische Elemente dargestellt. Die Funktionalität der Website ist aber trotzdem gewährleistet. Wenn Sie diese Website regelmässig benutzen, empfehlen wir Ihnen, auf Ihrem Computer einen aktuellen Browser zu installieren. Weitere Informationen finden Sie auf
The content in this site is accessible to any browser or Internet device, however, some graphics will display correctly only in the newer versions of Netscape. To get the most out of our site we suggest you upgrade to a newer browser.