Reflections on programming

From Aristotle to Wittgenstein

I do not need a language that allows you to create good programs. I'm looking for a language in which you can’t write a bad program. Author

Foreword

The development of computer science as a science is represented by a river that is born in the distant past (Euclid, 3rd century BC; Babylon, 19th century BC; perhaps even earlier) from barely noticeable streams of the first algorithmic calculations. Moving slowly through history, small streams unite into a river, which, carrying its waters through the centuries, absorbs tributaries from related disciplines, accumulates grandeur and power, and finally falls down from the second to the third millennium of Niagara, turning into a swift swirling stream that captures and carries with it from the past to the future millions of people.


')
Brownian particle, which then throws on the rapids with a turbulent flow, then overturns into a stagnant swamp, then in shallow water, then into a pool; The world of information technology seems mysterious, changeable and unpredictable. However, the joy of constant movement, the heroic overcoming of difficulties, the frantic rotation of the kaleidoscope of new impressions eventually gives way to longing, longing for the spirit and the insurmountable need to rise for a moment over the bustle, look at this wildly raging stream and try to see if not the general direction of the turbulent river, then at least the closest turn of the channel in which you are wallowing.

Introduction

“If a scientist cannot popularly explain to an eight-year-old child what he does, then he is a charlatan”
Kurt Vonnegut, "Cat's Cradle", 1963

A. “There is no silver bullet,” said F. Brooks in the last century and for a long time cooled the ardor of noble knights from programming in the fight against the “Dragon of complexity”. Since then, “His Majesty the Dragon” has served as an excuse that users, instead of some poorly working programs, are imposed on more and more new ones, which are not much better, but devour more and more CPU and computer memory resources (“Why? People hawth!” ( c) B.Titamir). For the sake of Dragon, an entire army of code & fix programmers has been grown (“do and rework”): “Not by skill, but by number!”, “Refactoring is our everything!”, “Even members of the Republican Party can program!” their banners. To feed the Dragon, every day they create gigabytes of source code, much of which will never be claimed by users. Over the years, this hideous Dragon has grown and become “The Idea. Historical necessity. Our state interest. A powerful factor, a justification for our united efforts. ”

B. We are not going to look for another “silver bullet”, but not because there is none, but because, no matter how much we want, it’s hard to believe in dragons. Dragons, as a rule, are born in the minds of people when they are confronted with phenomena that are not explained in their previous experience. For computer science, the presence of white spots is not surprising because it is a very young branch of human knowledge.



Q. Few programmers believe in dragons, but many believe that complexity is a subjective concept. One of the definitions of the word “complex” is difficult, tangled. For example, a complex task, a complex (or maybe more precisely, confusing?) Program. What is difficult and confusing for one person may be easy and clear for another. The motion of the planets in the geocentric model of Ptolemy over cycles and epicycles with amendments to them looks complicated. The motion in the heliocentric model along Kepler ellipses is simple. If you edit images in a bit format, it will be difficult, and if in a graphic editor, it’s easy. An image of a Mandelbrot set can hypnotize its complexity to an uninitiated observer, but in an adequate language, the Mandelbrot set is described very simply: “the set of points with on the complex plane, for which the iterative sequence z ₀ = 0, z _n = z _n-1 ² + c ( _n = 1, 2, 3, ...) does not go to infinity. "

G. There is nothing difficult and confusing in nature. Something can only seem difficult and confusing to a person who is trying to understand something. Maybe we make the software systems we develop ourselves complex and confusing? Why in the ERP system SAP / R3 more than 50 thousand tables, and in the largest dictionary of the Russian language only about 54 thousand nouns? I sometimes feel sorry to be a charlatan, trying to explain to the customer why it is so difficult to add to the program the simple functionality that he asks for.

D. In this post I don’t set myself any tasks other than one - to write down my not very connected, but sometimes incomplete thoughts about the most common programming issues that I have been thinking about for the last twenty years. Time is inexorable and I simply may not have enough of it in order to collect all the necessary "stones" and put together a fairly solid foundation for a new programming paradigm. I will be satisfied if my thoughts turn out to be useful to someone, and maybe they will push someone from colleagues to go in search of the missing "stones."

Theses

“Every task becomes trivial if it is formulated in an adequate language. ” I. M. Gelfand

