It became the rule: every time that is let out the new version of program product, substantially - now and then to many megabytes - run up its requirements for the dimensions of computer memory. When such demands exceed the available memory, it is necessary to buy additional. When further extension is impossible, then it is necessary to acquire new, more powerful computer or working station. But do go large productivity and extended functionality into the foot all by the being increased demands to the computational resources? In the majority of the cases the answer will be is not.

Years 25 ago, interactive text editor could be designed from the calculation of altogether only 8000 it was byte memory - contemporary editors it was text programs they require 100 or more times more. Operating system had to attend 8000 byte, and compiler had to be accommodated into 32 Kbytes, while their present descendants they require for his work of many megabytes. However, and that: this bulging software did become more rapid and it is more effective? Vice versa. If not equipment it by the increased into thousands of times productivity, contemporary software simply would not be possible to use.

It is considered that the extended functionality and conveniences in the user justify ever increasing sizes of programs; however, more fixed view reveals the unsteadiness of similar justifications. The same text editor still accomplishes sufficiently simple task in the insert, the removal and the transfer of the fragments of text; compiler as before transmits text into the usable code; and operating system, as in the bylye times, it governs memory, disk space and cycles of processor. These base responsibilities completely did not change with the advent of windows, strategy "cutting- insert" and of the floating up menu, just as with the replacement of text command lines by elegant pictograms.

So explicit explosive an increase in the dimensions of software would be, of course, it was unacceptable, if the not stunning progress of semiconductor technology, which improved relation to the degree, which has analogs not in what another region of technology. So, from 1978 through 1993 for the family of processors Intel of 80kh8' productivity increased 335, the density of the arrangement of transistors - 107 times, while price - only 3 times. Prospects for a constant increase in the productivity remain, with the fact that there are none it is indicative, that the wolf appetite, inherent in now software, will be in the foreseeable future quenched [ 1 ]. This course of events provoked the appearance of numerous rules, laws and conclusions, which, as this occurs in such cases, they are expressed in the universal terms; as such, they cannot be either proven, or refuted. Following two "laws" extremely good (although with the portion of irony) reflect present state of affairs:

* Software increases in the sizes until it fills entire accessible at the given moment memory (Parkinson)

* Software slows down more rapidly than equipment it becomes more rapid

The uncontrollable increase in the sizes of programs starts as proper also because the users have difficulties in separation of the actually essential features of program product from the special features, which it is simply "good to have". Examples: the arbitrarily being overlapped windows, proposed by the no critically perceived popular metaphor "working table"; the whimsical pictograms, which decorate screen - antiquarian mailboxes for the electronic mail or the basket for the collection of rubbish (which and furthermore also, they remain visible during the motion to their new position). These details are attractive, but they are not essential, and they have their concealed cost.

1. Reasons for “fat” of software

Thus, two factors make a contribution by the users of software of ever more growing sizes:

* the rapidly being increased apparatus productivity

* ignoring the fundamental difference between the vitally important possibilities and those, which "it is good to have".

But, possibly, is more important than it is simple to find reasons for this tolerance, to attempt to understand however, that the drift of software towards the complexity specifies.

Noncritical adoption by the supplying firms of in effect any demand of users relative to the new possibilities of program product is basic reason. Any incompatibility with the initial concepts of system either is ignored or it passes as that not recognized. As a result, the design solutions are complicated, while in the use product becomes bulkier. When the power of system is measured by the number of its possibilities, a quantity becomes more important than quality. It is considered that each new editorial staff of product must propose any additional possibilities, even if some of them do not actually add functionality.

Another important reason, critical for the program complexity, lies at the "monolithic" design, when all conceivable possibilities immediately are embedded into the system. Each user pays for all possibilities, but actually are used only a few of them. But in the ideal, must be proposed only base system with the essential possibilities placed into it, but this system must have a potential for different expansions. Then each user could select the functions, actually necessary for his task.

The increased productivity of equipment, undoubtedly, was stimulus for the developers with the attack on the more complex problems, and more complex problems unavoidably require the more complex solutions. However, the discussion deals not with this internally inherent in the program systems of the complexity, about which must be ill the head; we speak here about the complexity, artificially introduced. There is a mass of problems, long ago already solved, but are now to us proposed the "new" solutions of the same problems, covered into the bulkier program shell.

The increased complexity for the most part is the consequence of our recently emergent predilections to the "friendly" user interface. 4 it already mentioned windows and pictograms; here it is possible to add color, semitone, shadow, the floating up menu, all possible pictures and the dialogue "properties" of different types.

1.1 complexities as the equivalent of the power

