Assembly Line Engineers

A large software development shop is an array of cubes housing engineers. There are various groups of engineers working across an invisible software assembly line. Several of these groups specialize in particular languages and their associated libraries. Then, there are certified individual familiar with the latest peculiarities of the operating system or technologies they supervise. Yet another group consists of those familiar with high-level architectural ideas and the latest standards, such as UML, XML, SOAP and DCOM.

A smaller software development shop has considerably fewer engineers, and yet the entire parts of the assembly line are fairly noticeable. Thus, despite the fact that the project is smaller the complexity of its development is about the same. Furthermore, evidently each member of the smaller team is aware of a great deal more and is able to use it all concurrently.

For a moment this all seems natural. After all, a car is assembled as it moves along the assembly line. So, perhaps software should also be assembled using several languages, different versions of libraries and so on. That is why applications are costly to maintain and therefore expensive. That is just how it is, or is it?

Since all languages are mapped to the instructions of a hardware processor, a theorist will declare that all languages are equivalent, without reservations. Well then, let us examine the notion of equivalences of languages more closely.

The language Eiffel emphasizes Design by Contract, relying on its linguistic abstractions such as invariants, which its compiler enforces. Suppose we endow C++ with a similar mechanism through some form of library extension. As far as the theorist is concerned, the engineer is responsible for remembering to include certain statements at end of each and every relevant method.

Leaving the implementation of difficult and confusing concepts, like invariants, threading, IPC, strong mobility etc. to engineers results in as many different defects as the number of individuals. In an ideal situation a human will make no mistakes. Nevertheless, it is possible to create such an ideal environment by involving the compiler. Pragmatically thinking, it is better to rely on a compiler for not making mistakes rather than accepting the theoretical equivalence of languages.

Engineers should systematically follow proper patterns. However, the language must also be capable of evolving by providing linguistic abstractions that the compiler could enforce. The whole idea of having a language is to be able to abstract and automate the causes of complexities in order to reduce the defects associated with them. But, is it possible to evolve a language without deprecation of previously written software? The answer is indeed yes.

Our wish is a language that can monotonically grow, providing more abstractions without the costly side effect of having to repair previously written software. We know that aside from translating the language to the instructions of a processor, the compiler will also need help for threading, IPC etc. from an underlying operating system. Therefore, there is really one solution to this problem, and that is the existence of exactly one operating system running on the same one processor for all platforms.

At first glance, the requirement of a unique operating system for all sizes of computing devices may sound ridiculous. In fact, we want to see more operating systems than just Windows and UNIX even for desktop devices. Yet, at the same time, we want to write applications exactly once, without the use of multi-platform libraries and other similar software.

Ironically, Z47 processor solves exactly these technologically outstanding problems, and yet software companies prefer to produce assembly line software and thereby reduce their share of the profit, as they are entitled to. These companies pass their profits to those who have created the illusion that software assembly line is a fact of life.