The holy family of information technology (April theses in the form of critical criticism)
Pre-notification: This article is written in a sharp polemic. Practically everything in it is greatly exaggerated, brought to a logical and conceptual absurdity, and, in general, this is not an article, but one large unfolded remark, although, in connection with, but absolutely "not in the subject." Particularly impressionable readers can safely skip this article and find a more useful occupation. But, if, suddenly, someone has a response in his heart and an idea to create some kind of “start-up”, then I will be very happy (it will be very nice, though a tiny bit, to shift the developers' consciousness away from all the usual). That is why, I do not consider my article as an April Fools ’joke, although I would be very happy in some favorable way to play such a qualified community.
Imagine a developer who (in the distant, but "dashing" nineties) first encountered a rather tempting opportunity to create simple HTML pages. He thinks that, now, everything is simple: you type the text, insert tags into it (they are the same: commands) and save the result in a file on the working server, and the user gets what he, the user needs. The developer quickly realizes that it will be quite easy to implement an application that will interpret the HTML code, and ... creates the first browser. The idea of ​​interpreting something there is not new, the result is important here or, more precisely, the effect: the user requests a specific page, gets the prepared HTML code, the browser parses this code (according to its object model) and shows the final result to the user on the screen. Very impressive, right?
The developer does not particularly bother himself with questions that, in reality, the user needs and begins to invent all sorts of tags (they are the same commands): oblique, bold, setting the font, section title, list, etc. etc. The developer introduces the ability to create lists, insert pictures and ... hyperlinks (the ones for which “everything” is). The world in which the developer operates is simple and clear: the browser has only one window, and, therefore, the user has only one opportunity - to load a new page for yourself and see it all in the same single browser window. So, a “Back” button appeared in the browser (and the “Forward” button accompanying it, which is intended, as it were, to cancel the cancellation), the history of visits and the ability to bookmark the desired page.
In reality, such developers are not so, too, and few, and each of them strives to contribute to the creation of browsers. There are several browsers, and various companies are competing with each other on how best to display the contents of documents. Compatibility issues come to the fore, and page writers have to remember more and more things about how and what is displayed (or not displayed) in various browsers.
')
As long as WEB is static, you cannot do anything sensible in it. You can only put your product on the shop window and beautifully expand it there. But the user will only be a passive observer. Meanwhile, there is a desire to conduct your business through WEB, and for this you need somewhere to have program code that must be executed in response to user actions. A normal (local) application “carries” all its program code with itself (in an executable file), and in WEB the placement of the code turns out to be more complicated: the code can be located on the server side (and then the server should somehow receive commands from the user via the network) ), and can be located on the client’s side (and then this same code, which, of course, will waste processor time on the user's computer, should be located on the page itself). Awareness of this fact led, on the one hand, to the emergence of scripting languages ​​and embedding interpreters of such languages ​​into browsers, and, on the other hand, to the appearance in HTML of special tags designed to create data entry forms from the user. Further, the birth of XML took place, the ASP, JSON and REST technologies emerged ...
I will no longer bore the reader with a list of well-known facts, but I note that the basis of rapid growth in any field is precisely the simplicity that developers of the first versions of software products encounter. These happy developers initially deal with simple and visible objects. They still do not know what all this will result in later. They are not contained in any framework of any practical tasks. Their horizon is extremely narrowed. But, at the same time, a significant role is played by the element of novelty of technology. And this element provokes a very rapid development of technology. Some are trying to make a lot of money out of it. Others find a lot of interesting problems in the new area and achieve quite good results in solving them. Still others observe all this and describe this tumult of life on magazine pages ...
Imagine another, much more thoughtful developer. Such a developer is sure to ask himself the following questions:
Such a developer will not rush to conclusions, and, of course, will not rush to create their first browser. First of all, a thoughtful developer will definitely think about whether it is possible to use conventional “desktop” applications in WEB and what should be added to them in order to teach them how to work in a distributed environment. For example, what should the database application do if the data itself is on a remote server? Secondly, he will definitely think about what should be in the operating system itself so that the user can work correctly with a specific site. Moreover, the question of dividing the code into “client” and “server” will become a real headache for a thoughtful developer, and this pain will not cease until the developer finds a solution that is satisfactory in terms of both performance and security. and amenities. Finally, thirdly, a thoughtful developer will necessarily think about how WEB itself should be optimally organized, and what the operating system should be like, which can work with WEB.
Of course, a thoughtful developer will not have time to do anything. He, in general, will never have time to do anything. Everything that will be done will be done by many simple developers. And ... done.
What do we have as a result? What we have, then we have.
We have puff pie technology.
We have many very different options and means of implementation.
We have a lot of approaches to design, and, in general, the constant change of site design and approaches to
organizing data storage and organizing interaction.
We have the fragility of WEB, when the link given today becomes invalid tomorrow.
We have a situation where most of the WEB becomes invisible, because instead of static pages and full-text search, we have all sorts of dynamic applications. At the same time, the search engines for our requests return almost only informational garbage. As, however, the very infrastructure of the WEB, which, frankly, provokes a constant duplication (for the most part, we do not need) information. I'm not even talking about the fact that we have simply monstrous problems with the security of storing and transmitting data, and with all this, it becomes especially creepy because developers quite calmly allow themselves to produce unsafe products, knowing full well about their insecurity and demanding a fee for them! At the same time, the constant detection of vulnerabilities (in software products) has become for everyone an everyday background, and the user has less and less ways to control his own computers with each step of the software development industry, and the latter have completely ceased to be “personalized” ...
But! The world could be different. Why is he not the way you want? And how could the world that we think look better? And, most importantly, is this other world really "beautiful", and we are in vain amusing ourselves with illusions about some other "beautiful world"?
Let's start from the beginning. By the way, where is it, this is the very beginning? Here you have to act from different ends. Firstly, we have the pages themselves, that is, what is directly displayed to the user. Secondly, we have what is the source of data for the pages. Thirdly, we have what builds and delivers requests to the server, and what delivers the results of queries to the client. This is what is called, on the one hand. On the other hand, there is a question about how it should look as a whole: from the point of view of the user, from the point of view of the operating system, from the point of view of the network. The third aspect of the problem is what developers should (in fact) do, and how the software development industry should be organized. It is very tempting to start at the end and dissolve a long demagogy about software development, but we take ourselves in hand and, nevertheless, we will start from the very beginning, namely from the pages that are shown to the user.
Rolled text consists of blocks. Every WEB-page is also the result of the layout. Therefore, an arbitrary page in the WEB consists primarily of blocks. This means that before displaying on the page some text or a more complex object, you need to create a block for it. When you write the text, you compose a document, you are not interested in any blocks, but you know in advance that each element of your document will be in a certain block. A block is a part of the physical level of organization of a document, while you create a document, you work at a logical level, which contains specific paragraphs, sections, semantic selections, links, footnotes, formulas, drawings, graphs, etc., etc.
If the browser receives an already-built document, then it receives blocks, and you need to skip the source code of your document through the layout system to create these blocks. In this case, the browser should receive exactly the blocks themselves and only them, and already each block itself is responsible for its content. In essence, each block is a named channel for exchanging data. If the browser is limited only to work with these same blocks, then browsers will be easy to implement.
To some, this function may seem rather narrow for such an application as a browser, however, after some reflection, you can find quite a few tasks that the browser has to perform (besides, actually, the display). Firstly, it is necessary to ensure the primary processing of messages from the "mouse" and the keyboard. The user should be able to select a separate block (with the transfer of input focus to this block) and, for example, call the context menu associated with this block. The menu itself may provide, for example, saving operations on disk as a file (more precisely, as a document of a simple or complex structure) or printing to a printer (with or without a preview). Secondly, it is necessary to provide the ability to control the blocks. If the browser receives a list of blocks, and each block has its own type, the user can view the site not in the form of “funny pictures”, but in the form of a structure: here is a list of paragraphs, here is a list of illustrations, here is a list of formulas, and here is a base data. This means that the user always has the opportunity to use a fairly simple (if not primitive) subroutines to solve a huge variety of tasks. For example, you may want to take a certain set of pages of a certain site and take quite definite objects (blocks) from each page and make one document out of them and ... put it on some other site. Thirdly, it is necessary to be able to apply content filters and independently choose the necessary (at the moment) presentation of the same information. For example, if you are working with a forum, then you should have a choice: either you simply read the forum as a single stream of replicas (as one coherent document), or you review all the replicas one after the other (chronologically), or you you look only at one single line of conversation between two specific participants (and then it will be a linear flow again), or you see the whole conversation with everyone at once (and then they will use indents or some other means of displaying the replica hierarchy; here Also, it may be convenient to split the window into two parts, where in one part all source replicas and footnotes are shown, and in the other part - only response replicas: answering yourself, it is also convenient to make a footnote or quote a whole fragment, creating a lengthy footnote) . Thus, the browser has many different functions, but at the same time, it must be understood that the browser always deals only with blocks, and is not responsible for solving applied problems.
And here we immediately have a steady suspicion that the browser, in its essence, is not much different from the operating system. Each block is, in essence, an independent window, which has its own window function. If this is so, then there should be no differences between the construction of the user interface of any arbitrary operating system and WEB-application. This means that the same components of the user interface are always responsible for implementing the behavior on the client’s side, and therefore, for implementing the client-side code, everything that is needed is already in the operating system. Or should be. If, suddenly, to work with this site you need something fundamentally new, then, in this latter case, you, before starting to work with the site, must download the new software, but this download will be no different from any other installation of any other arbitrarily taken application that you install, for example, from disk. Remember how this happens in TeX: when you use, for example, a new font, before the start of the layout, calculations are performed (using the special subroutine METAFONT), after which all your documents using the new font will already look correct. (The example with the font should not be taken only literally. In a real situation, the "font" can also be understood as program code, which, like the font, can be ordered and distributed in a certain way to certain logical positions, each of which has fixed semantics.)
(Here, however, another question arises - what could be so specific on the site, which cannot be already implemented in the operating system itself? - but we will leave this question to the very end of the article. This is a very important question, and we still need to prepare well.)
What has been said above is intended to show that even creating a simple page with simple text requires certain layers, and these layers directly control how you interact with the contents of the document. Some blocks are add-ons over the logical structure of the document. Other blocks are responsible for accessing functions and operations and must be added by the end user interface components. The third blocks are responsible for the design. Depending on the selected task and the specific intentions of the user, the composition of the blocks will also change. If you are just reading the text, then it is one; if you want to be able to get any explanations and inquiries about ... then it will be different, finally, if you want to edit the text, the composition of the blocks will be the third. Finally, if you are dealing with dynamic content, then ... Are there too many options?
Have you ever thought about what you expect to get by installing this or that operating system (OS) on your computer? In theory, you should get out of the box a turnkey system that is completely ready for operation. You can expect that the OS has all the necessary tools for this. Meanwhile, in reality, something else happens: first you install the OS, and then you install the applications you need. Why are you doing this? No, of course, you have to do it. You do it for a reason. If you are a writer, then you need specialized tools to prepare your future publications. If you are an artist or designer, then you need special tools that automate drawing or design. If you are a software developer, you need compilers and development environments. You all use this or that general-purpose OS and choose for yourself and install the software you need. But ... You only imagine what will happen if you do not need to do this! Of course, I do not propose to get rid of this, it is absolutely impossible. I propose to look at the same question from a different angle and ... see the real problem.
Let's start our "abstract" reasoning from the applications themselves. Each such application is a monolithic construction. It can be said: “this is historically the case” Yes, that's how it is. And now, ask yourself the question: what is in this application that there is something that can not be in the OS itself? Each application usually works with files of a certain format, therefore the main typical operations of this application are the processing of files (of the appropriate format): opening, loading, editing and saving. If the OS is a complete system designed to manage operations, then typical file operations should be an integral part of the OS itself. “Installing” the application we need, we, in fact, tell the OS a specific way of processing files of a certain format, and the OS provides a single (and, also, common software) interface for accessing files for files of all conceivable formats. In fact, the OS should independently create in its depths some kind of software object (we will conditionally call objects intended for solving application tasks at the “application level” as software objects), which is something like a resource shared between the OS and this application. A program object can also be called a document, but, as it is not called, the essence of a program object remains unchanged: program objects are created, as it were, “inside” the application, but are managed by the OS. Each application thus turns out to be a document factory, providing the OS with a description (specification) of the format of the documents being processed, and already the OS takes on the main functions of creating a user interface. In turn, the OS provides each application with its own environment, which is determined by the type of the application itself and the task that the user is currently solving. This approach allows you to compare the OS with a database where all data is stored in an orderly manner, and access to it is carried out using a certain query language. Unfortunately, the "solidity" of applications significantly hinders the implementation of this approach.
Imagine that applications are not monolithic. What does this mean? Normally, the OS loads the application being launched into RAM and gives it control. Do whatever you want! But, first, each application is not a “spherical horse in a vacuum,” it is an entity intended to solve certain problems. In this sense, each application must “lie” in the OS on a certain “shelf”. If the OS is perceived as a database, then this database should have something like a reference book “Nomenclature” containing, in essence, a full-fledged thesaurus or a registry of concepts, and then each application will be tied to a certain position of this reference book. Secondly, each application should be perceived as a set of interrelated and interconnected components, each of which must also be controlled by the OS. Accordingly, having a certain pool of components installed in the OS, we can assemble new applications (new combinations of components) to solve new problems. If the program code is stored in the OS in some tables, then we can create the applications we need, composing well structured queries to the database of program code and receiving the final code in the form of an ordered sample of instructions. Thirdly, each “monolithic” application is delivered “as is” (as an executable file or as a compiled package), and we have no way to extract its source code from an application (this is what Sergey Tarasov in his book Soft Engineering from the inside "called" hopeless programming "), if, of course, the developers of this application did not provide (SUDDENLY) this happy opportunity. If applications were developed strictly according to the component model, then we could always switch to the “master” mode in the application we are interested in, decompose, go to the component level, extract the initial component of any component we need, make corrections to it, automatically save changes as a new version and use the new version along with the old one. (Yes, it is fundamentally at variance with the common practice of hiding source code, creating special protection against hacking.)
What has been said above makes us come to a definite conclusion: the OS should be something like a DBMS that manages different types of databases — a code database, an application database, and a user database containing the final data that users deal with. Each application makes a certain contribution to each of the listed databases and, in fact, is itself something of a database. Accordingly, the installation, operation and destruction of the application are, therefore, transactions carried out in different databases. And here we come to a very important question: where, here, is the code specific to this application? Another version of the same question: in what form should the source code of this application be supplied (for the OS)?Is not, here, the best approach, the application of which each installed application must be represented (and supplied by the developer) in a declarative form (and only in it) so that the compilation is done only when installing this application in the OS? A positive answer to this question leads to several important consequences. First, the OS can (and should be) initially provided for all the main types of interaction and implemented typical tasks. This means that any program code installed from the OS should initially be tied to predefined typical tasks. Secondly, standard operations and standard interactions imply a rather formalized and well-automated scheme for creating a user interface. And this meansthat no application will need to take on the implementation of, in fact, the same functions associated with the opening of various dialog boxes. Thirdly, with ready-made declarations and working components, you can create new applications, delivering new declarations and new components to your employees or interlocutors. In part, this is reminiscent of the “1C” application, which SUDDENLY would become a full-fledged OS. Indeed, briefly describing everything that we have described above, it turns out that the OS as a technology platform supports certain “configuration objects”, the configurations themselves describe the user data processing model, and at some point in time is used (running and functioning) one configuration that determines the appearance of the desktop, the functions available on it, etc.associated with the opening of various dialog boxes. Thirdly, with ready-made declarations and working components, you can create new applications, delivering new declarations and new components to your employees or interlocutors. In part, this is reminiscent of the “1C” application, which SUDDENLY would become a full-fledged OS. Indeed, briefly describing everything that we have described above, it turns out that the OS as a technology platform supports certain “configuration objects”, the configurations themselves describe the user data processing model, and at some point in time is used (running and functioning) one configuration that determines the appearance of the desktop, the functions available on it, etc.associated with the opening of various dialog boxes. Thirdly, with ready-made declarations and working components, you can create new applications, delivering new declarations and new components to your employees or interlocutors. In part, this is reminiscent of the “1C” application, which SUDDENLY would become a full-fledged OS. Indeed, briefly describing everything that we have described above, it turns out that the OS as a technology platform supports certain “configuration objects”, the configurations themselves describe the user data processing model, and at some point in time is used (running and functioning) one configuration that determines the appearance of the desktop, the functions available on it, etc.delivering new declarations and new components to your employees or interlocutors. In part, this is reminiscent of the “1C” application, which SUDDENLY would become a full-fledged OS. Indeed, briefly describing everything that we have described above, it turns out that the OS as a technology platform supports certain “configuration objects”, the configurations themselves describe the user data processing model, and at some point in time is used (running and functioning) one configuration that determines the appearance of the desktop, the functions available on it, etc.delivering new declarations and new components to your employees or interlocutors. In part, this is reminiscent of the “1C” application, which SUDDENLY would become a full-fledged OS. Indeed, briefly describing everything that we have described above, it turns out that the OS as a technology platform supports certain “configuration objects”, the configurations themselves describe the user data processing model, and at some point in time is used (running and functioning) one configuration that determines the appearance of the desktop, the functions available on it, etc.that the OS as a technology platform supports certain “configuration objects”, the configurations themselves describe the user data processing model, and at any given time one configuration is used (running and functioning) that determines the appearance of the desktop, the functions available on it, and so on. d.that the OS as a technology platform supports certain “configuration objects”, the configurations themselves describe the user data processing model, and at any given time one configuration is used (running and functioning) that determines the appearance of the desktop, the functions available on it, and so on. d. etc.
... And here we have a question: are these notorious components not analogous to those blocks that we talked about earlier in relation to the WEB-pages?
If you write some simple program, you design it in the form of a simple procedure. Usually, it is enough to carefully read the program code of this procedure once to understand what it does. Especially if you write, adhering to a certain (always the same) style. You can see that some code snippets are of independent significance, and you may be tempted to arrange these snippets as separate procedures. By creating a new function block and giving it a name, you become a hostage once the decision is made. It's one thing if this is your code, then you can write a new procedure. Another thing is if it is not your code, and then you can make (if possible) your version of this function, or you will have to be content with what you have.
As long as we adhere to the procedural approach, everything remains within certain limits. But, as soon as you need to use a developed user interface, everything becomes much more complicated. First, the user interface components appear. Secondly, the components themselves have events, and you need to handle these events somewhere. Thirdly, you are limited, in essence, by the method of building components that is used in your development tool. The appearance of components, in fact, leads to the fact that the code is “blurred” between components, and this significantly complicates the study of the source code of the application.
Here, however, we are waiting for one big problem, which is sometimes talked about, but, somehow, really, very casually. The question is what exactly to consider as a component, and where, specifically, the logic of the component should be described. If we formulate the problem extremely briefly, then we can say this: who should be responsible for processing the message from the component? In fact, this is a key issue in building any software architecture! It turns out that to implement an arbitrary component it is necessary to have at least three objects: one object describes the external (user) interface, and initial events occur in this object; the second object sets the internal (software) interface and performs the primary event handling of the first object; The third object already performs specific actions. In fact,The logic of the component is implemented in the third object, which can be perceived as a controller (if you use the terminology of MVC). Attempting to implement a ready-to-use visual component is a mistake. For example, you can try to implement the [Calendar] component (as it is done) based on a tabular visual component, but a tabular view is just a view, and a calendar, in its essence, is a set of certain functions and, in a sense, a certain data type. You should not try to create a new component, but connect (that is, bind) already existing components with data objects. With this approach, you simply specify the data model and the internal (program) interface to the visual component. Something like an Occam's razor works here,which does not allow the tree of visual components to grow too large. If, however, it is assumed that in this way it is possible to handle, in general, any components, not necessarily visual, but, let's say, components as such, assuming some generalized component programming method, then you can implement a unified scheme for building applications from components. Thus, the component approach forces us to always create some layer of special interface objects that translate events occurring in some components into actions performed by other components. By linking the components into chains, we, in fact, describe some fragment of a large system, and the language for describing these components, together with the connections between the components, will be the very same modeling language that many people think about.
Imagine some program code in the form of a sequence of instructions. In the normal situation, this code, executed in the form of a procedure, is once compiled into code that is executed directly by the processor. If there is an object behind each variable, and each operation is overloaded, then we can run the procedure, so to speak, at idle and reproduce the syntax tree built for this procedure. This means that you can, before performing real calculations with real data, prepare the structures you need. In other words, you automatically have an additional layer of program objects that will be responsible not only for processing the data itself, but, for example, for keeping the event log, for converting data from one form to another,for managing the user interface and for restricting access to certain functions. With this intermediate layer, you can, having a ready-made application, save it ... as source code. But what seems to be especially important here, you get the opportunity to write all your programs, adhering to a strict procedural approach. And, if, for example, you implement some computational algorithm that requires input of any parameters, then you should arrange it just as data input, but not describe the input itself in any way: the intermediate layer of objects will perform the necessary binding of the input data with input fields or with the file selection dialog. Thus, the component approach allows you to reuse the same program code, while, depending on the context, the result of this code will be different,and the calculations that will actually be performed when processing the final (user) data may differ from the previously specified ones, because, as a result of "intermediate" calculations, instead of some generalized algorithm specified in the source code, a specific implementation was inserted, which is determined by the current configuration of the application.
It would be extremely tempting to “mathematize” programming in some suitable way and consider some semblance of a scalar product. The meaning of the analogy is to define a certain space and define in it multiplication operations (interaction of two objects) and addition (concatenation or merging of results). Then, the scalar product operation could describe a fairly wide range of phenomena. And where is the scalar product, there is the Gramm-Schmidt orthogonalization process. Here we need the concept of linear independence. Having a system of linearly independent "vectors", we can go to an orthonormal system, and the scalar product in an orthonormal basis is described extremely simply. This is the simplicity you should strive for when creating software.
What does orthogonalization mean for data? The fact is that any entity manifests itself in different ways in different circumstances. This means that the same real-world object appears in different roles in different interactions. Therefore, for each such type of interaction, you need to create your own program object. But each such object (or object class) will be processed using its own separate component. By separating different types of control flows, we, in fact, provide the developer with the opportunity to write the most generalized code.
What does orthogonalization mean for operations? This means that you can always arrange convenient access to all operations, you can create lists of operations by type, maintain a separate database for operations, and that seems to me particularly important, we have the opportunity to code operations on objects in one way and do this code part of the physical representation of the program code. Recall FORTH with his idea of ​​representing programs as bundles of recursive functions. If you have a table of functions (operations), then ... You can literally solve any task using the construction of finite automata (according to Shalyto), but this possibility should, in theory, be built in the OS!
Comparison of programming with the process of layout of complex documents seems to be very significant. It is usually assumed that the source code of the program is written first (in any programming language), and then this code is translated into the code of the target machine. (There is also an important intermediate representation in the form of so-called “byte-code”, but this is not the
point now.) There are two problem points here.
On the one hand, any complex software should be presented not in the form of its source code, but in some special form; in this sense, the source code of any application should not be a code in some programming language, but something like a database. In fact, the development environment should not be a simple source code editor with advanced functions, but a document-oriented system that allows, for example, to keep some sort of “accounting”. If you perceive each action in such an environment as an operation with a certain “account”, then the “programming” of a complex corporate system will consist in replenishing certain “accounts” with the subsequent compilation of a “report”, while various types of “reports” will answer different tasks for example, the documentation of the designed system can also be considered a kind of "report"). (It is to this,in my opinion, as a result, serious developers of large corporate systems come. But this approach, unfortunately, does not become a “common place.”)
Here it is important that the application, at first, is always in a project state, which means that the program code (in the final programming language) is only the final result of the developer’s work, and even before this program code (needed only when real product exploitation) will be completely ready, the developer has quite a lot of work, and the first release can only appear when the customer and the performer, sitting at the same development tool, can finally “hit their hands” and press the cherished “red w "button (which may be referred to, for example," New Release "). This, again, greatly brings together the creation of software and the layout of documents: you write the “source code” and, just before printing, skip the created “code” through the layout system. Of course, you can constantly check intermediate results,but sometimes it happens if you, for example, write an article for a collection, you send only the “source code” to the editorial board.
On the other hand, the question arises about the relationship between procedural and declarative approaches. It is difficult to do without a practical example and explain the essence of the question "in words." If we could use various declarations quite widely, then ... we would use only them, for example, to transmit data over the network. (Is it not for this that XML was created at the time?). Receiving only declarations, the OS could compile a native code for itself according to a given declaration. (And it would be safe!) In this sense, the OS can be perceived as a hierarchy of languages, which means that the OS should have built-in tools for building translators, but then the question will not be put the way it is put today - what language to choose programming and development environment, but in the opposite way: which programming language should be created,to optimally solve problems of a certain type. I still do not know this, but it seems to me that functional programming can bring clarity in answering this question, and future discoveries in the field of creating some kind of three-dimensional memory (where the same data can be placed in a huge number of ways depending on the task, they will solve the issues of speed of the so-called. “Lazy calculations”, which seem extremely promising because they are conceptually transparent and conclusively accurate. Next - to error-free programming!Three-dimensional memory (where the same data can be placed in a huge number of ways, depending on the task) will solve the speed problems of the so-called. “Lazy calculations”, which seem extremely promising because they are conceptually transparent and conclusively accurate. Next - to error-free programming!Three-dimensional memory (where the same data can be placed in a huge number of ways, depending on the task) will solve the speed problems of the so-called. “Lazy calculations”, which seem extremely promising because they are conceptually transparent and conclusively accurate. Next - to error-free programming!
Why does everything happen the way it does?
For a start, there is an economic explanation. The time required for detailed thinking and implementation of a complete multifunctional and secure solution is not. All you need is "here and now." As a result, the winners are the companies that were the first to stake out the scope of work for themselves. If you make, one day, a product that truly automates a certain activity, you will leave future generations without bread.
“Politics is a concentrated economy”, and therefore, in order to spread its influence in time and space, one must always maintain one’s own value for the user. And if practical problems are solved more easily, if there is a way to streamline them somehow, if there is an opportunity to automate typical operations once and to design applications on the fly to solve current user tasks, then ... why do we need numerous software development companies?
And what is a "concentrated policy"? Right!The science! And what can science tell us? I want to remind the interested reader that the initial idea of ​​the hyperlink was not to make the transition from one document to another possible, but to create an inseparable link between two documents, so that we could use another document while looking at one document. . Hyperlinks, in their essence, are needed in order to be able to reflect the dynamic nature of changes of the whole WEB as a whole. This means that when you open a single document, you have the opportunity to automatically upload information that relates to the subject of interest. What has only recently been reported as a kind of achievement (JSON and REST) ​​should have initially been the foundation of all distributed data storage technology. But for the realization of this information "paradise" it would be necessary to understandthat: firstly, WEB should be a large distributed knowledge base (which means that the basis should be based on the ideas of hierarchical distributed semantic databases, and where ordinary relational databases would occupy their honorable, but, nevertheless, subordinate "intermediate "Position); secondly, for the functioning of this system, it is necessary not to minimize traffic (as is usually done), but to establish a permanent exchange of data, make it regular (which means that no DDoS attacks, in particular, will be impossible, since it will be impossible to “just so "make a request for a particular page, you can only request some specific information); thirdly, for WEB users should be presented as a large Wikipedia, where each page has a history of edits, you can always create a discussion or take part in editing.In a word: such a WEB is similar to the real world, where there can be no “broken” links, users deal with documents, each document has its own history, etc. etc. Yes Yes. Dreaming is not bad, is it?
Why did I write this article?
First, I decided to tidy up my own thoughts a bit and try to put them together in a coherent way. Connected to explain failed. Is to blame.It turned out several disparate scenes and episodes. The idea is that here, in this article, reminiscent of an iceberg, on which my wild imagination stumbled, several blanks were buried for quite decent articles that you can, and generally speaking, should write here in Habrahabr.
Secondly, I tried to outline for myself the circle of my own interests and determined for myself the area of ​​my searches. It would be extremely interesting for me to develop flexible software systems based on the component approach (which must be worked out!), To search for non-standard ways of implementing generalized programming and to solve the fascinating problem of the correlation of procedural and declarative principles in programming.
Third, ... but maybe everything is already there? Is everything already invented? Everything you need already exists? Well, then I will be glad to hear about it from others and I can immediately take up the solution of real problems. And then, believe me, there will be a lot of reasons to write about what I did along the way ...
As it was once said: "do not talk about how you work hard and hard, tell us better about what you have achieved."
Exposure: two types of developers
Imagine a developer who (in the distant, but "dashing" nineties) first encountered a rather tempting opportunity to create simple HTML pages. He thinks that, now, everything is simple: you type the text, insert tags into it (they are the same: commands) and save the result in a file on the working server, and the user gets what he, the user needs. The developer quickly realizes that it will be quite easy to implement an application that will interpret the HTML code, and ... creates the first browser. The idea of ​​interpreting something there is not new, the result is important here or, more precisely, the effect: the user requests a specific page, gets the prepared HTML code, the browser parses this code (according to its object model) and shows the final result to the user on the screen. Very impressive, right?
The developer does not particularly bother himself with questions that, in reality, the user needs and begins to invent all sorts of tags (they are the same commands): oblique, bold, setting the font, section title, list, etc. etc. The developer introduces the ability to create lists, insert pictures and ... hyperlinks (the ones for which “everything” is). The world in which the developer operates is simple and clear: the browser has only one window, and, therefore, the user has only one opportunity - to load a new page for yourself and see it all in the same single browser window. So, a “Back” button appeared in the browser (and the “Forward” button accompanying it, which is intended, as it were, to cancel the cancellation), the history of visits and the ability to bookmark the desired page.
In reality, such developers are not so, too, and few, and each of them strives to contribute to the creation of browsers. There are several browsers, and various companies are competing with each other on how best to display the contents of documents. Compatibility issues come to the fore, and page writers have to remember more and more things about how and what is displayed (or not displayed) in various browsers.
')
As long as WEB is static, you cannot do anything sensible in it. You can only put your product on the shop window and beautifully expand it there. But the user will only be a passive observer. Meanwhile, there is a desire to conduct your business through WEB, and for this you need somewhere to have program code that must be executed in response to user actions. A normal (local) application “carries” all its program code with itself (in an executable file), and in WEB the placement of the code turns out to be more complicated: the code can be located on the server side (and then the server should somehow receive commands from the user via the network) ), and can be located on the client’s side (and then this same code, which, of course, will waste processor time on the user's computer, should be located on the page itself). Awareness of this fact led, on the one hand, to the emergence of scripting languages ​​and embedding interpreters of such languages ​​into browsers, and, on the other hand, to the appearance in HTML of special tags designed to create data entry forms from the user. Further, the birth of XML took place, the ASP, JSON and REST technologies emerged ...
I will no longer bore the reader with a list of well-known facts, but I note that the basis of rapid growth in any field is precisely the simplicity that developers of the first versions of software products encounter. These happy developers initially deal with simple and visible objects. They still do not know what all this will result in later. They are not contained in any framework of any practical tasks. Their horizon is extremely narrowed. But, at the same time, a significant role is played by the element of novelty of technology. And this element provokes a very rapid development of technology. Some are trying to make a lot of money out of it. Others find a lot of interesting problems in the new area and achieve quite good results in solving them. Still others observe all this and describe this tumult of life on magazine pages ...
Imagine another, much more thoughtful developer. Such a developer is sure to ask himself the following questions:
- What is the difference between WEB applications and ordinary desktop applications?
- What should be the software infrastructure supporting work with WEB-applications?
- What does the user really need?
Such a developer will not rush to conclusions, and, of course, will not rush to create their first browser. First of all, a thoughtful developer will definitely think about whether it is possible to use conventional “desktop” applications in WEB and what should be added to them in order to teach them how to work in a distributed environment. For example, what should the database application do if the data itself is on a remote server? Secondly, he will definitely think about what should be in the operating system itself so that the user can work correctly with a specific site. Moreover, the question of dividing the code into “client” and “server” will become a real headache for a thoughtful developer, and this pain will not cease until the developer finds a solution that is satisfactory in terms of both performance and security. and amenities. Finally, thirdly, a thoughtful developer will necessarily think about how WEB itself should be optimally organized, and what the operating system should be like, which can work with WEB.
Of course, a thoughtful developer will not have time to do anything. He, in general, will never have time to do anything. Everything that will be done will be done by many simple developers. And ... done.
What do we have as a result? What we have, then we have.
We have puff pie technology.
We have many very different options and means of implementation.
We have a lot of approaches to design, and, in general, the constant change of site design and approaches to
organizing data storage and organizing interaction.
We have the fragility of WEB, when the link given today becomes invalid tomorrow.
We have a situation where most of the WEB becomes invisible, because instead of static pages and full-text search, we have all sorts of dynamic applications. At the same time, the search engines for our requests return almost only informational garbage. As, however, the very infrastructure of the WEB, which, frankly, provokes a constant duplication (for the most part, we do not need) information. I'm not even talking about the fact that we have simply monstrous problems with the security of storing and transmitting data, and with all this, it becomes especially creepy because developers quite calmly allow themselves to produce unsafe products, knowing full well about their insecurity and demanding a fee for them! At the same time, the constant detection of vulnerabilities (in software products) has become for everyone an everyday background, and the user has less and less ways to control his own computers with each step of the software development industry, and the latter have completely ceased to be “personalized” ...
But! The world could be different. Why is he not the way you want? And how could the world that we think look better? And, most importantly, is this other world really "beautiful", and we are in vain amusing ourselves with illusions about some other "beautiful world"?
Development
Let's start from the beginning. By the way, where is it, this is the very beginning? Here you have to act from different ends. Firstly, we have the pages themselves, that is, what is directly displayed to the user. Secondly, we have what is the source of data for the pages. Thirdly, we have what builds and delivers requests to the server, and what delivers the results of queries to the client. This is what is called, on the one hand. On the other hand, there is a question about how it should look as a whole: from the point of view of the user, from the point of view of the operating system, from the point of view of the network. The third aspect of the problem is what developers should (in fact) do, and how the software development industry should be organized. It is very tempting to start at the end and dissolve a long demagogy about software development, but we take ourselves in hand and, nevertheless, we will start from the very beginning, namely from the pages that are shown to the user.
Episode # 1: TeX for WEB
Rolled text consists of blocks. Every WEB-page is also the result of the layout. Therefore, an arbitrary page in the WEB consists primarily of blocks. This means that before displaying on the page some text or a more complex object, you need to create a block for it. When you write the text, you compose a document, you are not interested in any blocks, but you know in advance that each element of your document will be in a certain block. A block is a part of the physical level of organization of a document, while you create a document, you work at a logical level, which contains specific paragraphs, sections, semantic selections, links, footnotes, formulas, drawings, graphs, etc., etc.
If the browser receives an already-built document, then it receives blocks, and you need to skip the source code of your document through the layout system to create these blocks. In this case, the browser should receive exactly the blocks themselves and only them, and already each block itself is responsible for its content. In essence, each block is a named channel for exchanging data. If the browser is limited only to work with these same blocks, then browsers will be easy to implement.
To some, this function may seem rather narrow for such an application as a browser, however, after some reflection, you can find quite a few tasks that the browser has to perform (besides, actually, the display). Firstly, it is necessary to ensure the primary processing of messages from the "mouse" and the keyboard. The user should be able to select a separate block (with the transfer of input focus to this block) and, for example, call the context menu associated with this block. The menu itself may provide, for example, saving operations on disk as a file (more precisely, as a document of a simple or complex structure) or printing to a printer (with or without a preview). Secondly, it is necessary to provide the ability to control the blocks. If the browser receives a list of blocks, and each block has its own type, the user can view the site not in the form of “funny pictures”, but in the form of a structure: here is a list of paragraphs, here is a list of illustrations, here is a list of formulas, and here is a base data. This means that the user always has the opportunity to use a fairly simple (if not primitive) subroutines to solve a huge variety of tasks. For example, you may want to take a certain set of pages of a certain site and take quite definite objects (blocks) from each page and make one document out of them and ... put it on some other site. Thirdly, it is necessary to be able to apply content filters and independently choose the necessary (at the moment) presentation of the same information. For example, if you are working with a forum, then you should have a choice: either you simply read the forum as a single stream of replicas (as one coherent document), or you review all the replicas one after the other (chronologically), or you you look only at one single line of conversation between two specific participants (and then it will be a linear flow again), or you see the whole conversation with everyone at once (and then they will use indents or some other means of displaying the replica hierarchy; here Also, it may be convenient to split the window into two parts, where in one part all source replicas and footnotes are shown, and in the other part - only response replicas: answering yourself, it is also convenient to make a footnote or quote a whole fragment, creating a lengthy footnote) . Thus, the browser has many different functions, but at the same time, it must be understood that the browser always deals only with blocks, and is not responsible for solving applied problems.
And here we immediately have a steady suspicion that the browser, in its essence, is not much different from the operating system. Each block is, in essence, an independent window, which has its own window function. If this is so, then there should be no differences between the construction of the user interface of any arbitrary operating system and WEB-application. This means that the same components of the user interface are always responsible for implementing the behavior on the client’s side, and therefore, for implementing the client-side code, everything that is needed is already in the operating system. Or should be. If, suddenly, to work with this site you need something fundamentally new, then, in this latter case, you, before starting to work with the site, must download the new software, but this download will be no different from any other installation of any other arbitrarily taken application that you install, for example, from disk. Remember how this happens in TeX: when you use, for example, a new font, before the start of the layout, calculations are performed (using the special subroutine METAFONT), after which all your documents using the new font will already look correct. (The example with the font should not be taken only literally. In a real situation, the "font" can also be understood as program code, which, like the font, can be ordered and distributed in a certain way to certain logical positions, each of which has fixed semantics.)
(Here, however, another question arises - what could be so specific on the site, which cannot be already implemented in the operating system itself? - but we will leave this question to the very end of the article. This is a very important question, and we still need to prepare well.)
What has been said above is intended to show that even creating a simple page with simple text requires certain layers, and these layers directly control how you interact with the contents of the document. Some blocks are add-ons over the logical structure of the document. Other blocks are responsible for accessing functions and operations and must be added by the end user interface components. The third blocks are responsible for the design. Depending on the selected task and the specific intentions of the user, the composition of the blocks will also change. If you are just reading the text, then it is one; if you want to be able to get any explanations and inquiries about ... then it will be different, finally, if you want to edit the text, the composition of the blocks will be the third. Finally, if you are dealing with dynamic content, then ... Are there too many options?
First lyrical digression (long)
Have you ever thought about what you expect to get by installing this or that operating system (OS) on your computer? In theory, you should get out of the box a turnkey system that is completely ready for operation. You can expect that the OS has all the necessary tools for this. Meanwhile, in reality, something else happens: first you install the OS, and then you install the applications you need. Why are you doing this? No, of course, you have to do it. You do it for a reason. If you are a writer, then you need specialized tools to prepare your future publications. If you are an artist or designer, then you need special tools that automate drawing or design. If you are a software developer, you need compilers and development environments. You all use this or that general-purpose OS and choose for yourself and install the software you need. But ... You only imagine what will happen if you do not need to do this! Of course, I do not propose to get rid of this, it is absolutely impossible. I propose to look at the same question from a different angle and ... see the real problem.
Let's start our "abstract" reasoning from the applications themselves. Each such application is a monolithic construction. It can be said: “this is historically the case” Yes, that's how it is. And now, ask yourself the question: what is in this application that there is something that can not be in the OS itself? Each application usually works with files of a certain format, therefore the main typical operations of this application are the processing of files (of the appropriate format): opening, loading, editing and saving. If the OS is a complete system designed to manage operations, then typical file operations should be an integral part of the OS itself. “Installing” the application we need, we, in fact, tell the OS a specific way of processing files of a certain format, and the OS provides a single (and, also, common software) interface for accessing files for files of all conceivable formats. In fact, the OS should independently create in its depths some kind of software object (we will conditionally call objects intended for solving application tasks at the “application level” as software objects), which is something like a resource shared between the OS and this application. A program object can also be called a document, but, as it is not called, the essence of a program object remains unchanged: program objects are created, as it were, “inside” the application, but are managed by the OS. Each application thus turns out to be a document factory, providing the OS with a description (specification) of the format of the documents being processed, and already the OS takes on the main functions of creating a user interface. In turn, the OS provides each application with its own environment, which is determined by the type of the application itself and the task that the user is currently solving. This approach allows you to compare the OS with a database where all data is stored in an orderly manner, and access to it is carried out using a certain query language. Unfortunately, the "solidity" of applications significantly hinders the implementation of this approach.
Imagine that applications are not monolithic. What does this mean? Normally, the OS loads the application being launched into RAM and gives it control. Do whatever you want! But, first, each application is not a “spherical horse in a vacuum,” it is an entity intended to solve certain problems. In this sense, each application must “lie” in the OS on a certain “shelf”. If the OS is perceived as a database, then this database should have something like a reference book “Nomenclature” containing, in essence, a full-fledged thesaurus or a registry of concepts, and then each application will be tied to a certain position of this reference book. Secondly, each application should be perceived as a set of interrelated and interconnected components, each of which must also be controlled by the OS. Accordingly, having a certain pool of components installed in the OS, we can assemble new applications (new combinations of components) to solve new problems. If the program code is stored in the OS in some tables, then we can create the applications we need, composing well structured queries to the database of program code and receiving the final code in the form of an ordered sample of instructions. Thirdly, each “monolithic” application is delivered “as is” (as an executable file or as a compiled package), and we have no way to extract its source code from an application (this is what Sergey Tarasov in his book Soft Engineering from the inside "called" hopeless programming "), if, of course, the developers of this application did not provide (SUDDENLY) this happy opportunity. If applications were developed strictly according to the component model, then we could always switch to the “master” mode in the application we are interested in, decompose, go to the component level, extract the initial component of any component we need, make corrections to it, automatically save changes as a new version and use the new version along with the old one. (Yes, it is fundamentally at variance with the common practice of hiding source code, creating special protection against hacking.)
What has been said above makes us come to a definite conclusion: the OS should be something like a DBMS that manages different types of databases — a code database, an application database, and a user database containing the final data that users deal with. Each application makes a certain contribution to each of the listed databases and, in fact, is itself something of a database. Accordingly, the installation, operation and destruction of the application are, therefore, transactions carried out in different databases. And here we come to a very important question: where, here, is the code specific to this application? Another version of the same question: in what form should the source code of this application be supplied (for the OS)?Is not, here, the best approach, the application of which each installed application must be represented (and supplied by the developer) in a declarative form (and only in it) so that the compilation is done only when installing this application in the OS? A positive answer to this question leads to several important consequences. First, the OS can (and should be) initially provided for all the main types of interaction and implemented typical tasks. This means that any program code installed from the OS should initially be tied to predefined typical tasks. Secondly, standard operations and standard interactions imply a rather formalized and well-automated scheme for creating a user interface. And this meansthat no application will need to take on the implementation of, in fact, the same functions associated with the opening of various dialog boxes. Thirdly, with ready-made declarations and working components, you can create new applications, delivering new declarations and new components to your employees or interlocutors. In part, this is reminiscent of the “1C” application, which SUDDENLY would become a full-fledged OS. Indeed, briefly describing everything that we have described above, it turns out that the OS as a technology platform supports certain “configuration objects”, the configurations themselves describe the user data processing model, and at some point in time is used (running and functioning) one configuration that determines the appearance of the desktop, the functions available on it, etc.associated with the opening of various dialog boxes. Thirdly, with ready-made declarations and working components, you can create new applications, delivering new declarations and new components to your employees or interlocutors. In part, this is reminiscent of the “1C” application, which SUDDENLY would become a full-fledged OS. Indeed, briefly describing everything that we have described above, it turns out that the OS as a technology platform supports certain “configuration objects”, the configurations themselves describe the user data processing model, and at some point in time is used (running and functioning) one configuration that determines the appearance of the desktop, the functions available on it, etc.associated with the opening of various dialog boxes. Thirdly, with ready-made declarations and working components, you can create new applications, delivering new declarations and new components to your employees or interlocutors. In part, this is reminiscent of the “1C” application, which SUDDENLY would become a full-fledged OS. Indeed, briefly describing everything that we have described above, it turns out that the OS as a technology platform supports certain “configuration objects”, the configurations themselves describe the user data processing model, and at some point in time is used (running and functioning) one configuration that determines the appearance of the desktop, the functions available on it, etc.delivering new declarations and new components to your employees or interlocutors. In part, this is reminiscent of the “1C” application, which SUDDENLY would become a full-fledged OS. Indeed, briefly describing everything that we have described above, it turns out that the OS as a technology platform supports certain “configuration objects”, the configurations themselves describe the user data processing model, and at some point in time is used (running and functioning) one configuration that determines the appearance of the desktop, the functions available on it, etc.delivering new declarations and new components to your employees or interlocutors. In part, this is reminiscent of the “1C” application, which SUDDENLY would become a full-fledged OS. Indeed, briefly describing everything that we have described above, it turns out that the OS as a technology platform supports certain “configuration objects”, the configurations themselves describe the user data processing model, and at some point in time is used (running and functioning) one configuration that determines the appearance of the desktop, the functions available on it, etc.that the OS as a technology platform supports certain “configuration objects”, the configurations themselves describe the user data processing model, and at any given time one configuration is used (running and functioning) that determines the appearance of the desktop, the functions available on it, and so on. d.that the OS as a technology platform supports certain “configuration objects”, the configurations themselves describe the user data processing model, and at any given time one configuration is used (running and functioning) that determines the appearance of the desktop, the functions available on it, and so on. d. etc.
... And here we have a question: are these notorious components not analogous to those blocks that we talked about earlier in relation to the WEB-pages?
Episode 2: component approach
If you write some simple program, you design it in the form of a simple procedure. Usually, it is enough to carefully read the program code of this procedure once to understand what it does. Especially if you write, adhering to a certain (always the same) style. You can see that some code snippets are of independent significance, and you may be tempted to arrange these snippets as separate procedures. By creating a new function block and giving it a name, you become a hostage once the decision is made. It's one thing if this is your code, then you can write a new procedure. Another thing is if it is not your code, and then you can make (if possible) your version of this function, or you will have to be content with what you have.
As long as we adhere to the procedural approach, everything remains within certain limits. But, as soon as you need to use a developed user interface, everything becomes much more complicated. First, the user interface components appear. Secondly, the components themselves have events, and you need to handle these events somewhere. Thirdly, you are limited, in essence, by the method of building components that is used in your development tool. The appearance of components, in fact, leads to the fact that the code is “blurred” between components, and this significantly complicates the study of the source code of the application.
Here, however, we are waiting for one big problem, which is sometimes talked about, but, somehow, really, very casually. The question is what exactly to consider as a component, and where, specifically, the logic of the component should be described. If we formulate the problem extremely briefly, then we can say this: who should be responsible for processing the message from the component? In fact, this is a key issue in building any software architecture! It turns out that to implement an arbitrary component it is necessary to have at least three objects: one object describes the external (user) interface, and initial events occur in this object; the second object sets the internal (software) interface and performs the primary event handling of the first object; The third object already performs specific actions. In fact,The logic of the component is implemented in the third object, which can be perceived as a controller (if you use the terminology of MVC). Attempting to implement a ready-to-use visual component is a mistake. For example, you can try to implement the [Calendar] component (as it is done) based on a tabular visual component, but a tabular view is just a view, and a calendar, in its essence, is a set of certain functions and, in a sense, a certain data type. You should not try to create a new component, but connect (that is, bind) already existing components with data objects. With this approach, you simply specify the data model and the internal (program) interface to the visual component. Something like an Occam's razor works here,which does not allow the tree of visual components to grow too large. If, however, it is assumed that in this way it is possible to handle, in general, any components, not necessarily visual, but, let's say, components as such, assuming some generalized component programming method, then you can implement a unified scheme for building applications from components. Thus, the component approach forces us to always create some layer of special interface objects that translate events occurring in some components into actions performed by other components. By linking the components into chains, we, in fact, describe some fragment of a large system, and the language for describing these components, together with the connections between the components, will be the very same modeling language that many people think about.
Imagine some program code in the form of a sequence of instructions. In the normal situation, this code, executed in the form of a procedure, is once compiled into code that is executed directly by the processor. If there is an object behind each variable, and each operation is overloaded, then we can run the procedure, so to speak, at idle and reproduce the syntax tree built for this procedure. This means that you can, before performing real calculations with real data, prepare the structures you need. In other words, you automatically have an additional layer of program objects that will be responsible not only for processing the data itself, but, for example, for keeping the event log, for converting data from one form to another,for managing the user interface and for restricting access to certain functions. With this intermediate layer, you can, having a ready-made application, save it ... as source code. But what seems to be especially important here, you get the opportunity to write all your programs, adhering to a strict procedural approach. And, if, for example, you implement some computational algorithm that requires input of any parameters, then you should arrange it just as data input, but not describe the input itself in any way: the intermediate layer of objects will perform the necessary binding of the input data with input fields or with the file selection dialog. Thus, the component approach allows you to reuse the same program code, while, depending on the context, the result of this code will be different,and the calculations that will actually be performed when processing the final (user) data may differ from the previously specified ones, because, as a result of "intermediate" calculations, instead of some generalized algorithm specified in the source code, a specific implementation was inserted, which is determined by the current configuration of the application.
Second lyrical digression (not so long)
It would be extremely tempting to “mathematize” programming in some suitable way and consider some semblance of a scalar product. The meaning of the analogy is to define a certain space and define in it multiplication operations (interaction of two objects) and addition (concatenation or merging of results). Then, the scalar product operation could describe a fairly wide range of phenomena. And where is the scalar product, there is the Gramm-Schmidt orthogonalization process. Here we need the concept of linear independence. Having a system of linearly independent "vectors", we can go to an orthonormal system, and the scalar product in an orthonormal basis is described extremely simply. This is the simplicity you should strive for when creating software.
What does orthogonalization mean for data? The fact is that any entity manifests itself in different ways in different circumstances. This means that the same real-world object appears in different roles in different interactions. Therefore, for each such type of interaction, you need to create your own program object. But each such object (or object class) will be processed using its own separate component. By separating different types of control flows, we, in fact, provide the developer with the opportunity to write the most generalized code.
What does orthogonalization mean for operations? This means that you can always arrange convenient access to all operations, you can create lists of operations by type, maintain a separate database for operations, and that seems to me particularly important, we have the opportunity to code operations on objects in one way and do this code part of the physical representation of the program code. Recall FORTH with his idea of ​​representing programs as bundles of recursive functions. If you have a table of functions (operations), then ... You can literally solve any task using the construction of finite automata (according to Shalyto), but this possibility should, in theory, be built in the OS!
Episode 3: hierarchy of programming languages
Comparison of programming with the process of layout of complex documents seems to be very significant. It is usually assumed that the source code of the program is written first (in any programming language), and then this code is translated into the code of the target machine. (There is also an important intermediate representation in the form of so-called “byte-code”, but this is not the
point now.) There are two problem points here.
On the one hand, any complex software should be presented not in the form of its source code, but in some special form; in this sense, the source code of any application should not be a code in some programming language, but something like a database. In fact, the development environment should not be a simple source code editor with advanced functions, but a document-oriented system that allows, for example, to keep some sort of “accounting”. If you perceive each action in such an environment as an operation with a certain “account”, then the “programming” of a complex corporate system will consist in replenishing certain “accounts” with the subsequent compilation of a “report”, while various types of “reports” will answer different tasks for example, the documentation of the designed system can also be considered a kind of "report"). (It is to this,in my opinion, as a result, serious developers of large corporate systems come. But this approach, unfortunately, does not become a “common place.”)
Here it is important that the application, at first, is always in a project state, which means that the program code (in the final programming language) is only the final result of the developer’s work, and even before this program code (needed only when real product exploitation) will be completely ready, the developer has quite a lot of work, and the first release can only appear when the customer and the performer, sitting at the same development tool, can finally “hit their hands” and press the cherished “red w "button (which may be referred to, for example," New Release "). This, again, greatly brings together the creation of software and the layout of documents: you write the “source code” and, just before printing, skip the created “code” through the layout system. Of course, you can constantly check intermediate results,but sometimes it happens if you, for example, write an article for a collection, you send only the “source code” to the editorial board.
On the other hand, the question arises about the relationship between procedural and declarative approaches. It is difficult to do without a practical example and explain the essence of the question "in words." If we could use various declarations quite widely, then ... we would use only them, for example, to transmit data over the network. (Is it not for this that XML was created at the time?). Receiving only declarations, the OS could compile a native code for itself according to a given declaration. (And it would be safe!) In this sense, the OS can be perceived as a hierarchy of languages, which means that the OS should have built-in tools for building translators, but then the question will not be put the way it is put today - what language to choose programming and development environment, but in the opposite way: which programming language should be created,to optimally solve problems of a certain type. I still do not know this, but it seems to me that functional programming can bring clarity in answering this question, and future discoveries in the field of creating some kind of three-dimensional memory (where the same data can be placed in a huge number of ways depending on the task, they will solve the issues of speed of the so-called. “Lazy calculations”, which seem extremely promising because they are conceptually transparent and conclusively accurate. Next - to error-free programming!Three-dimensional memory (where the same data can be placed in a huge number of ways, depending on the task) will solve the speed problems of the so-called. “Lazy calculations”, which seem extremely promising because they are conceptually transparent and conclusively accurate. Next - to error-free programming!Three-dimensional memory (where the same data can be placed in a huge number of ways, depending on the task) will solve the speed problems of the so-called. “Lazy calculations”, which seem extremely promising because they are conceptually transparent and conclusively accurate. Next - to error-free programming!
Reprise: what is the reason for what is happening?
Why does everything happen the way it does?
For a start, there is an economic explanation. The time required for detailed thinking and implementation of a complete multifunctional and secure solution is not. All you need is "here and now." As a result, the winners are the companies that were the first to stake out the scope of work for themselves. If you make, one day, a product that truly automates a certain activity, you will leave future generations without bread.
“Politics is a concentrated economy”, and therefore, in order to spread its influence in time and space, one must always maintain one’s own value for the user. And if practical problems are solved more easily, if there is a way to streamline them somehow, if there is an opportunity to automate typical operations once and to design applications on the fly to solve current user tasks, then ... why do we need numerous software development companies?
And what is a "concentrated policy"? Right!The science! And what can science tell us? I want to remind the interested reader that the initial idea of ​​the hyperlink was not to make the transition from one document to another possible, but to create an inseparable link between two documents, so that we could use another document while looking at one document. . Hyperlinks, in their essence, are needed in order to be able to reflect the dynamic nature of changes of the whole WEB as a whole. This means that when you open a single document, you have the opportunity to automatically upload information that relates to the subject of interest. What has only recently been reported as a kind of achievement (JSON and REST) ​​should have initially been the foundation of all distributed data storage technology. But for the realization of this information "paradise" it would be necessary to understandthat: firstly, WEB should be a large distributed knowledge base (which means that the basis should be based on the ideas of hierarchical distributed semantic databases, and where ordinary relational databases would occupy their honorable, but, nevertheless, subordinate "intermediate "Position); secondly, for the functioning of this system, it is necessary not to minimize traffic (as is usually done), but to establish a permanent exchange of data, make it regular (which means that no DDoS attacks, in particular, will be impossible, since it will be impossible to “just so "make a request for a particular page, you can only request some specific information); thirdly, for WEB users should be presented as a large Wikipedia, where each page has a history of edits, you can always create a discussion or take part in editing.In a word: such a WEB is similar to the real world, where there can be no “broken” links, users deal with documents, each document has its own history, etc. etc. Yes Yes. Dreaming is not bad, is it?
Coda: everything just begins
Why did I write this article?
First, I decided to tidy up my own thoughts a bit and try to put them together in a coherent way. Connected to explain failed. Is to blame.It turned out several disparate scenes and episodes. The idea is that here, in this article, reminiscent of an iceberg, on which my wild imagination stumbled, several blanks were buried for quite decent articles that you can, and generally speaking, should write here in Habrahabr.
Secondly, I tried to outline for myself the circle of my own interests and determined for myself the area of ​​my searches. It would be extremely interesting for me to develop flexible software systems based on the component approach (which must be worked out!), To search for non-standard ways of implementing generalized programming and to solve the fascinating problem of the correlation of procedural and declarative principles in programming.
Third, ... but maybe everything is already there? Is everything already invented? Everything you need already exists? Well, then I will be glad to hear about it from others and I can immediately take up the solution of real problems. And then, believe me, there will be a lot of reasons to write about what I did along the way ...
As it was once said: "do not talk about how you work hard and hard, tell us better about what you have achieved."
Source: https://habr.com/ru/post/325448/
All Articles