The ease of the use of a system always must be central objective, but this ease must rest on the systems of concept lying at the basis, that also makes it possible to make work with it of almost intuitive. It seems, however, that the it is further, the more the people are inclined to erroneously interpret complexity as the refinement, which brings down to sense, - and indeed incomprehensibility must arouse suspicion, but not admiration.

Possibly, this tendency originates from the doubtful faith in the fact that to a certain degree the mysterious means reports the aura of something super-natural to user (although that it actually "reports", so this feeling of helplessness, if not weakness). Therefore, the temptation of complexity as stimulus for sales is easily intelligible; complexity contributes to the maintenance of the dependence of user on the supplier.

It's no secret to anyone, for example, what basic firm- producers of software carried out - and successfully! - the investments in the service maintenance, after hiring hundreds of consultants, intended twenty-four hour to answer the bells of users. It would be, however, much more economical both for them and for their clients, if program product was based on the systematic concepts (universally valid rule of deductions, and not on the tables of the rules, applied only to the specific situations) in combination with the systematic documentation and the training courses. Certainly, the client, who pays - forward! - for the contractual service, is more stable source of income, than the client, who completely independently mastered product. Industry, probably, pursues the purposes, very different from those accepted in the academic peace; consequently, it is possible to formulate one additional "law": the dependence of client is more profitable than his instruction

What I find by truly placing in the blind alley - so this of management and documentation - with volume of hundreds of pages!, which accompany applications programs, languages of programming and operating systems. It is error-free, they signal both about the distorted design without the clear conceptual base and about the intention to powder to user the brains.

However, one absence alone of clear conceptual basis cannot answer for an explosive increase in the dimensions of software. The design of the solutions for the complex problems, they do appear at the program or apparatus level, this difficult, by road the requiring is much time process. The so improved apparatus relation is achieved more as a result of the best technology of the industrial copying of projects, than because of the more advanced possession of the methods of design. The creation of software, however, is designing as such, and its copying costs the producer of kopeck.

The initial design of program system for the complex applications invariably itself is complex, even when competent engineers develop him. The truly good design solutions appear after iterative improvements or after redesign, which rests on the qualitatively new understanding of problematic region and methods of solution of problem, and the most successful iterations - this those, which lead to simplification in the programs. The evolutions of this type, however, are extremely rare in the current practice - they require prolonged cognitive process, which is very rarely evaluated in the manner that it becomes. Instead of this, inadequacy in the programs they are usually corrected by the "additions proposed to the fast hand", which unavoidably lead to the most disproportionate volumes.

of 1.2 times do not always be sufficient

A constant deficiency in the time - here, it is probable, the first-rate reason, which leads to the appearance of bulky software. The hurry, in conditions of which work the designers, does not contribute to thorough planning and improvement of the solutions accepted; then it panders to the appearing in motion program additions and corrections. Hurry little by little reduces the engineering standards of quality and perfection and it has extremely adverse effect on personnel, and it means also to the developed products.

One additional characteristic feature of computer industry is the fact that the supplier, for whom it was possible first to reject product for the market, as a rule, obtains the perceptible advantages over the competitor, whose analogous - is best according to quality! - product appears by the second. Tendency to assume the first appeared product as de facto- standard - these are the extremely lamentable phenomenon, caused to the life is everything the same hurry.

A good engineering practice is characterized by the sequential step-by-step improvement of product that also leads to an increase in the productivity with the assigned resources and the limitations. However, limitations to the computational resources are not considered to any extent serious and the ease they are ignored: it seems, is present the universal faith in the fact that the exuberance in the velocity of processor and dimensions of memory those allowed with the design ON the carelessness compensate. Thorough engineering work does not bring dividends in the feverish races to the short distances, and this is one of the reasons, why program engineering has doubtful reputation among kept balance engineering disciplines.

2. Languages and the methodology of the design

Although studies in the region of development ON, that are been key for many future technologies, use not bad financial support, their results, judging by everything, are recognized as not too appropriate for the use in the contemporary program industry. Systematic methodical design, for example, has a reputation of not too of that being suitable, since for the output to the market for products, by such means of those developed, supposedly too much time is required. Matters concerning the analytical verification and the methods of the proof of correctness even more badly be; among other things, these methods require higher intellectual caliber than that entered the habit "try and all will come out" approach. It is not surprising that in light of the love of users for any kind "ware", the proposals about the reduction of complexity with the aid of the concentration on the basic principles as deliberately absurd. When as modus operandi comes out exclamation "and all it works!" methodologies and discipline in the development become the first victims.

