Andrei Ershov: “Two Views of Programming”
This article came into being when thinking about software development as a human activity. If in this regard we consider the work of a programmer, then it is necessary to distinguish between two, it seems to me, very different kinds of it: the programmer treats one of them as a servant, and the other as a master.
Let us elaborate this thesis in more detail.
')
When I think of a programmer as a host, I mean that he programs for himself. Having all the resources, all the means (virtually or physically - it does not matter!) At his disposal, he is the sole and final judge of his actions and their results.
When I think of a programmer as a servant, it seems to me primarily as a communication channel that perceives the task specification presented to it. The responsibility of the programmer for the correctness of the specification is very limited, on the other hand he undertakes to diligently implement the adopted specifications and issue the product program to the client (for a one-time account or permanent use, it does not matter!).
Naturally, this distinction was noticed by many. F. Bauer [1] calls the work of a programmer-servant programming by contract. Accordingly, you can call the work of the programmer-host programming for yourself. E. Sandeval [2] develops a close approach, highlighting a group of "terminal" programmers. Sometimes this distinction is made using the terms professional and non-professional programming for the servant and master. Such an interpretation is permissible if we explore the social side of programming as an activity, for example, its professional ethics. If we talk about programming, bearing in mind its internal content, in this case, looking at the host programmer as an amateur can lead to misunderstandings.
The programmer-servant, in a certain (very deep) sense, does not know what the customer wants, and relies solely on the formulation of the problem. Of course, he is not illiterate, and may know a bunch of things about the subject area. He can provide invaluable services to the customer by finding many inconsistencies in his specifications. However, all this is beyond the plan. Its main and only business is to convert the specification into a reliable and effective result: a program or data.
This is the kind of programming that has been worked on the most and that dominated during the formation of programming. This work has led to the possibility of rigorously justifying each step of building a program, and this opportunity is undoubtedly the greatest achievement of computational science. The methodological principle of abstraction from the informative knowledge of the programmable task turned out to be very fruitful: it led to the development of generally significant and powerful methods of manipulating programs and reasoning about them, based on the schematic representation of the program in the uninterpreted signature of elementary operations and predicates.
Another aspect of programming, however, also existed all this time. Being rotated in the direction of the backyard of programming, he nevertheless gains "second wind" in connection with the emergence and development of personal computers. Moreover, a system programmer in his kitchen, lined with tool machines, often behaves like an owner. Such facilities as extensible languages, macroprocessors, rewriting systems, compile-time operations, universal editors, and much more have already accumulated in this farm. This assortment, however, has developed by chance and is not ordered either by a good theory or a reliable methodology. Only recently a collective term has emerged, under which, as a banner, non-compressed system programmers gather, the programming environment (programming environment), or - more deployed, but more precisely for the Russian language - the operating environment for building programs. To turn this fashionable word usage into a coherent methodology with a solid theoretical substantiation is an important and fascinating task of theoretical and system programming of the 80s.
The host programmer knows what he wants.
This is the fundamental methodological difference between contract programming and programming for oneself. This principle was empirically groped by the developers of experimental personal computers, who without hesitation gave priority to action over the plan.
As Attardi [3] put it: “to see and act, and not to memorize and write”. Naturally, adherents of a strict approach perceive this as a heresy, but in reality this is a new phenomenon in programming that requires theoretical understanding and study.
The purpose of this note is to present a version of the theoretical model of the software environment in which the host programmer works. I call this model a transformational machine (TM). The machine supports various transformations (transformations) of “program-data” pairs into “a-data” program pairs. Properly arranged TM retains the functional invariant of the pairs being transformed, i.e. if (p ′, d ′) = t (p, d), where t is a transformation performed by the machine, then p ′ (d ′) = p (d).
Another important feature of the transformation machine is that it is built by the programmer himself. Its construction is a hierarchical structure, and following the E. Sandeval, A. Bers and P. Leonov, I will call the selected level of this hierarchy a context.
The context has a convertible pair (p, d) and a set of basic transformations, each of which performs an elementary (at this level) transformation of the pair (p, d) into another pair (p ′, d ′) while preserving the functional invariant. The basic transformations are divided into three categories - reductions, disclosures and conversions. Reductions deal with the interpretation of elementary (at this level) operations and predicates, disclosures reveal composite constructs, and conversions are schematic and combinatorial in nature. Examples of reductions are, for example, the replacement of a construction if it is true. Otherwise, B is all A or 3 + 5 by 8. An example of disclosure is the implementation of a procedure call by its open substitution, and an example of a conversion is the redistribution of memory or the saving of matching subexpressions.
What is important?
It is important that basic transformations can be applied freely. Their use in an arbitrary sequence does not violate the functional invariant of the pair to be transformed. This resolves the main difficulty: the programmer can do what he wants without fear of a mistake. This is not enough. Disclosures and conversions have a certain property of completeness. The completeness of reductions and disclosures allows us to find uniquely the normal forms of pairs (p, d), obtaining them as fixed points of the basic transformations.
If the functional invariant of the pair (p, d) is the constant c = p (d), then the normal form of this pair will be the pair (0, c) with a fully reduced program and with the calculated result in the data field. If the invariant of the pair (p, d) is
some function ϕ (y), then the normal form for (p, d) is a pair, the program component of which contains some
the residual program for ϕ, and the data component contains the name of the argument y and (maybe) some constants and the names of intermediate values.
Conversions may also have the property of completeness with respect to some schematic invariant or canonical form of the program and its data.
The hierarchy of contexts is achieved by the fact that finding fixed points of reductions or canonical forms of conversions is interpreted as an atomic act in the context of the next level, and basic context transformations are revealed by means of internal contexts. We also add that the transformation machine is a convenient concept for the implementation of abstract data types, in which the descriptions of types and operations are implemented by the disclosures, and the reductions and conversions correspond to axioms.
The fact that the hierarchy of contexts arises and is built at the will of the programmer allows him to fine-tune the software processor to the relationship between compilation, interpretation and direct calculation, making these distinctions movable, flexible and manageable.
Of course, the transformation rules invented by programmers cannot be arbitrary. The software monitor should embody and maintain some knowledge of functional dependency, the general rules of the compositional hierarchy, naming, control, and informational links. This general knowledge will allow at any level to support abstract invariants that guarantee the preservation of functional invariants.
The considerations outlined in this note develop the initial thesis in line with the transformational approach to programming. Its peculiarity is that the direction of manipulation with programs does not so much require pre-planning, but is determined by the prevailing situation.
The host programmer, however, will only be able to properly dispose of the freedom of action given to him, if he is well aware of the field for their use. A large and clear display screen is needed by a programmer just as a wide and clear windshield for a motorist. But if reality itself puts road signs and situations behind the windscreen, then for a system programmer you need to work a lot to turn the weak-eyed letters of alphanumeric displays into a compact and visual image of programs and data. I would like to draw the reader’s attention to some new principles of human-machine interaction put forward by so-called object-oriented languages, of which, first of all, it is necessary to single out the Smoltok language [5].
Returning once again to distinguishing the spirit of the forms of programming, it should be recognized that, relying finally on the same device - a computer, both forms of programming are mathematically quite translatable into each other. Nevertheless, both practical and theoretical, their distinction will help the cause, allowing to supply both categories of programmers with adequate operational tools, methodological guidelines and mathematical theories.
1. Bauer FL Programing as a contract. - In: “Infotech state of the art reports, Series 9, No.6. System Design. - Maidenhead: Pergamon Infotech, 1981, p. 167–174.
2. E.Sandewall. An environment for development and use of executable application models. - In: Records of the 2nd, Capri, May 3–7, 1982, p. 12 + 43p
3. Attardi G. Office information systems desing and implementation. - (Technical report) Cnet No.47. Instituto di Scienze dell'Informazione Univers. di Pisa, Pisa, 1980, 44p. + ii.
4. Ershov A.P. Mixed computation: potential applications and research problems. - In the book: Methods of Mathematical Logic in Problems of Artificial Intelligence and Systematic Programming. Abstracts of reports and messages. Part 2. In nadzag.: Institute of Mathematics and Cybernetics ANL SSSR. Vilnius, 1980, pp.26–55.
5. Ingalls DH The Smalltalk-76 programming system: design and implementation. - In: Proceedings of the 5th Annual ACM Symposium on Principles of Programming Languages, 1978.
1982
From the Ershov Archive [ source ]
Let us elaborate this thesis in more detail.
')
When I think of a programmer as a host, I mean that he programs for himself. Having all the resources, all the means (virtually or physically - it does not matter!) At his disposal, he is the sole and final judge of his actions and their results.
When I think of a programmer as a servant, it seems to me primarily as a communication channel that perceives the task specification presented to it. The responsibility of the programmer for the correctness of the specification is very limited, on the other hand he undertakes to diligently implement the adopted specifications and issue the product program to the client (for a one-time account or permanent use, it does not matter!).
Naturally, this distinction was noticed by many. F. Bauer [1] calls the work of a programmer-servant programming by contract. Accordingly, you can call the work of the programmer-host programming for yourself. E. Sandeval [2] develops a close approach, highlighting a group of "terminal" programmers. Sometimes this distinction is made using the terms professional and non-professional programming for the servant and master. Such an interpretation is permissible if we explore the social side of programming as an activity, for example, its professional ethics. If we talk about programming, bearing in mind its internal content, in this case, looking at the host programmer as an amateur can lead to misunderstandings.
The programmer-servant, in a certain (very deep) sense, does not know what the customer wants, and relies solely on the formulation of the problem. Of course, he is not illiterate, and may know a bunch of things about the subject area. He can provide invaluable services to the customer by finding many inconsistencies in his specifications. However, all this is beyond the plan. Its main and only business is to convert the specification into a reliable and effective result: a program or data.
This is the kind of programming that has been worked on the most and that dominated during the formation of programming. This work has led to the possibility of rigorously justifying each step of building a program, and this opportunity is undoubtedly the greatest achievement of computational science. The methodological principle of abstraction from the informative knowledge of the programmable task turned out to be very fruitful: it led to the development of generally significant and powerful methods of manipulating programs and reasoning about them, based on the schematic representation of the program in the uninterpreted signature of elementary operations and predicates.
Another aspect of programming, however, also existed all this time. Being rotated in the direction of the backyard of programming, he nevertheless gains "second wind" in connection with the emergence and development of personal computers. Moreover, a system programmer in his kitchen, lined with tool machines, often behaves like an owner. Such facilities as extensible languages, macroprocessors, rewriting systems, compile-time operations, universal editors, and much more have already accumulated in this farm. This assortment, however, has developed by chance and is not ordered either by a good theory or a reliable methodology. Only recently a collective term has emerged, under which, as a banner, non-compressed system programmers gather, the programming environment (programming environment), or - more deployed, but more precisely for the Russian language - the operating environment for building programs. To turn this fashionable word usage into a coherent methodology with a solid theoretical substantiation is an important and fascinating task of theoretical and system programming of the 80s.
The host programmer knows what he wants.
This is the fundamental methodological difference between contract programming and programming for oneself. This principle was empirically groped by the developers of experimental personal computers, who without hesitation gave priority to action over the plan.
As Attardi [3] put it: “to see and act, and not to memorize and write”. Naturally, adherents of a strict approach perceive this as a heresy, but in reality this is a new phenomenon in programming that requires theoretical understanding and study.
The purpose of this note is to present a version of the theoretical model of the software environment in which the host programmer works. I call this model a transformational machine (TM). The machine supports various transformations (transformations) of “program-data” pairs into “a-data” program pairs. Properly arranged TM retains the functional invariant of the pairs being transformed, i.e. if (p ′, d ′) = t (p, d), where t is a transformation performed by the machine, then p ′ (d ′) = p (d).
Another important feature of the transformation machine is that it is built by the programmer himself. Its construction is a hierarchical structure, and following the E. Sandeval, A. Bers and P. Leonov, I will call the selected level of this hierarchy a context.
The context has a convertible pair (p, d) and a set of basic transformations, each of which performs an elementary (at this level) transformation of the pair (p, d) into another pair (p ′, d ′) while preserving the functional invariant. The basic transformations are divided into three categories - reductions, disclosures and conversions. Reductions deal with the interpretation of elementary (at this level) operations and predicates, disclosures reveal composite constructs, and conversions are schematic and combinatorial in nature. Examples of reductions are, for example, the replacement of a construction if it is true. Otherwise, B is all A or 3 + 5 by 8. An example of disclosure is the implementation of a procedure call by its open substitution, and an example of a conversion is the redistribution of memory or the saving of matching subexpressions.
What is important?
It is important that basic transformations can be applied freely. Their use in an arbitrary sequence does not violate the functional invariant of the pair to be transformed. This resolves the main difficulty: the programmer can do what he wants without fear of a mistake. This is not enough. Disclosures and conversions have a certain property of completeness. The completeness of reductions and disclosures allows us to find uniquely the normal forms of pairs (p, d), obtaining them as fixed points of the basic transformations.
If the functional invariant of the pair (p, d) is the constant c = p (d), then the normal form of this pair will be the pair (0, c) with a fully reduced program and with the calculated result in the data field. If the invariant of the pair (p, d) is
some function ϕ (y), then the normal form for (p, d) is a pair, the program component of which contains some
the residual program for ϕ, and the data component contains the name of the argument y and (maybe) some constants and the names of intermediate values.
Conversions may also have the property of completeness with respect to some schematic invariant or canonical form of the program and its data.
The hierarchy of contexts is achieved by the fact that finding fixed points of reductions or canonical forms of conversions is interpreted as an atomic act in the context of the next level, and basic context transformations are revealed by means of internal contexts. We also add that the transformation machine is a convenient concept for the implementation of abstract data types, in which the descriptions of types and operations are implemented by the disclosures, and the reductions and conversions correspond to axioms.
The fact that the hierarchy of contexts arises and is built at the will of the programmer allows him to fine-tune the software processor to the relationship between compilation, interpretation and direct calculation, making these distinctions movable, flexible and manageable.
Of course, the transformation rules invented by programmers cannot be arbitrary. The software monitor should embody and maintain some knowledge of functional dependency, the general rules of the compositional hierarchy, naming, control, and informational links. This general knowledge will allow at any level to support abstract invariants that guarantee the preservation of functional invariants.
The considerations outlined in this note develop the initial thesis in line with the transformational approach to programming. Its peculiarity is that the direction of manipulation with programs does not so much require pre-planning, but is determined by the prevailing situation.
The host programmer, however, will only be able to properly dispose of the freedom of action given to him, if he is well aware of the field for their use. A large and clear display screen is needed by a programmer just as a wide and clear windshield for a motorist. But if reality itself puts road signs and situations behind the windscreen, then for a system programmer you need to work a lot to turn the weak-eyed letters of alphanumeric displays into a compact and visual image of programs and data. I would like to draw the reader’s attention to some new principles of human-machine interaction put forward by so-called object-oriented languages, of which, first of all, it is necessary to single out the Smoltok language [5].
Returning once again to distinguishing the spirit of the forms of programming, it should be recognized that, relying finally on the same device - a computer, both forms of programming are mathematically quite translatable into each other. Nevertheless, both practical and theoretical, their distinction will help the cause, allowing to supply both categories of programmers with adequate operational tools, methodological guidelines and mathematical theories.
1. Bauer FL Programing as a contract. - In: “Infotech state of the art reports, Series 9, No.6. System Design. - Maidenhead: Pergamon Infotech, 1981, p. 167–174.
2. E.Sandewall. An environment for development and use of executable application models. - In: Records of the 2nd, Capri, May 3–7, 1982, p. 12 + 43p
3. Attardi G. Office information systems desing and implementation. - (Technical report) Cnet No.47. Instituto di Scienze dell'Informazione Univers. di Pisa, Pisa, 1980, 44p. + ii.
4. Ershov A.P. Mixed computation: potential applications and research problems. - In the book: Methods of Mathematical Logic in Problems of Artificial Intelligence and Systematic Programming. Abstracts of reports and messages. Part 2. In nadzag.: Institute of Mathematics and Cybernetics ANL SSSR. Vilnius, 1980, pp.26–55.
5. Ingalls DH The Smalltalk-76 programming system: design and implementation. - In: Proceedings of the 5th Annual ACM Symposium on Principles of Programming Languages, 1978.
1982
From the Ershov Archive [ source ]
Source: https://habr.com/ru/post/282053/
All Articles