About programs

Program = task + model + algorithm + data structure

The program is created in order to solve a specific task: to provide control over the spacecraft during the flight to Phobos, recognize the criminal through a photo in a stream of people, receive an SMS message from one mobile phone and transfer it to another.

The model describes what the program should do to solve the problem, but not how it should do it. Created in human thinking (mental) domain models can relate both to real-world phenomena, for example, the movement of a space object in the gravitational field and the atmosphere of the Earth, as well as to ideal concepts, such as an online store. A model is a mental image of a future tool that will allow us to solve the problem posed.

The key concept in the definition of the program is the task . It is unreasonable to discuss the technical system in isolation from the task that it solves, so it is pointless to consider the program outside the goals for which it is created. To solve different problems, even in the same subject area, different models will be created and different programs developed. To calculate the trajectories of interplanetary flights, it suffices to simulate the gravitational field as a superposition of the point masses of the Sun and the planets. For practically acceptable accuracy of predicting the motion of satellites in near-Earth orbits in the gravity model, it is necessary to take into account the heterogeneity of the Earth's field in the form of an expansion in harmonic functions or a specially selected point mass system. And the solution of individual tasks of the global satellite navigation system (GLONASS / GPS) is impossible without using models of time and space from the General Theory of Relativity.

So, a program is a solution of the problem before us written in a language understandable to some computer.

Object Oriented Approach

Today, about 2,500 programming languages ​​have been created for recording programs. The history of their development is somewhat similar to the history of the development of human speech. There is an opinion that the content of the first statements of a person consisted solely of the requirements of assistance that could be provided to him by another individual. “If the first statements of a person becoming express with our developed language, they would necessarily contain verbs in the imperative mood:“ give ! ”,“ Carry ! ”,“ Break ! ”,“ Cut ! ”,“ Beat ! ”,“ lift ! ”,“ pull ! ”and so on.” Moreover, these commands were accompanied by gestures that indicated exactly what this action should be applied to. Well, very much like imperative programming language commands! For example, assembler commands with precise indication of memory addresses or registers.

A person first learns to distinguish one practical situation, taken as a whole, from another situation. Separate elements of these situations (objects, on which actions are performed, actions, which are performed on objects) are distinguished later - as in practical activity a person became more and more familiar with the things around him, learned their properties and their relations to each other and to to the man himself. Gradually, a person begins to select from an concrete situation an object of action (in programming, data) and the action itself (in programming, functions). Mastering the ability to isolate the objects of action was a real revolution in the mental development of primitive man. And this is very similar to the object-oriented approach (OOP) used in programming. At least in its modern implementation in languages: C ++, Java, C #.

With the help of natural language, a person materializes his mental models of the world in order to transfer them to another person. With the help of OOP, the programmer materializes his mental models of the software product in order to transfer them to execution to the calculator. But is the PLO really the main channel of our river? Or is it just a quiet backwater before a sharp turn, which is characterized by a slow and sometimes reverse flow of water and which has already begun to swamp?

The application of the PLO to the construction of mental models of the physical world has more than two thousand years of successful use history, which originated in the writings of Aristotle. In the world of Aristotle, there are only single and specifically defined things with a given set of properties and related to one and only one category.

Yes, now we have learned to say not just “ carry, ” but “ carry firewood ” or “ carry stone ”. In their development, programming languages ​​have settled on the fact that they have learned to distinguish objects ( firewood and stone ), but have not learned to distinguish actions on them. And from the point of view of the programming language men.carry (firewood) and men.carry (stone) are different language units, unless firewood and stone objects have a common ancestor! Simply implementing these “interface objects that a person can wear ” with these objects will not help us out, since these will be two implementations, and, therefore, there will also be two units of source code.



One of the main limitations of OOP, which makes our programs more difficult than they could be, is hidden here, forcing us to use crutches in the form of design patterns to compensate for the innate lameness of OOP. When we are trying to determine whether a particular software system design is suitable for us or not, we cannot consider this solution in isolation. We must consider it in terms of reasonable assumptions about how this design will be used in consequence. If we translate this thesis into the language of " firewood " and " stones ", then this will sound, approximately, as follows. When designing the “ firewood ” and “ stone ” software objects, we should be aware of the Lord’s plans for improving the software system. Namely, we must assume that He will not limit himself to making firewood and stones, but on the sixth day of the creation of the world he will create a person who will drag them.

