Part 1. Modern Consitency of Programming Languages
1. Conceptual Scheme of Programming Languages
1.1 What is a Programming Language
At first, let’s give an extensional definition of PL, thus clearly list those concrete languages in which we are knowingly interested (them we confidently consider to be programming languages). These are Fortran, Simula, Pascal, Basic, Lisp, Fort, Refal, Ada, Si, Okkam, Oberon. However, it would be beneficial to have an opportunity to predict, based on a definition new, specific cases that haven’t been mentioned in the definition
.
Such definition must be based on existing characteristics of chosen for examination languages. It must be intentional. Let’s give one of the possible intentional definitions of PL.
Programming Language - a tool for planning the behaviour of an executor.
However, firstly, the PL’s mentioned prior are used not only for planning behaviour of executors (computers), but also for exchange of software/programs between individuals. Such a function of utmost importance substantially affects the structure and principles of creating PL (even though it still remains secondary. It’s provable that people must understand and read software/programs, even if having no intentions of exchanging them, since in other ways a big enough software/programs just can’t be created.) This function of the language simply can’t be ignored while studying PL.
Secondly, in our definition, every word requires to be clarified. Can “tools for planning the behaviour of an executor” be an official instruction, a writing desk, an intercom device, traffic regulations or Russian language?
Let’s look on our actions from the perspective of a bystander, diverting ourselves from the roles of consequently author and readers on the only just ended very first segment of our joint venture. In other words, let’s rise to a meta-level, in order to view the primary level as a whole.
What were we doing?
Firstly, we tried to reach consensus on the question of what is PL. Secondly, in order to reach this consensus, we started applying the method of consecutive elaborations.
What did we achieve and what remains still unclear? One thing that became clearer is what we are going to study. We can give examples with which everyone agrees, and indicate objects that surely aren’t consistent with out definitions (also counting on common agreement in them), for e.g. left pedestal of a writing desk. We also understood that reaching consensus (even in the case of familiar concepts) can be very difficult. What remained unclear was from which position and with what objective are we going to study PL.
With our first approach, let’s try to eliminate these ambiguities. However, through out our joint venture we will be engaging in successive clarifications of many important concepts, since our journey is not formal, but informative and we are interested in truly existing, emerging and on our eyes developing objects, real PL’s. Thus it is impossible to give an exhaustive description of PL as a concept (the concept lives with and within us).
Reaching consensus can be very difficult. In order to highlight the problems evolving at this point, let’s study the following model of message transmission. (fig.1.1)
| Semantics | -------- Meaning ------------ | Pragmatics |
|
Sender -> Message -> Addressee/Recipient
|
| Syntax |
Fig. 1.1
In this model, highlighted are the concepts”Sender” (author, generator of the message),”Addressee” (recipient, reader, listener of the message), the “Message” itself (text, sequence of sounds),”Meaning” of the message (something signified by the message, in accordance to rules and regulations that are familiar to both the sender and the recipient).
Highlighted are also the names of scientific disciplines that subsequently deal with, rules for building feasible messages (Syntax), rules for collating such messages with meaning (Semantics) and rules which regulate the application of these messages (Pragmatics).
Author can use a word with a vague meaning, implying only one of its many possible meanings, whilst the addressee can choose another one. Let’s consider for e.g. a fragment of a recipe for preparing chocolate fudge; “rarely mixing, boil on low fire, until a drop will start turning in cold water into a soft ball”. Isn’t culinary art called an art, rather than exact science, due to the fact that different chefs, knowing one and the same recipe differently interpret the words “rarely”, “slowly”, “cold”, “soft”, as well as with different frequencies will try to “turn the drop into a soft ball”. Obviously, the results they all will achieve will be different. This is a semantic misunderstanding.
Finally, the author can sometimes have difficulties to imagine which interpretation the addressee can give to his message, if their conception and view of the world or the problem that is to be solved greatly differ from each other.
For e.g., message of a lecturer of a forecoming colloquium can be interpreted by students as an call for not attending uninformative lections in order to have time to work with the books. This is already a pragmatic misunderstanding.
It’s easy to give other examples of syntactic, semantic and pragmatic misunderstandings in an attempt to come to mutual understanding. However, why right in the beginning we started talking of mutual understanding and of the obstacles that stand on the way of reaching it? Mainly, this is due to two reasons.
Firstly, PL is an instrument for achieving mutual understanding (safe “mutual understanding”) between humans and computers, as well as between people on the matter of controlling computers. Because of this, in the principles of construction, structure, concepts and constructs of PLs, find their reflections, in essence the overall problem of mutual understanding, the views of creators of a PL on that problem and concrete methods for solving it.
Secondly, the way by which people overcome the obstacles on their way towards mutual understanding, contains some substantial elements that are at least as important as when communicating with computers (in particular creating and using PL). Incidentally in the International Standardisation Organisation ISO has been developed a document [1], regulating the system of PL standards. The document contains classifications of software defects, being in full concordance with our classification of misunderstandings.
We shouldn’t be especially fearful of syntactic misunderstandings. They are usually caused by individual, careless phrases and can easily be eliminated with an immediate question. In PL this is also not a problem. In PL there are no syntactic misunderstandings. This is due to the fact that creators of PL are governed by principles of uniformity: a programming language must by syntactically uniform (i.e. any correct text written in PL must have only a single acceptable structure).
Hence, one of the principles of PL construction has been formulated, clearly distinguishing PL from e.g. natural languages. Such kind of general principles and concepts will be our primary points of interest.
Semantic misunderstandings are more dangerous. If, for e.g., the word “language” (“˙çűę” in Russian) will be associated with a subproduct like tongue (the same word “˙çűę” in Russian), the misunderstandings could spread out of a single phrase. Big language, fresh language, red language, green and blue language; these can all be concerned with German language as well as with PL (in a competition of language projects, which became one of the stages of creating the language Ada, competing languages received conditional “colourful” nametags. The winning language was the “green” language.).
Method of fighting with a semantic misunderstanding in human communication is known. Important concepts and ideas have to be highlighted, given specific and accurate definitions and appropriate, distinctive examples should be given. This is the task of the speaker. The listener, in return, has to try to grasp the remaining substantial ambiguities, give counter examples (of objects that are inline with given by the speaker definitions, but apparently haven’t been implied by the speaker and of objects that have been implied by the speaker but aren’t inline with the given definitions.) Such a method of accurate definitions is widely used in PL (definition of procedures, functions and types in Pascal) as well as examples and counter examples being applied in debugging of programs.
In our fighting for mutual understanding, we actively use the apparatus of abstraction-concretisation (generalization-specialisation).
Whilst creating concepts, we divert our attention (abstract) from insignificant properties of such concrete objects on the basis of which concepts are created and concentrate in the process of concept creation only on substantial, important from the perspective of the task that can only be resolved with the application of this concept, characteristics. Thus, in the concept of “clock” we usually concentrate only on its property as “a device showing us the time”, and divert our attention from its form, structure, colour, material, producer and other attributes of a specific clock.
Giving an example, we concretise an abstract concept by “supplying” it with secondary, from the perspective of its essence, but important in a concrete situation, details. Thus, specific execution of a procedure takes place with the help of specific meanings of its parameters. I.e., a specific example PL, Fortran, has specific syntax and specific semantics.
My watch is big, round, gilded, with three hands, of brand “Tissot” and with a leather belt. All this tells little of its properties as an “a device for showing the time”, but any specific device/apparatus always possesses such “dispensable”, from the perspective of its main function, properties. Their existence only underlines the fact that an (abstract) concept never exhausts a concrete object. It always only reflects just one specific point of view of or on this object, acting as a component of its model which has turned out to be useful for solving a specific task. In another situation, while solving another task, the same specific object may play another role. Then the point of view on it might also be different and can require a totally different model for the same specific object.
In some instances we could prefer viewing the ”device for showing the time” as an ornament, and then from that perspective (in that role) its form, colour, size and brand will become more important that its ability to correctly show the time. We can look at this procedure as on an “object, consuming mechanical resources”. With its role being such, the meaning of the actions it’s performing becomes totally insignificant. On a PL, sometimes we are forced to look as on an object of standardisation, and then what becomes important is not what specific properties its syntax and semantics have, but rather are there enough people and organisations interested in one or another of its properties.
Involuntary, and sometimes even intentional, but not a foregrounded change of perspective resulting in an essential transfer towards another model and thus interfering with reaching mutual understanding, can act as a source of pragmatic misunderstandings. You’re saying that the watch is a “bad one” because it is ugly, while I say that the watch is a “great one” because it works excellently.
Capability of changing from one model to another without difficulties, to clearly fixate and easily change the level of examination as well as the angle of view are often indicated as the most important professional qualities of a programmer.
Well return later to discuss the role of the just listed aspects for creation and application of PL, while now we shall concentrate on discussing the main aim of the book (in order to coordinate our objective attitudes/ objectives)
We intend to present principles of valuation, creation and application of modern PL. This is a much needed, fruitful and absorbing field of research, which however is yet not stabilized and is rapidly evolving and developing. Because of this, there is no possibility to base our work on findings of predecessors, nor on stable programs or textbooks (as it happens in, for e.g., in the study of mathematical analysis or differential equations). Thus, we are/one is forced to take risks and to experiment.
Hence, concerning our main aim. It consists of an attempt to correctly orientate the reader in the field of PL, to help him to grasp the skills and experience gained through individual work with concrete PL.
But can the idea of “correctly” orientating be too dangerous? Since, if for e.g., the authors image of the professional inquiries of the reader or of the tendencies of PL development turn out to be false, then most probably the “correct” orientation will in fact turn out to be disorientation. Wouldn’t it be better to limit ourselves to presenting only undisputable positions from the field of PL – since they will be needed for sure!?
Unfortunately or luckily, in fact we have no alternatives. Absolutely undisputable positions generally tend to concern only specific PL. For example, “One of the operators in the Pascal language is an assignment statement. It is built like this. Its function is that.” In a well-known programming textbook this position is generalised. It is said like this: “An assignment that changes the meaning of a certain variable appears to be the fundamental activity in any algorithmic language”. And this is already false! Nowadays a lot of attention is dedicated to so called functional programming, to applicative PL, where assignment is not only not a “fundamental” activity, but it simply doesn’t exist!
Does this mean that in the field of PL there aren’t enough of universal undisputable positions? In some sense there is. Often these positions are not so undisputable, but rather deserving further examination. However their universality is of different nature. Previously mentioned principle of uniformity could act as an example. Or the translated phrase from the textbook - an undisputable enough position, if considering that it characterises a specific PL class, from which one of the most “renowned”, widespread and the same time promising languages Lisp, is excluded. Thus, even if we limit our selves only with relatively undisputable positions, they still must be selected from certain positions, with a defined goal. A natural goal is our strive to bring the reader maximum benefit. Once again we come to “predicting” future needs.
Setting teaching of free use of a specific PL, even an extremely interesting or a promising one, as our goal would be incorrect. This part is covered by special textbooks, exercises and most importantly, by practise.
Our task is to make the reader familiar with the most important ideas and conceptions, helping evaluating, applying, implementing and developing PL, as well as to give the reader an idea of the directions and problems of their development. Because of this, let’s engage ourselves mainly into the study of PL models. In other words, when studying PL, we will systematically apply a principle of modelling (as of PL themselves, also of their separate aspects). The most important from one reason or the other PLs or their constructs will sometimes be examined to great detail, but primarily only as examples, illustrating more general positions.
For example, it is vital to understand that with every PL there is tied a normative (abstract) executor, in which there is defined data, operations, binding, nominations, apparatus of estimation and control and possibly an apparatus of exclusion, synchronisation and defence. It is important to understand the listed above terms, the function of appropriate language constructs, as well as being capable of applying them while solving practical tasks. What is not so important is to memorize all details of a specific PL connected to them. Last may occur as relevant only when details illustrate the key concepts of the PL studied. For example, firm rules of marking selection in Basic are immediately tied with its orientation on relatively small programs and on simplicity of implementation.
Thus let’s consider that objective attitudes/ objectives are agreed upon to a level high enough to be able to take the next step – proceed to systematic study of our subject. Right away a question follows. Where should we start from? It’s easy to say ”systematic”. However systems can be of different types. One often begins from the”bottom”, starting from main constructs, found in nearly all existing PL. In this way, we right away sink ourselves into the world of variables, constants, parameters, procedures, cycles and etc. Such a route is tempting since it is a relatively easy one. But on this route, behind the trees we see no forest, meaning that we are unable to see the PL as whole, to build an adequate model of it.
Because of this let’s choose another route. Let’s try to look on the object of our study, PL, from general positions. We will be especially interested in technological, semiotic and author’s positions.
First one is called technological, because it reflects the view of an individual, willing or forced to use PL as an technological instrument on one of the stages of creation and application of software products (in other words, during their life cycle). It’s natural to explain oneself with such a person in technological terms.
Second position is named semiotic, because it can be imagined as a position of an individual, familiar with some semiotical systems (Russian language, road signs, positional systems) and interested in what makes such remarkable systems as PL stand out. What follows is that this should be explained to him in semiotic terms.
The third position is the author’s position. The author creates the PL, makes it renown in the programming community, perfects and modifies it with appropriate consideration for incoming suggestions and critical remarks.
We’ll pay attention to other positions as well, notably mathematical and implementers.
A mathematician understands what is a mathematical model of the studied object and strives to make himself familiar with mathematical models of PL. It would be desirable to communicate with him in mathematical terms.
Implementer provides the opportunity to use PL as a mean of practical programming. In other words, he not only creates translator, but also writes methodological guidelines that educate and control the programs as well as tests translators and etc.
It is appropriate to underline that from different positions we will discuss and study the same object. We’ll start from the technological position, by establishing a connection between PL and production of software products.
Measuring the effectiveness of one or another production is reasonable only against the parameters of its goal (final result). Because of this it’s important to understand that the final goal of programming is not creating software just on its own, but rather providing software services. In other words, programming in its essence is targeted on providing service to a user. And real customer service should be governed by a famous principle: “The customer is always right”. When applying to programming, this principle means that software must be “friendly” in respect to the user. In particular they must be reliable, robust and “caring”.
First one means that the program must contain as little mistakes as possible, second, that is must maintain its ability to work even in difficult conditions of exploitation and third, that it has to know how explain its actions as well as mistakes of the user.
What “little mistakes” means, depends of the purpose of the software (it’s clear that a software for teaching Russian language and an autopilot software can have different kinds of reliabilities). Under “difficult conditions” we understand the limited amount of resources provided to the software (memory, input-out channels, number of processors), reboot (a lot of users, large volumes of data), users mistakes, failures and disruptions of devices, attempts of conscious sabotage of the software and etc.
What has just been said, relates to the functioning of the software. However it’s important to understand that software service, is not just a mere service provided to the user directly through the work of the computer which is dictated by the software, but also monitoring, evaluation, sales, selection of software, their transfer to another executor, escorting and certification (authoritatively certified qualities) of software and etc.
When production of software services reaches a certain level of maturity, crude production evolves into an industry of software services and theory of programming, servicing its needs. As well as the industry, also the crude production is used in one or another technology – technology of software services production, i.e. programming technology.
(About the connection of science, are, theory and technology in programming, amongst others stands out Donald Knut’s Turings lection in Communication of the ACM.- 1974.- Vol.12.- P.667-673).
Hence, the fundamental aim of programming – production of software services. It is known that this type of human activity in developed countries, comes out on the first place amongst other industries (for e.g. in the U.S.A this branch of economics already outstripped the recent leaders, the oil and automobile industry).
However what is also known is that creating software and providing other connected to it services still remains too expensive and lengthy of a task in which it is difficult to guarantee a high quality end result.
What is then the principal cause for such a position? Is it connected to the nature of programming itself or does it carry a subjective character?
At the moment a short answer could be formulated as follows: “complexity – the fundamental problem of programming; is connected with its nature itself; we can hope on its decrease for tasks classified as mastered”.
Let’s try a bit more accurately to clarify on why the complexity of objects with which we are forced to deal with acts as the lineament in programming of computers.
After finding the source of complexity, the path for its overcoming can be searched with a higher hope for a favourable outcome.
When executors perform slowly, but actions that are considered to be elementary, are specific for the type of services provided, then planning of the executors activity and criteria of quality for such planning substantially depend from the service provided as well as from a concrete set of elementary actions.
Scarcely is it recommended to delegate, let’s say, to a factory technician who is a specialist in metal refinement by engraving to plan a tailored outfit for someone. For this we have tailors, who in return would probably have a lot of difficulties in applying their skills in creating a technological map of a factory. In other words, considering the set of “elementary” actions of the two studied categories of executors equivalent is unnatural.
Computers function quickly and the sets of their commands are equivalent in a known way. Moreover, throughout several years the tendency of involving speed and memory volume at a fixed price ( *10 during a decade) has been maintained. In such circumstances arises the potential/principal possibility of adjusting the executor to provide services for a very wide range of classes (at least, the boundaries of this class are unknown). For this, it is enough to provide the executor with an appropriate plan of actions (code/write a program).
This potential/principal possibility tempts to adjust the computers on the types of services that are very far from the elementary capabilities of an executor. Moreover, almost all significant services are of such kind. Because of this, in general, the plan of actions should foresee a huge number of elementary actions over an enormous number of elementary objects. However this isn’t enough. The most important is to provide a huge number of connections between such objects. Because of this the software itself becomes enormous (there already exist programs which consist of millions of commands; for example for control of military and cosmic objects).
In the mean time, the capabilities of a human to work with a large number of interconnected objects, as we all know, is quite limited. As a kind of an reference point in evaluating these capabilities the “number of Ignve”, being equal to seven (plus-minus 2), is often pointed out. In other words, a human being is often not capable enough to work with an object which consists of more than seven components with arbitrary mutual connections. Until then while programming still remains mainly a human activity, the pointed out limitation must be considered.
In such manner, by providing universality, speed and potentially unlimited memory, creators of computers, from one perspective tempted humanity by unprecedented possibilities, while at the same time set us face to face with problems of unseen potential complexity (in the attempt to materialize these hypothetical possibilities).
Related to this, it is appropriate to mention a notable principle “shove the work to the user”. Inventor of computers, by providing in to the hands of programmers an abstract device unique by its capabilities, for providing specific services, “shoved” on them the hard work of adjusting this abstract device in order provide concrete services. However such concretisation turned out to be far from trivial. Programmers, in their turn, when creating “universal” programs, “shove” the hard work of their application in concrete circumstances to the potential users of such programs.
Hence, the first source of complexity in programming, the so called semantic gap, a gap between the level and nature of elementary objects and operations from one perspective, and potentially possible services, from the other. In other words, this is a problem of scale coordination; we are offered to construct cities using jewellery instruments.
Exactly this source was in our mind, when we were discussing the objective nature of inherent to programming complexity. When involving ourselves in a specific class of services (tasks), we can strive to highlight the typical to that specific class set of elementary objects and operations, to build an appropriate executor (by means of hardware or software) and to program using this, more suitable executor.
Actually this means to create a PL that is adequate to the chosen class of services. In practise this is the most widespread method of dealing with complexity and simultaneously the main reason for the growth of Problem Orientated Languages (POL).
There exists also one more essentially important source of complexity, complicating our “mutual understanding” with computers. We’re talking about lack of real world models in modern day computers, which would be in congruence with the picture of the world of both programmers and users. Because of this, in general, computers are incapable of controlling orders given by the programmer or actions performed by the users, from the pragmatic point of view (to control in conformity between actions and those goals for the sake of which these actions are performed; the goals remain unknown to the computer).
Because of this, the”smallest”, from the perspective of the creator of the program, lapse can lead to totally unpredictable consequences (It is a widely known case, when one comma in a program written by Fortran, caused a cosmic rocket that was heading towards Venus to explode; all efforts, that cost billions of dollars were lost).
Hence, as the second source of complexity in modern programming we should name the ignorance of computers towards the real world. Deprived from necessary knowledge, a computer can’t not only correct inaccurate commands in a program of actions, but it is also incapable of informing of deflections from the direction towards goal-oriented action. Traditional for computers control by means of directions for actions, not for the whole, requires consideration of tiniest of nuances of all possible circumstances, in which the executor can find itself in the process of providing the necessary service. This substantially increases the number of objects with which one is forced to deal with when creating a program. From here derives the increase in complexity of programming, increase in software sizes, decrease of their reliability and robustness.
The second source of complexity has been dealt with by developing methods of presentation of real-life knowledge in computers and by effectively considering this knowledge in creation and implementation of “user friendly” software.
The discussed sources of complexity play a vital role on theory and practise in the field of PL. Apparatus of abstraction-concretisation, found in one or another form in any PL, could be identified as the utmost important method for dealing with a semantic gap. Precisely this apparatus acts as the basis of problem orientated language expression methods.
For example, Fortran has a distinctive method of abstraction; a subprogram and corresponding to it method of concretisation, referring to it with actual parameters. Because of this, a natural POL, created by the means of Fortran, is a set (a package) of problem-orientated subprograms. In more modern PL are applied more developed methods of abstraction (abstract data types, clusters, frames) and corresponding to it means of concretisation (which we will discuss further). The possibilities to build POL become richer and richer.
As the most important method of dealing with the ignorance of the real world by the computer acts the apparatus of prediction-control. There are PLs in which this apparatus is practically absent (Apl, Fort, Lisp) or is very weak (any assembler). However exactly this apparatus acts as the base for increasing reliability and robustness of programs. Lastly mentioned doesn’t mean that “friendly” programs can’t be written using a PL with weak prediction-control. Just in this case, the creation of an appropriate apparatus becomes fully the responsibility of the programmer.
For e.g. in Fortran, a typical mean of prediction are built-in (predetermined) data types. Appropriate control is provided by semantics of the language, but there are no means of supervision of such control (new types of data can’t be inserted). In such PLs, as Pascal or Ada, this apparatus is more developed, and in so-called artificial intelligence languages it is directly intended for providing a whole enough picture of the world, aims of activity and control over actions as of the program itself as well as of the user.
Exercise. Give an example of methods of abstraction-concretisation and prediction-control in familiar to you PLs. Try to select symmetrical, complementary methods. Find out that this complementary is not always present.
Now we are ready to formulate the next main criterion of quality in a PL (as an instrument, i.e. from a technological perspective): the language is the better, the less complex its main production of software services is built.
Let’s leave our technological perspective on this for now and focus ourselves on the semiotic one.
Let’s continue clarifying on the concept of”programming language”. Our new intentional definition of PL:
programming language – a semiotic system for planning the behaviour of computers.
In order to create one self a more comfortable base for formulation evaluations, principles and demands, let’s adopt a view that narrows our field of study.
From now on, we will consider only “industrial” programming, which aims to create programs (software products) on order or for sale purposes. It’s typical characteristic – alienability of the result.
Secondly, we will be interested, in general, only in synthesizing industrial programming.
In third, at first we will be interested in the phase of software product design, since in it, in one form or another, we should consider the requirements of all other phases of the softwares lifecycle.
Two highlighted sources of complexity, the semantic gap and ignorance of the real world. It is useful to interpret two separate aspects of one common source; mismatch of models in a problem field (PF), in the field of services, tasks, user and executor operations.
It is impossible to adjust an executor immediately being adapted to perform any kind of services. However, it is possible to build specialised executors and to orientate them towards a fixed service class, i.e. PF. Problem orientated languages (POL) are created exactly for this purpose, for governance of such specialised executors. It is worth the effort, to try and build a PL, on the base of which it would be convenient/comfortable (relatively easy, with an acceptable expenditure of time and effort) to build models of rather various PFs. Such a language is called a baseprogramming language.
The base PL can also be considered as a specialised POL in its own PF, since it is aimed to build models of other PF and of corresponding POL. Further on we will be concentrating precisely on base PLs, and more accurately, on base PLs of industrial programming.
Consummating the training for systematic examination of series of PL models, let’s fix ourselves to one scheme of their examination. This scheme will help to compare and evaluate various PL, primarily from the point of view of their eligibility to act as a base language of industrial programming. In every PL, we will be interested in the following three aspects: base, developmental apparatus (simply development) and defence apparatus (simply defence).
Apart from base, development and defence, we will sometimes be studying also other specific features of PL, and in particular, specific features of a reference executor of PL (so-called language processor) and architecture of PL in general.
Architecture will be evaluated from the perspective of such concepts as integrity (ability to predict some solutions of language authors using other solutions, i.e. congruence of solutions), modularity, orthogonality (ability to freely combine small numbers of relatively independent fundamental expressing methods) and etc.
In conclusion, let’s underline that our scheme involves only internal aspects of PL, such as semiotic systems. Totally untouched remain such aspects of utmost importance to selection and evaluation of PL as, their prevalence in various computer types, presence of high quality implementation, the level of their compatibility and etc.