Characteristics of the language for domain of applications

In previous section the Categories of languages was presented. The argument was that the languages for most areas are standardized while the domain of applications is still a war zone. We also argued that the process of solving a problem in this domain is not programming. The term programming implies the type of activity that makes an entity behave in a certain way.

In developing an application we do not engage in programming any entity at all, physical or virtual. Instead, we manipulate the actual domain in such a way so the problem can be expressed linguistically. Obviously the language used for expressing problems must possess certain characteristics.

In How indispensable is Z++ we mentioned some of the desirable characteristics of an abstract language, which we will include in the list below for convenience.

1. None of the paradigms is adequate by itself. We need them all, and more.

2. The combined set of features of C++, Eiffel, ADA and APL falls short of requirements for an abstract language.

3. The future language should be a coherently designed superset of a well-established language. The notions involved in developing software are becoming increasingly more complex. It is therefore desirable to learn them in a sequence of increasingly larger languages. Each language in the sequence should accept programs written in the language it extends.

4. The abstract language must provide support for interacting with other technologies, such as database. However, the support should be limited to data manipulation. That is, we only need to interact with an existing database, but not to modify it by adding new tables to it. Software engineering must be separated from hacking and marketing strategies.

We should avoid the loop of making same mistakes in different disguises.

1. Gluing disparate languages using yet another (interpreted) language used to be an acceptable chaotic practice only because we did not have the language providing full-scale support for an abstract language. This practice is the plague that will kill many businesses before it is abandoned.

2. C++ is not the abstract language we are seeking precisely because we need C++ for system programming.

3. There must not be different versions of the abstract language, by all means. That completely defeats platform-independence, which is the number one priority.

4. The notion of code portability does not apply to an abstract language, while it is quite desirable for a system programming language like C++. Software developed in an abstract language, on the other hand, is expected to run on future platforms, just as well.

By abuse of word I would like to refer to "distributed component-based development" as a paradigm. It is not hard to deduce that software in this paradigm satisfy the further requirement of being independent of platform.

The idea here is that, one should be able to develop an application on a single convenient system, comprising of several components. The components, however, could run on platforms of different sizes and shapes. Nevertheless, the engineer crafts the software oblivious of any platform idiosyncrasies. Furthermore, the engineer designs the software as a set of cooperating components.

Before closing let me clarify some possible confusion. A jar file is not a component. In fact, other than Z++ there is no language that supports distributed component-based development. For an illustration please see the white paper titled "Component" at ZHMicro.