About inheritance

Another limitation of OOP is that each object belongs to one and only one hierarchy (" is a ") of classes, even with the possibility of multiple inheritance and has once and for all a given set of properties. For example, a red rose is a flower, and a flower is a plant. This contradicts the reality in which objects can evolve, acquire new properties, and lose pre-existing ones. For example, a rose can be a commodity, and then a gift. What class heir should a rose present be? Rose-goods or rose-flower? Another example. A person is born with a very limited set of properties: to have age, weight, height, squeak, eat and spoil the diaper. As time goes by, he acquires new sets of properties: a student of a school, a buyer, a passenger, a soldier, a student, an employee, an entrepreneur, a spouse, a parent, etc. And perhaps not gaining. For example, not every person serves in the army, studies in high school, marries and becomes a father or an entrepreneur. Or loses. For example, he finished studying, served in the army or divorced. Consequently, the same object must be able to belong to different classes and this set of classes must be dynamic, i.e. change in the course of the evolution of the object and the software system itself. As a rule, restrictions are imposed on the set of classes to which the object belongs. For example. To become a soldier, a person must reach 18 years. And if a person is a student, in order to become a husband, you must pass the mat.

About messages

Another odd PLO: “Behavior is how an object acts and reacts; behavior is expressed in terms of the state of the object and the transmission of messages. But, wait, if I simulate a collision between two cars, which of them receives and sends messages?

About properties

"The state of an object is characterized by a list (usually static) of all the properties of a given object and the current (usually dynamic) values ​​of each of these properties." But does the property of the object belong to the object itself? I will argue that no. For example, we say this apple is green. But what does this really mean? This means that if we direct a light source close to the spectrum to sunlight, this apple will absorb all wavelengths except those that correspond to the green color range, and an observer who is able to perceive the entire spectrum of sunlight will see only reflected green light. If the source or observer has a different range, for example, infrared, then the color of the apple will be black. Thus, a property is not an integral characteristic of an object, but is a possible manifestation of an object when it interacts with other objects. For example, the property of an object “to float on the surface” may manifest itself in interaction with water and not manifest itself in interaction with alcohol.

About aggregation

We say: a mop "consists of" (aggregates) brushes and sticks. But what does this mean? If we consider a mop as an object capable of moving in space, then in this case the aggregation does not manifest itself in any way, we consider the mop as an atomic object and we are only interested in its total mass and dimensions. But if we load the mop and test it for strength, then the aggregation will manifest as the interaction of its structural components of the brush and stick and the result of the test will depend on whether this interaction occurs through hammered nails or by grooves, spikes and glue. Therefore, aggregation is also the interaction of objects.

About association

If we say that object (a) is the husband of object (b), then we declare that objects (a and b) are related by association. How can this connection be manifested? First, this connection itself is the result of the interaction of the three objects (a), (b) and the object (c) (Civil Registry Office, a certain registrar, where this connection is born, and there, by the way, it may disappear). Secondly, it can manifest itself in interactions of objects, for example, (a and b): the joint spending of the family budget or the birth and upbringing of a common child. It makes no sense to ask a.is Married (b), he may lie. But the function isMarried (a, b, c) is quite meaningful. Consequently, connections, like properties, are possible interactions between objects.

About identity

"Identity is a property of an object that distinguishes it from all other objects." What should really correspond to this statement? Suppose I repainted my car. For me, he certainly remained the same. But for the traffic police it will be a completely different object, which will receive a new state registration number. Another example. With the car removed the wheels. Did the car stay the same? And if the engine? And when will the car stop being the same? Identity arises only when binding specific objects. Each mop will consist of a very specific brush and stick. Each husband will have a very specific wife, and each client will have his own copy of a bank account.



So, in our mental world there are no objects and their properties. And there are structures and their interactions. If we simulate road traffic, then cars should be considered as elementary nodes of the structure that, entering into interaction (overtaking, cutting, braking), consistently change their coordinates in phase space (speed, position). On the other hand, cars cease to be elementary nodes of the structure as soon as we begin to consider their interaction in a collision. We must move to a lower structural level. At this level, the elementary units should be: bumper, body, frame, engine, and so on. components, as well as methods of their connection (bolts, welding, etc.). The fact of the allocation of a structure node is an act of cognitive activity (Gestalt theory), which depends on the problem being solved.