The methodologies, connected with the languages of programming, until now, are the object of discussions. In 1970- X it was accepted to believe that the design of programs must rest on the well-structured methods and the layers of abstraction with the clearly specific specifications. Best anything this thought was expressed in the concept of the abstract type of data, which found its embodiment in the new then languages, first of all in Modula-2 and Ada. Today programmers leave the well structured languages and they migrate, in essence, to SI the language of SI does not make possible for compiler even to carry out the control of safety of types, but indeed precisely this function to the greatest degree is useful with the development of programs for the localization of conceptual errors already at the early stage. Untyped very concept of abstraction in the languages of programming becomes empty and that having purely academic interest. Abstraction can work only in the languages, which postulate a strict static standard control for each variable and functions. In this respect of SI it is unfounded and, in the essence, it is such to the assembler code, where, true, "everything works".

It is very remarkable, that the abstract type of the data 25 years after its invention appeared again by the name "objective- oriented". In its essence this contemporary concept (taken by many as panacea) most of all it is connected with the construction of the hierarchies of classes or types. Older concept not was, in the essence, understood, until appears new label "objective- oriented"; now programmers recognized inherent in the abstract type of data power and turned themselves finally to it. However, so that it would be possible to speak in earnest about the objective- oriented languages, in them must be realized a strict static typification, which could not be destroyed; this would afford the possibility to programmer to rely on compiler in the matter of the identification of the different kind of disagreements. Unfortunately, the most popular language, S++, are unsatisfactory in this respect, because it was originally proclaimed, what it must be compatible with its ancestor - the language of SI the wide adoption Of s++ it confirms the following "laws":

* Progress is acceptable, only if it is compatible with the current state.

* Adherence to standard - is always safer than even the justified withdrawal from it.

Assuming this situation as given more than, programmers enter into the fight with the language, which does not encourage structural thinking and the disciplined construction of programs, denying the base support of compiler. They also come running to the tool- palliatives, which even more contribute to the growth of the sizes of programs.

That after gloomy picture; which pessimist! - must be, the reader thinks. And no hint to the bright computer future, which, like, is considered by itself being understood. In reality, this gloomy view is realistic; nevertheless, if there is a desire and will, then it is possible to find the method to improve the present state of the matters.

3. Project "Oberon"

Between 1986 and 1989, Jurg Gutkneht and I developed and realized the new system of software - named Oberon, intended for the working stations, and which rests directly on the hardware and, correspondingly, he does not use any strange programs. Our basic purpose it was demonstrate - software can be developed so as to use only an small part of the memory and processor power of usually those required; in this case there is no need for sacrificing flexibility, functionality or conveniences in the user.

Beginning from 1989, the system of Oberon widely is used in many subject areas: the preparation of documents, the development of software and the automated designing of electronic circuits. System includes:

* control of memory;

* file system;

* the window system for control of mapping data;

* network with the servers;

* compiler;

* the editor of documents;

* text and graphic editors.

That designed and realized - from zero - by the association of two people in three years, Oberon was in the past postponed by several serially produced working stations and acquired the sympathies of many filled enthusiasm users, especially since it became freely accessible.

Our additional purpose it was design such system, which it would be possible to easily explain and to study in all details,; being suitable for using as an example the design of program system; and which would be "transparent" on top downwardly. All basic design solutions can be clearly represented and explained. (actually, the practical absence of the published detailed examples of the creation of program systems to obviously each, who occurred before the need for reading the corresponding training course). The book, which contains the complete description of system together with the source texts of all modules, was fruit of our efforts.

Due to what it did be possible, after spending only five man-years, to build this representative program system, to on top of that and give its comprehensive description in the one- only book 3.1 three basic rules

First, we were concentrated on the actually essential features of system. We disregard all, that is not exerted a substantial influence on the necessary power and the flexibility of system. For example, interaction with the user in the base system is limited to the regime of input/output of text information - any drawing, any pictures and pictograms.

In the second place, we wanted to use the truly objective- oriented language of programming - capable of ensuring safety of types. In combination with our faith in the fact that the first principle is even more required for the instrument means, than for the most constructed system, this forced us to design its own language and to design for it compiler. So arose Oberon - the language, in the essence obtained from language Modula-2 by removal from it the "unreliable" special features (such as the functions of conversion of the type and variant records) together with the not too essential (examples - type- range and the enumerable type).

Finally, we assumed that the system must be flexibly expansible - this will allow it to become simple, effective and useful. Consequently, into it the new modules, which include new procedures on the basis of the call of those of already existing, can be added. This also means that in the new modules the new types of data, compatible with the existing types, can be determined. We call their extended types, and they are the only fundamental concept, which was added to Modula-2.