A tribute to Dijkstra

It should be clear that all the years of my work on Z47 processor and Z++ formalism is not the equivalent of the monkey in the British Museum trying to type “To be or not to be”. Specifically, in all my writings on program correctness I have been careful to distinguish between an algorithm, and its implementation as an actual program.

To pioneers, like Dijkstra, the code looked and felt like mathematical formulas. In fact I remember reading Dijkstra, some 25 years ago, saying that procedures are the equivalent of mathematical theorems. Obviously I could not accept that kind of statement without some formal mapping. On the other hand, I could not dismiss the statement for the same reason. Indeed, I was inclined towards establishing it as a fact.

Interestingly, Dijkstra’s Shortest-path Algorithm is a point of diversion. It portrays an algorithm as a strategy that can be rigorously verified. On the other hand, the implementation of the algorithm is the tactics we use based on the programming languages available to us.

A lot of defects are consequences of poor personal techniques just as a rookie is less likely to score a goal in a feasible situation than a skillful soccer player. However, most defects are created by, experts struggling with complicated programming tricks to mix and match technologies. That is why a coach replaces his soccer star when he finds the star too tired to be effective. Unlike soccer, resting for a few days makes things worse because the engineer has to recreate the information in her short-term memory.

According to Dijkstra, someday there will be a form of mathematics that can be used to prove the correctness of algorithms, systematically: something like algebra for equations, or calculus for continuous events. Even in recent history of mathematics, differential equations were essentially a bag of tricks for a long time. Indeed, much of Kleene’s work and current research is in this direction. However, that research should not be extended to, or mixed with program correctness, as Dijkstra envisaged.

The main cause of defective programs and unmanageable cost of maintenance is the gap between theory and technology. Although programs are not mathematical entities, programming does admit a monotonic formalism analogous to mathematics. The demonstration of this fact has been my research for past decades.

The materialization of programming formalism is of technological nature. Theoretical considerations are required for building the foundation for this technology. Specifically, isolated observations implemented in a large set of disparate languages and libraries, is not a technological solution. The notion of monotonic growth does not mean adding a new language to the set, which simply does a few more things somewhat differently.

The mathematical notion of number derives its usefulness from its lack of dependence to platform. Thus, Peano could study the characteristics of numbers without having to think about different notions of number used for counting different objects. Programming concepts can also be studied without having to think about idiosyncrasies of platforms. The solution to this problem requires a platform independent technological foundation.

Some of the disbelief for the existence of such a technological infrastructure comes from the fact that we have witnessed the rise of several paradigms. However, there has not been any scientific observation to argue that any paradigm is in conflict with any other. There is no slightest scientific evidence to believe that some future paradigm will become incompatible with any of the existing paradigms in such a way that it cannot be absorbed monotonically.

In other articles I have discussed the need for separating, system programming languages from a monotonic formalism for developing applications. In support of this argument, consider the simple fact that the notion of society is studied by a collection of sciences each dealing with its own abstractions.

Turning to the cost of maintenance, a simple research will reveal that the cost rises exponentially with time. In most cases, the interval of time is just a few months and the curve rises sharply. When we look at these products, we find them put together with a large set of technologies, including languages.

The solution to this unwieldy practice is to automate the work done by all these technologies, libraries and minimal languages, algorithmically. Once that is done, and only then, one goes about presenting the solution through linguistic abstractions. It goes without saying that the solution must provide the technological infrastructure for monotonic growth of the language without repercussions.

These points have been the guiding factors in the implementation of Z47 processor for the infrastructure, and the design of Z++ language for the software development formalism.

Zorabi Honargohar