On the ontology of Ludwig Wittgenstein

The world of Wittgenstein is not the world of things as in Aristotle. If for Aristotle the essence of language is noun, then according to Wittgenstein the essence of language is sentence. Language, according to Wittgenstein, is not a set of names or properties, but consists of sentences in which the interactions of objects are expressed. In the world of Wittgenstein, facts are primary - interactions between objects, and things are determined by the totality of their possible interactions. Such a view of the world very well corresponds to the modern category theory, in which morphisms set the interaction of objects, and functors determine the evolution of the model over time.

In contrast to the static world of Aristotle, the world of Wittgenstein is dynamic. In the course of the evolution of the world facts can be added and the idea of ​​things will change. Thanks to this interpretation of the world, the thing appears not as something given, frozen, quite definite, but as some entity with fuzzy, changeable boundaries. Software systems dynamically evolve like Wittgenstein’s world. In the course of the development of the software system, developers add new potential interactions to objects, which expand their property sets and relationships.



Wittgenstein introduced the concept of "language game" - a single whole: the language and actions with which it is intertwined. “How many offer types are there? Let's say a statement, a question, a command? There are countless such types and endlessly diverse uses of all that we call "signs", "words", "sentences". And this multiplicity is not something sustainable, once and for all given ... ". Do we not play a similar language game when we describe a domain model using user stories?

About domain-specific language (Domain Specific Language, DSL)

It seems to me that in the future programming environments will mostly resemble CAD systems with embedded DSL. Software systems should be created by application specialists, for example, an engineer will assemble a software model for studying the flight characteristics of a new aircraft from a ready-made element base: fuselage, wings, engines, connecting mounts and models of their interaction with the incoming flow. Similarly, they will be assembled from ready-made components and business applications: accounting, logistics, warehouse, manufacturing, etc.

Does this mean that for each domain we need to create our own unique DSL? Yes and no. Yes, in the sense that almost all established areas of people's professional activity, for example, mathematics, medicine, biology, have their own specific language, so in each subject area we will have to create our own DSL to describe specific models for solving specific problems. No, because professional languages ​​are built on the basis of a single syntax of a natural language, and there should be a universal syntax for describing mental models based on the general laws of human thinking.

Attempts to create a universal DSL syntax were made more than once. I will list only the most notable of them: one and two . I don’t know examples of serious practical application of the proposed approaches. Maybe this is because they are trying to simulate the static world of the objects of Aristotle? It is quite possible that the dynamic world of Wittgenstein's interactions and the categorical approach, reflecting the fundamental features of our thinking, can form the basis for the universal syntax of DSL.

DSL like DNA should describe:

1. scenarios for assembling a model from finished components;
2. initialization of the initial state;
3. laws of model evolution over time.

The main building block of the language should be the interaction in which the properties of objects manifest, their states change and new instances are born. Each object in the course of evolution can be supplemented by a new set of potential interactions and this addition should not affect the previously created code. The appearance of a “ person ” in the world of “ stones ” and “ firewood ” with this approach will lead to the creation of a new interaction carry ( carrier, thing, space, gravitation ) ;. The carrier element must implement interactions: take (carrier, thing) and move (carrier, thing, space) . And the thing element should implement the interaction: weight (thing, gravitation) and shape (thing, space) . In this case, our model of action to bear will be quite universal. The method will not change from the fact that a person implements the interaction take hands, the animal - his teeth, and the crane - a special capture. Therefore, we can easily replenish our software system with any elements that implement the necessary interactions for the carrier, thing and we do not need to change our universal function. What could it be like? Perhaps, the future DSL will be similar to Mixin-technology or Anemic Domain Model (by the way, Martin Fowler called this model anti-pattern), or D. Knuth's “ verbal programming ”, where the narrative description of interactions will be interpreted as algorithms and data structures.

findings

Programming is a new kind of human activity that is mistakenly related to engineering.
Engineering is the area where the laws of natural sciences, mathematics, physics, and chemistry are applied to the design of new products. , , .

– , : , , , . - , . , , - .