Что сказал Дейкстра в конце жизни
Страница 1 из 1

Автор:  Владимир Паронджанов [ Суббота, 16 Октябрь, 2010 13:32 ]
Заголовок сообщения:  Что сказал Дейкстра в конце жизни

Недавно я прочитал материал Дейкстры, который меня очень озадачил.
Дейкстра отрекается от названия "GOTO Statement Considered Harmful"
(Оператор GOTO считается вредным (опасным)".
И подчеркивает, что он дал статье другое название. Но редактор журнала
Никлаус Вирт убрал заглавие Дейкстры. И назвал статью (письмо
в редакцию) по-своему.

Короче, название "GOTO Statement Considered Harmful" придумал
не Дейкстра, а Вирт.

У меня возник вопрос: зачем Дейкстра пишет об этом? Причем, он пишет это
в конце жизни. Примерно за год до смерти.

Дейкстра умер 6 августа 2002 года в возрасте 72 лет. А материал, который
меня озадачил, написан 10 июня 2001 года. Точнее, меня озадачил
не весь материал, а только его последний абзац.

У меня нет никакого мнения или предположения на этот счет. Я просто
не понял, почему Дейкстра отрекся от эффектного названия Вирта.

Ведь если бы Дейкстра был согласен с названием Вирта, тогда зачем
об этом писать? Причем писать спустя десятилетия после события,
почти в конце жизни.

Мне это непонятно. Я обращаюсь к участникам нашего форума.
Что вы думаете по этому поводу? Каково ваше мнение?

Продолжение следует

Автор:  Владимир Паронджанов [ Суббота, 16 Октябрь, 2010 13:45 ]
Заголовок сообщения:  Re: Что сказал Дейкстра в конце жизни

Дальнейшее изложение ведется по следующему плану.

:arrow: Сначала я приведу текст статьи "Оператор GOTO считается опасным"
(к сожалению, по-английски).

:arrow: Затем приведу английский текст материала
What led to "Notes on Structured Programming"
Это материал из Архива Дейкстры. Я не знаю, был ли
он когда-либо напечатан.
Если перейти по ссылке EWD1308 в правом верхнем углу, мы увидим
рукопись Дейкстры.

:arrow: После этого дам автоматический перевод материала на русский язык

:arrow: B заключение я переведу на русский язык последний абзац архивного

Продолжение следует

Автор:  Владимир Паронджанов [ Суббота, 16 Октябрь, 2010 14:09 ]
Заголовок сообщения:  Re: Что сказал Дейкстра в конце жизни

Go To Statement Considered Harmful
Edsger W. Dijkstra

Reprinted from Communications of the ACM, Vol. 11, No. 3, March 1968, pp. 147-148. Copyright ©
1968, Association for Computing Machinery, Inc.

This is a digitized copy derived from an ACM copyrighted work. It is not guaranteed to be an accurate copy of the author's original work.

Key Words and Phrases: go to statement, jump instruction, branch instruction, conditional clause, alternative clause, repetitive clause, program intelligibility, program sequencing
CR Categories:
4.22, 6.23, 5.24


For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. More recently I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all "higher level" programming languages (i.e. everything except, perhaps, plain machine code). At that time I did not attach too much importance to this discovery; I now submit my considerations for publication because in very recent discussions in which the subject turned up, I have been urged to do so.

My first remark is that, although the programmer's activity ends when he has constructed a correct program, the process taking place under control of his program is the true subject matter of his activity, for it is this process that has to accomplish the desired effect; it is this process that in its dynamic behavior has to satisfy the desired specifications. Yet, once the program has been made, the "making' of the corresponding process is delegated to the machine.

My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.

Go To Statement Considered Harmful Page 1 of 3
http://www.acm.org/classics/oct95/ 9/26/2002

Let us now consider how we can characterize the progress of a process. (You may think about this question in a very concrete manner: suppose that a process, considered as a time succession of actions, is stopped after an arbitrary action, what data do we have to fix in order that we can redo the process until the very same point?) If the program text is a pure concatenation of, say, assignment statements (for the purpose of this discussion regarded as the descriptions of single actions) it is sufficient to point in the
program text to a point between two successive action descriptions. (In the absence of go to statements I can permit myself the syntactic ambiguity in the last three words of the previous sentence: if we parse them as "successive (action descriptions)" we mean successive in text space; if we parse as "(successive action) descriptions" we mean successive in time.) Let us call such a pointer to a suitable place in the text a "textual index."

When we include conditional clauses (if B then A), alternative clauses (if B then A1 else A2), choice clauses as introduced by C. A. R. Hoare (case[i] of (A1, A2,•••, An)),or conditional expressions as introduced by J. McCarthy (B1 -> E1, B2 -> E2, •••, Bn -> En), the fact remains that the progress of the process remains characterized by a single textual index.

As soon as we include in our language procedures we must admit that a single textual index is no longer sufficient. In the case that a textual index points to the interior of a procedure body the dynamic progress is only characterized when we also give to which call of the procedure we refer. With the inclusion of procedures we can characterize the progress of the process via a sequence of textual indices, the length of this sequence being equal to the dynamic depth of procedure calling.

Let us now consider repetition clauses (like, while B repeat A or repeat A until B). Logically speaking, such clauses are now superfluous, because we can express repetition with the aid of recursive procedures. For reasons of realism I don't wish to exclude them: on the one hand, repetition clauses can be implemented quite comfortably with present day finite equipment; on the other hand, the reasoning pattern known as "induction" makes us well equipped to retain our intellectual grasp on the processes generated by repetition clauses. With the inclusion of the repetition clauses textual indices are no longer sufficient to describe the dynamic progress of the process. With each entry into a repetition clause, however, we can associate a so-called "dynamic index," inexorably counting the ordinal number of the corresponding current repetition. As repetition clauses (just as procedure calls) may be applied nestedly, we find that now the progress of the process can always be uniquely characterized by a (mixed) sequence of textual and/or dynamic indices.

The main point is that the values of these indices are outside programmer's control; they are generated (either by the write-up of his program or by the dynamic evolution of the process) whether he wishes or not. They provide independent coordinates in which to describe the progress of the process.

Why do we need such independent coordinates? The reason is - and this seems to be inherent to sequential processes - that we can interpret the value of a variable only with respect to the progress of
the process. If we wish to count the number, n say, of people in an initially empty room, we can achieve this by increasing n by one whenever we see someone entering the room. In the in-between moment that we have observed someone entering the room but have not yet performed the subsequent increase of n, its value equals the number of people in the room minus one!

The unbridled use of the go to statement has an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress. Usually, people take into account as well the values of some well chosen variables, but this is out of the question because it is relative to the progress that the meaning of these values is to be understood! With the go to statement one can, of course, still describe the progress uniquely by a counter counting the number of actions performed since program start (viz. a kind of normalized clock). The difficulty is that such a coordinate,

Go To Statement Considered Harmful Page 2 of 3
http://www.acm.org/classics/oct95/ 9/26/2002

although unique, is utterly unhelpful. In such a coordinate system it becomes an extremely complicated affair to define all those points of progress where, say, n equals the number of persons in the room minus one!

The go to statement as it stands is just too primitive; it is too much an invitation to make a mess of one's program. One can regard and appreciate the clauses considered as bridling its use. I do not claim that the clauses mentioned are exhaustive in the sense that they will satisfy all needs, but whatever clauses are suggested (e.g. abortion clauses) they should satisfy the requirement that a programmer independent coordinate system can be maintained to describe the process in a helpful and manageable way.

It is hard to end this with a fair acknowledgment. Am I to judge by whom my thinking has been influenced? It is fairly obvious that I am not uninfluenced by Peter Landin and Christopher Strachey.

Finally I should like to record (as I remember it quite distinctly) how Heinz Zemanek at the pre-ALGOL meeting in early 1959 in Copenhagen quite explicitly expressed his doubts whether the go to statement should be treated on equal syntactic footing with the assignment statement. To a modest extent I blame myself for not having then drawn the consequences of his remark

The remark about the undesirability of the go to statement is far from new. I remember having read the explicit recommendation to restrict the use of the go to statement to alarm exits, but I have not been able to trace it; presumably, it has been made by C. A. R. Hoare. In [1, Sec. 3.2.1.] Wirth and Hoare together make a remark in the same direction in motivating the case construction: "Like the conditional, it mirrors the dynamic structure of a program more clearly than go to statements and switches, and it eliminates the need for introducing a large number of labels in the program."

In [2] Guiseppe Jacopini seems to have proved the (logical) superfluousness of the go to statement. The exercise to translate an arbitrary flow diagram more or less mechanically into a jump-less one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one.


1. Wirth, Niklaus, and Hoare C. A. R. A contribution to the development of ALGOL. Comm. ACM 9 (June 1966), 413-432.

2. Bohm, Corrado, and Jacopini Guiseppe. Flow diagrams, Turing machines and languages with only two formation rules. Comm. ACM 9 (May 1966), 366-371.

Edsger W. Dijkstra
Technological University
Eindhoven, The Netherlands

Go To Statement Considered Harmful Page 3 of 3
http://www.acm.org/classics/oct95/ 9/26/2002

Продолжение следует

Автор:  Владимир Паронджанов [ Суббота, 16 Октябрь, 2010 14:37 ]
Заголовок сообщения:  Re: Что сказал Дейкстра в конце жизни

Материал из архива Дейкстры
http://www.cs.utexas.edu/users/EWD/tran ... D1308.html


What led to "Notes on Structured Programming"

The purpose of this historical note is to describe the experiences which in hindsight seem to have influenced me when I wrote EWD249 "Notes on Structured Programming" in 1969. The note is based on what I remember; I am sure my memory has been selective and hence don't claim the objectivity of the professional historian.

I was introduced to programming at the 1951 Summer School, given in Cambridge by Wilkes. Wheeler and Gill, and became in 1952 on a part-time basis ℄initially 2 days per week℄ the programmer of the Mathematical Centre in Amsterdam; the rest of the week I studied Theoretical Physics in Leyden.

My only model was the program organization for the EDSAC in Cambridge; I followed it closely when designing program notation, input, output and library organisation for the ARRA in Amsterdam. For the next machines, the FERTA, the ARMAC and the X1, program notation and input would very much follow the same pattern: I clearly was a conservative programmer. Add to this that the ARMAC's instruction buffer with a capacity of one track of the drum, destroyed the store's homogeneity, and you will understand that I did not embark on adventures like "autocoders".

In 1955 I took the decision not to become a theoretical physicist, but to become a programmer instead. I took that decision because I had concluded that of theoretical physics and programming, programming embodied the greater intellectual challenge. You see, in those days I did not suffer from intellectual modesty. It was a difficult decision, for I had been groomed as first-class scientist and becoming a programmer looked like a farewell from science. When I explained to A. van Wijngaarden, my then boss, my dilemma, he told me that computers were here to stay and that in the world of programming I could be very well be the one called to create the science that was still lacking. Getting my physics degree in Leyden became a formality to be done with as quickly as possible. (As a matter of fact I no longer felt welcome in Leyden: the physicists considered me as a deserter and the mathematicians, one of whom openly prided himself on "of course knowing nothing about computers", were just contemptuous.)

In the mean time a pattern emerged for the cooperation between me and my hardware colleagues Bram J. Loopstra and Carel S Scholten. After the functional specification of the next machine had been written down (usually by me), that document served as a kind of contract between us: it told them what machine to design and construct, while I knew what I could count upon while writing all the basic software for the machine. The target of this division of labour was that my programs would be ready by the time the construction of the machine had been completed.

Looking back I now observe that the above arrangement has had a profound influence on how I grew up as programmer: I found it perfectly normal to program for not yet existing machines. As a byproduct it became firmly ingrained in my mind that I programmed for the abstract machine as specified in the original document, and not for the actual piece of hardware: the original document was not a description but a prescription, and in the case of a discrepancy not the text but the actual hardware would be at fault.

At the time I regarded this division of labour and the resulting practice of programming for non-existing machines as perfectly normal. Later I read an American article on why software was always late; I remember being very amazed when I read that limited availability of the hardware was the main cause, and I concluded that the circumstances under which I had learned programming had been less common than I had assumed.

Of course I could not exclude from my designs typographical errors and similar blemishes, but such shortcomings did not matter as long as the machine was not ready yet, and after the completion of the machine they could be readily identified as soon as they manifested themselves, but this last comforting thought was denied to me in 1957 with the introduction of the real-time interrupt. When Loopstra and Scholten suggested this feature for the X1, our next machine, I got visions of my program causing irreproducible errors and I panicked.

Eventually, Loopstra and Scholten flattered me out of my resistance and I studied their proposal. The first thing I investigated was whether I could demonstrate that the machine state could be saved and restored in such a way that interrupted programs could be continued as if nothing had happened. I demonstrated instead that it could not be done and my friends had to change their proposal. Admittedly the scenarios under which the original proposal would fail were very unlikely, but this can have only strengthened my conviction that I had to rely on arguments rather than on experiments. At the time that conviction was apparently not so widespread, for up to seven years later I would find flaws in the interrupt hardware of new commercial machines.

I had a very illuminating experience in 1959, when I had posed my colleagues at the Mathematical Centre the following problem. Consider two programs that communicate via atomic reads and writes in a shared store; can they be programmed in such a way that the execution of their critical sections exclude each other in time? Solutions came pouring in, but all wrong, so people tried more and more to elaborate counterexamples for their refutation, I had to change the rules: besides the programs they had to hand in an argument why the solution was correct.

Within a few hours, Th. J. Dekker handed in a true solution with its correctness argument. Dekker had first analysed the proof obligations, then chosen the shape of an argument that would meet them, and then constructed the program to which this argument was applicable. It was a very clear example of how much one loses when the role of mathematics is confined to a posteriori verification; in 1968 I would publish a paper titled "A constructive approach to the problem of program correctness".

And then there was ALGOL 60. We saw it coming in 1959 and implemented it in the first half of 1960. I was terribly afraid, for this implementation was then by far my most ambitious project: ALGOL 60 was so far ahead of its time that even its designers did not know how to implement it, I had never written a compiler and had to achieve my goal with a machine that had only 4096 word of storage. (The latter constraint was of course a blessing in disguise, but I don't remember seeing that when we started.)

By today's standards we did not know what we were doing; we did not dream of giving any guarantee that our implementation would be correct because we knew full well that we lacked the theoretical knowledge that would be needed for that. We did the only thing we could do under the circumstances, viz. to keep our design as simple and systematic as we could and to check that we had avoided all the mistakes we could think of. Eventually we learned that we had made mistakes we had not thought of, and after all the repairs the compiler was no longer as clean as we had originally hoped. (F. E. J. Kruseman Aretz still found and repaired a number of errors after I had left the Mathematical Centre in 1962.)

Right from the start we expected two very different types of errors, writing errors, whose repair is trivial, and thinking errors that would send us back to the drawing board, and the distinction has helped us because one combats them by different techniques. J.A. Zonneveld and I combatted the writing errors by coding together, each with his own text in front of him; when we were done, both our texts were punched independently, the two tapes were compared mechanically, and about two dozen discrepancies ℄if I remember correctly℄ showed up. The thinking errors we had tried to prevent by convincing each other why the proposed section would work. In this reasoning we could mainly discuss the workings of the compiler while the program compiled was treated as data, and this experience has been helpful for later, as it made us accustomed to non-operational considerations of program texts.

The whole experience has made me sensitive to what later would be called modularization or divide-and-rule or abstraction, to the care with which interfaces have been chosen and to the potential scope of the programming challenge in general. It has heavily contributed to my subsequent opinion that creating confidence in the correctness of his design was the most important but hardest aspect of the programmer' s task. In a world obsessed with speed, this was not a universally popular notion.

I remember from those days two design principles that have served me well ever since, viz.

(i) before really embarking on a sizable project, in particular before starting the large investment of coding, try to kill the project first, and

(ii) start with the most difficult, most risky parts first.

My first test program was almost the empty block, say

begin real x end ,

not the most difficult example, but my 4th test was a double summation in which the nested calls of the summation routine were introduced via the parameter mechanism, while the summation routine itself had been defined recursively. In passing we had demonstrated the validity of what became known as Jensen' s Device.

After this implementation interlude I returned in fairly general terms to the still open problem of the proper coordination of in principle asynchronous components. Without being directly involved I had witnessed a few years earlier the efforts of coupling all sorts of punched card equipment to the X1 and had been horrified by the degree of complication introduced by the inclusion of real-time commitments. For simplicity' s sake I therefore insisted on "timeless" designs, the correctness of which could be established by discrete reasoning only.

Almost unavoidably the model of Cooperating Sequential Processes emerged: sequential processes with (by definition!) undefined relative speeds and hence, for the sake of their cooperation, equipped with some primitives for synchronization.

Another opportunity for simplification was presented by the recognition that timing aspects between a piece of communication equipment and the program that used it were completely symmetrical between the two and independent of whether we had an input or output device. Needless to say, this unification helped a lot.

When we got involved in the design of the THE Multiprogramming System, scaling up slowly became a more and more explicit concern. It had to. Within IBM, and possibly elsewhere as well, circulated as a supposed law of nature that "system complexity" in some informal sense would grow as the square of the number of components; the reasoning behind it was simple ℄each component could interfere with each other component, etc.℄ but if it were true it would de facto rule out systems beyond a certain size. This evoked my interest in systems structured in such a way that "system complexity" in the same informal sense would not grow more than linearly with the size. In 1967, the expression "layers of abstraction" entered the computer lingo.

Let me close the discussion of this episode by quoting the last two sentences of EWD123 "Cooperating Sequential Processing" (September 1965):

"If this monograph gives any reader a clearer indication of what kind of hierarchical ordering can be expected to be relevant, I have reached one of my dearest goals. And may we not hope, that a confrontation with the intricacies of Multiprogramming gives us a clearer understanding of what Uniprogramming is all about?"

In 1968 I suffered from a deep depression, partly caused by the Department, which did not accept Informatics as a relevant to its calling and disbanded the group I had built up, and partly caused by my own hesitation what to do next. I knew that in retrospect, the ALGOL implementation and the THE Multiprogramming System had only been agility exercises and that now I had to tackle the real problem of How to Do Difficult Things. In my depressed state it took me months to gather the courage to write (for therapeutic reasons) EWD249 "Notes on Structured Programming" (August 1969); it marked the beginning of my recovery.

It tries to synthesize the above mentioned ingredients of the preceding decade. It mentions on an early page "the program structure in connection with a convincing demonstration of the correctness of the program", mentions as our mental aids "1) Enumeration, 2) Mathematical Induction, 3) Abstraction", and about the first and the last I quote (from EWD249-14)

"Enumerative reasoning is all right as far as it goes, but as we are rather slow-witted it does not go very far. Enumerative reasoning is only an adequate mental tool under the severe boundary condition that we only use it very moderately. We should appreciate abstraction as our main mental technique to reduce the demands made upon enumerative reasoning."

I had had two external stimuli: the 1968 NATO Conference on "Software Engineering" in Garmisch-Partenkirchen and the founding of the IFIP Working Group on "Programming Methodology". Thanks to the ubiquitous Xerox machine, my typewritten text could spread like wildfire, and it did so, probably because people found it refreshing in the prevailing culture characterized by the 1968 IBM advertisement in Datamation, that presented in full colour a beaming Susie Mayer who had solved all her programming problems by switching to PL/I. Apparently, IBM did not like the popularity of my text; it stole the term "Structured Programming" and under its auspices Harlan D. Mills trivialized the original concept to the abolishment of the goto statement.

Looking back I cannot fail to observe my fear of formal mathematics at the time. In 1970 I had spent more than a decade hoping and then arguing that programming would and should become a mathematical activity; I had (re)arranged the programming task so as to make it better amenable to mathematical treatment, but carefully avoided creating the required mathematics myself. I had to wait for Bob Floyd, who laid the foundation, for Jim King, who showed me the first example that convinced me, and for Tony Hoare, who showed how semantics could be defined in terms of the axioms needed for the proofs of properties of programs, and even then I did not see the significance of their work immediately. I was really slow.

Finally a short story for the record. In 1968, the Communications of the ACM published a text of mine under the title "The goto statement considered harmful", which in later years would be most frequently referenced, regrettably, however, often by authors who had seen no more of it than its title, which became a cornerstone of my fame by becoming a template: we would see all sorts of articles under the title "X considered harmful" for almost any X, including one titled "Dijkstra considered harmful". But what had happened? I had submitted a paper under the title "A case against the goto statement", which, in order to speed up its publication, the editor had changed into a "letter to the Editor", and in the process he had given it a new title of his own invention! The editor was Niklaus Wirth.

Nuenen, 10 June 2001

prof.dr Edsger W. Dijkstra
Department of Computer Sciences
The University of Texas at Austin
Austin, TX 78712-1188


Transcription by Wolfgang Houben.
Last revised on Mon, 21 Apr 2008.

http://www.cs.utexas.edu/users/EWD/tran ... D1308.html

Продолжение следует

Автор:  Владимир Паронджанов [ Суббота, 16 Октябрь, 2010 14:45 ]
Заголовок сообщения:  Re: Что сказал Дейкстра в конце жизни

Прошу прощения, это автоматический перевод на русский язык
материала из архива Дейкстры

Что привело к "Заметки по Структурное программирование"

Цель этой исторической справкой является описание опыта, который задним числом, кажется, повлияли на меня, когда я написал EWD249 "Заметки по Структурное программирование" в 1969 году. Записка основана на том, что я помню, я уверен, что моя память была селективного и, следовательно, не претендуют на объективность профессионального историка.

Я познакомился с программированием на 1951 Летняя школа, учитывая в Кембридже по Уилкс. Уилер и Гилл, и стал в 1952 году на неполный рабочий день ℄ изначально 2 раза в неделю ℄ программист математических центр в Амстердаме; конца недели я изучал теоретической физики в Лейдене.

Моя единственная модель организации программы для EDSAC в Кембридже, я последовал его внимательно при разработке программы обозначения, ввод, вывод и библиотеки для организации ARRA в Амстердаме. Для следующей машины, FERTA, ARMAC и X1, программы обозначения и вход бы очень следовать той же схеме: я, безусловно, был консервативным программиста. Добавьте к этому, что обучение буфера ARMAC с мощностью один трек из барабана, уничтожены однородности магазина, и вы поймете, что я не встать на приключения, как "autocoders".

В 1955 году я принял решение, чтобы не стать физиком-теоретиком, но и стать программистом, а не. Я принял это решение, потому что я пришла к выводу, что теоретической физики и программирования, программирование воплощенные больше интеллектуальный вызов. Видите ли, в те дни я не страдают от интеллектуальной скромности. Это было трудное решение, потому что я была ухоженной, как первоклассный ученый и стать программистом похож прощание с точки зрения науки. Когда я объяснил А. ван Вейнгаардена, мой тогдашний босс, моя дилемма, он сказал мне, что компьютеры были здесь, чтобы остаться и что в мире программирования я могу быть очень хорошо быть одна называется для создания науки, которая по-прежнему не хватает. Начало моей физики степени в Лейдене стал формальностью быть с как можно быстрее. (На самом деле я уже не чувствовал Добро пожаловать в Лейдене. Физиков считали меня как дезертира и математиков, один из которых открыто гордился ", конечно, ничего не зная о компьютерах", были просто презрительно)

В то же время картина возникла для сотрудничества между мной и моими коллегами аппаратных Брэма Дж. Loopstra и Карел S Схолтен. После функциональные спецификации следующей машины были записаны (как правило, меня), что документ служит своего рода договор между нами: он сказал им, что машина на проектирование и строительство, в то время я знал, что я мог рассчитывать на время написания всех Базовое программное обеспечение для машин. Цель этого разделения труда в том, что мои программы будут готовы к моменту строительства машина была завершена.

Оглядываясь назад, я теперь, что выше договоренность была глубокое влияние, как я вырос как программист: я нашел это совершенно нормально, чтобы программа еще не существующих машин. Как побочный продукт стал прочно укоренена в голову, что я запрограммирован для абстрактной машины, как указано в исходный документ, а не для фактического часть оборудования: оригинал документа не было, но описание рецепта, и в случае Расхождение не текст, но имеющемся оборудовании будет виноват.

В то время я считал это разделение труда и в результате практике программирования для несуществующей машины, как совершенно нормальное. Позже я прочитал статью американского о том, почему программа была всегда опаздывает, я помню, очень удивлен, когда я читал, что ограниченная доступность аппаратных было главной причиной, и я пришел к выводу, что обстоятельства, при которых я узнал программирования были менее распространены, чем я взял на себя.

Конечно, я не мог исключить из моих проектов опечатки и подобные огрехи, но таких недостатков не имеет значения, пока машина еще не был готов, и после завершения машины они могут быть легко определены, как только они проявились, Но этот последний утешительная мысль было отказано со мной в 1957 году с введением в режиме реального времени прерывания. Когда Loopstra и Схолтен предложил эту функцию для X1, нашей следующей машине, я получил видения моей программы вызывая невоспроизводимых ошибок и я запаниковал.

В конце концов, Loopstra и Схолтен польщен меня из моего сопротивления, и я изучил их предложение. Первое, что я исследовал был ли я мог бы продемонстрировать, что государственная машина могла быть сохранены и восстановлены таким образом, что прервал программ можно было бы продолжить, как будто ничего не случилось. Я показал, а не что она не может быть сделано, и моим друзьям пришлось изменить свое предложение. Правда сценарии, при которых первоначальное предложение не смогут были очень маловероятно, но это может иметь только укрепило мою уверенность, что я должен был опираться на аргументы, а не на эксперименты. В то время, что осуждение было, видимо, не настолько широко распространены, на срок до семи лет спустя я хотел бы найти недостатки в аппаратных прерываний новых коммерческих машин.

У меня был очень освещающей опыт в 1959 году, когда я задал моих коллег в Математическом Центре следующую задачу. Рассмотрим две программы, которые общаются с помощью атомно читает и пишет в общем магазине, они могут быть запрограммированы таким образом, что выполнение их критических секций исключают друг друга во времени? Решения пришел налива, но все не так, чтобы люди старались все больше и больше разработать контрпримеры для их опровержения, я должен был изменить правила: помимо программы они должны были руки в аргумент, почему решение было правильным.

В течение нескольких часов, Чт. Дж. Деккер передал в истинное решение с его правильность аргументов. Деккер впервые проанализировал доказательства обязательства, то выбрали форму аргумент, что бы встретиться с ними, а затем построили программы, к которой этот аргумент был применимо. Это был очень яркий пример того, как много теряется, когда роль математики сводится к проверке апостериори; в 1968 году я бы опубликовать документ под названием "конструктивный подход к проблеме корректности программ".

А потом был Алгол 60. Мы видели, что это проникает в 1959 году и реализовали его в первой половине 1960 года. Я ужасно боялась, для этой реализации было то, безусловно, мой самый амбициозный проект: Алгол 60 был настолько опередили свое время, что даже его создатели не знали, как осуществить это, я никогда не писал компилятор и должен был достичь своей цели с машины, которая была только 4096 слов хранения. (Последнее ограничение было, конечно, благом, но я не помню, что когда мы начинали.)

По сегодняшним меркам мы не знали, что мы делаем, мы не мечтал о каких-либо гарантий того, что наша реализация будет правильно, потому что мы хорошо знали, что нам не хватает теоретических знаний, которые потребуются для этого. Мы сделали единственное, что мы могли сделать в данных обстоятельствах, а именно. сохранить наш дизайн максимально простым и систематические, как мы могли бы и проверить, что у нас было избежать всех ошибок, которые мы могли думать. В конце концов мы узнали, что мы сделали ошибки, которые мы об этом не подумал, а ведь ремонт компилятор уже не настолько чист, как мы первоначально рассчитывали. (FEJ Kruseman Арец еще обнаруженных и исправленных количество ошибок, после того как я покинул Математический Центр в 1962 году.)

С самого начала мы предполагали два очень разных типов ошибок, ошибками записи, которых ремонт тривиально, и ошибки мышления, что бы отправить нас назад к чертежной доске, и различие помог нам, потому что один борется с ними по разным методикам. Военный прокурор Зонневельд и я combatted Дать ошибок кодирования вместе, каждый со своим собственным текстом перед ним, когда мы закончили, как наши тексты были кулаками самостоятельно, две ленты были сравнению механически, и около двух десятков расхождений ℄ если я правильно помню ℄ появился. Ошибки мышления мы пытались предотвратить, убеждая друг друга, почему предлагаемый раздел будет работать. В этом рассуждении мы могли бы обсудить основном работой компилятор, программа составлена была рассматриваться как данные, и этот опыт был полезен на потом, как это сделало нас привыкли к не-эксплуатационных соображений текстов программ.

Весь опыт сделал меня чувствительны к тому, что позднее будет называться модуляризации или разделяй и властвуй или абстракции, к уходу с которыми интерфейсы были выбраны и потенциальные сферы программирования задача в целом. Он сильно способствовал моему последующих мнение, что создание уверенности в правильности его дизайн был наиболее важным, но трудным аспектом с задачей программиста. В мире, одержимых скоростью, это не универсально популярное мнение.

Я помню те дни две дизайн принципах, которые мне хорошо с тех пор, а именно.

(I), прежде чем приступать к действительно значительным проектом, в частности, перед началом крупных инвестиций кодирования, попытаться убить проекта во-первых, и

(II) начинаются с самых сложных, наиболее рискованной части первой.

Моя первая программа испытаний была почти пустой блок, скажем,

начать реальный X конец,

не самый сложный пример, но моем 4 тест двойная сумма, в которой вложенные вызовы суммирования рутинной были введены с помощью параметра механизма, а суммирование рутинной сама была определена рекурсивно. Попутно мы показали справедливость что стало известно как S устройств Дженсен.

После этой реализации Interlude я вернулся в довольно общих чертах остается открытым вопрос о надлежащей координации в принципе асинхронных компонентов. Без непосредственного участия я видел несколько лет назад усилиями связи всех видов оборудования перфорированные карты X1 и был в ужасе от степени сложности введено включение в режиме реального времени обязательств. Ради простоты "Поэтому я настаивал на" вечные "конструкции, правильность которого может быть создана дискретными рассуждения только.

Почти неизбежно модель взаимодействующих процессов последовательного появились: последовательные процессы с (по определению!) Неопределенная относительных скоростей и, следовательно, для их сотрудничества, оснащенный некоторые примитивы для синхронизации.

Другая возможность для упрощения был представлен признание того, что сроки аспекты между частью коммуникационного оборудования и программы, которые использовали его полностью симметричной между двумя и независимо от того, у нас был вход или выход устройства. Излишне говорить, что это объединение помогло.

Когда мы были вовлечены в разработку мультипрограммирования системы, расширения медленно стал все более и более явной обеспокоенностью. Он должен был. В IBM, и, возможно, в другом месте, а, к нему в качестве предполагается закон природы, что "сложность системы", в некоторых неофициальных смысле будет расти пропорционально квадрату числа компонентов; мотивах его был прост ℄ каждого компонента могут мешать друг другу компоненты и т.д. ℄ но если бы это было правдой было бы де-факто исключают системы за определенного размера. Это вызвало мой интерес к системам структурирован таким образом, что "сложность системы" в том же смысле неофициальных не будет расти более чем линейно с размером. В 1967 году, выражение "слои абстракции" вошел компьютер жаргон.

Позвольте мне в заключение обсуждения этого эпизода, процитировав последние два предложения EWD123 "Сотрудничество последовательная обработка" (сентябрь 1965):

"Если эта монография дает любому читателю четкое указание о том, какой иерархической упорядоченности может быть как ожидается, будет уместно, я пришел один из моих самых близких целей. И пусть мы не надеемся, что конфронтация с тонкостях Мультипрограммирование дает нам четкое понимание того, что Uniprogramming это все о?

В 1968 году я страдала от глубокой депрессии, частично вызванный департамента, который не принял информатики как имеющие отношение к его призвание и распустил группу я создал, и отчасти вызвано мое собственное колебаний, что делать дальше. Я знал, что в ретроспективе, реализации Алгола и мультипрограммирования системы была только ловкость и упражнения, что теперь я должен был решать реальные проблемы, как сделать сложные вещи. В моем подавленном состоянии он взял меня месяцев до набраться смелости, чтобы написать (по терапевтическим причинам) EWD249 "Заметки по Структурное программирование" (август 1969), он положил начало моего выздоровления.

Он пытается синтезировать вышеупомянутых компонентов предыдущее десятилетие. Он упоминает о ранних странице "Структура программы в связи с убедительной демонстрацией правильности программы", упоминается как наши умственные СПИД "1) Перечисление, 2) математической индукции, 3) абстрактное", и о первой и Последнее я цитирую (с EWD249-14)

"Нумерационное рассуждения все в порядке, поскольку она идет, но, как мы довольно тупой это не очень далеко зайти. Нумерационное рассуждения только адекватных психических инструмент под тяжелой граничное условие, что мы только использовать его очень умеренно. Мы должны ценить абстракции, как наши основные психические техники уменьшить требования, предъявляемые перечисления рассуждения. "

У меня было два внешних раздражителей: в 1968 году НАТО конференция "Программная инженерия" в Гармиш-Партенкирхен и основания ИФИП Рабочей группы по методологии программирования ". Благодаря вездесущим ксерокс, мой машинописный текст может распространяться, как лесной пожар, и он сделал это, вероятно, потому, что люди нашли освежающий в сложившейся культуры характеризуется 1968 года IBM рекламы в Datamation, что представлены в полном цвете сияющий Сузи Майер которые решить все ее проблемы программирования путем перехода на PL / I. По-видимому, IBM не любил популярность мой текст, он украл термин "Структурное программирование" и под ее эгидой Харлан Д. Миллс тривиализуется оригинальной концепции к отмене доЬо.

Оглядываясь назад, я не могу не заметить, мой страх формальной математики в то время. В 1970 году я провел более чем десятилетие надеясь и то, рассуждая, что программирование бы и должна стать математической деятельности, я был (повторно), расположенных задачи программирования, с тем чтобы сделать его лучше поддается математической обработке, но тщательно избегать создания необходимых математике себя. Мне пришлось ждать Боб Floyd, который заложил основу для Джим Кинг, который показал мне первый пример, который убедил меня, и для Тони Хора, который показал, как семантика может быть определена в терминах аксиомы, необходимые для доказательства свойств программ, и даже тогда я не видел значение своей работе немедленно. Я был очень медленным.

Наконец рассказ для записи. В 1968 г., Сообщения ACM опубликовала текст мину под названием "доЬо считались вредными", который в последующие годы будет наиболее часто ссылаются, к сожалению, однако, часто, авторы которых не видела больше, чем его титул, который стал краеугольным камнем моей славы, став шаблона: мы хотели бы увидеть все виды статей под названием "X считается вредной" практически для любого X, в том числе один с названием "Дейкстра считались вредными". Но что случилось? Я представил документ под названием "дело против доЬо", который, в целях ускорения ее публикации, редактор изменилось в "Письмо в редакцию", и в процессе он дал ей новое название его собственное изобретение! Редактор был Никлаус Вирт.

Nuenen, 10 июня 2001

prof.dr Эдсгер В. Дейкстра
Факультет компьютерных наук
Техасский университет в Остине
Остин, штат Техас 78712-1188


Транскрипция Вольфганга Хоубен.
Последняя редакция на Mon, 21 апреля 2008.

Продолжение следует

Автор:  Info21 [ Суббота, 16 Октябрь, 2010 14:55 ]
Заголовок сообщения:  Re: Что сказал Дейкстра в конце жизни


Слово Editor: -- это просто стандартное обращение к редактору.
Письмо принято кому-то конкретно писать.
Посмотрите сейчас разделы писем всяких Nature и т.п. -- там такие же обращения, либо Editor:, либо Sir:.

Автор:  Info21 [ Суббота, 16 Октябрь, 2010 15:07 ]
Заголовок сообщения:  Re: Что сказал Дейкстра в конце жизни

Владимир Паронджанов писал(а):
Недавно я прочитал материал Дейкстры, который меня очень озадачил.
Дейкстра отрекается от названия "GOTO Statement Considered Harmful"
(Оператор GOTO считается вредным (опасным)".
И подчеркивает, что он дал статье другое название. Но редактор журнала
Никлаус Вирт убрал заглавие Дейкстры. И назвал статью (письмо
в редакцию) по-своему.

Короче, название "GOTO Statement Considered Harmful" придумал
не Дейкстра, а Вирт.

У меня возник вопрос: зачем Дейкстра пишет об этом? Причем, он пишет это
в конце жизни. Примерно за год до смерти.
Я обращаюсь к участникам нашего форума.
Что вы думаете по этому поводу? Каково ваше мнение?
Это знаменитая статья.
На старости лет люди пишут мемуары о своих подвигах.
Почему бы не сообщить людям такой любопытный фактоид. Добавить аромату.

Так что никакого особенного "зачем" тут выдумывать совершенно нет нужды.

Но более того, фраза "considered harmful" стала очень популярным мемом и приклеивалась к чему угодно.
И вполне возможно, что Дейкстра, будучи человеком, судя по всему, прямым и честным, просто отдал должное настоящему автору мема. Что особенно уместно сделать перед смертью. Он умер, кажется, от рака, а это не бывает неожиданным, и в Америке от пациентов не скрывают диагноз и прогноз, чтобы человек мог уладить дела с завещанием и собственностью, а не оставлять детей на милость случайностей и адвокатов.

Кстати, что это Вирт придумал название, было, если я не ошибаюсь, известно в кругу этих людей, что называется, всегда на уровне анекдота.

Автор:  Владимир Паронджанов [ Суббота, 16 Октябрь, 2010 15:11 ]
Заголовок сообщения:  Re: Что сказал Дейкстра в конце жизни

Это мое последнее сообщение.

Сначала я повторю последний абзац (по английски) из архивного
материала Дейкстры.
А затем переведу его.

Finally a short story for the record. In 1968, the Communications of the ACM published a text of mine under the title "The goto statement considered harmful", which in later years would be most frequently referenced, regrettably, however, often by authors who had seen no more of it than its title, which became a cornerstone of my fame by becoming a template: we would see all sorts of articles under the title "X considered harmful" for almost any X, including one titled "Dijkstra considered harmful". But what had happened? I had submitted a paper under the title "A case against the goto statement", which, in order to speed up its publication, the editor had changed into a "letter to the Editor", and in the process he had given it a new title of his own invention! The editor was Niklaus Wirth.

Nuenen, 10 June 2001

В заключение короткий рассказ о том, что было в 1968 году. Журнал Communications of the ACM опубликовал мой текст под названием "Оператор GOTO считается опасным". В последующие годы этот текст часто цитировали. К сожалению, зачастую это делали авторы, которые увидели в нем не больше, чем сказано в заголовке. Этот заголовок стал краеугольным камнем моей славы (известности). Дело превратилось в шаблон. И стало похоже на статьи типа "Х считается опасным", включая "Дейкстра считается опасным".

Но что произошло? Я подписал статью под названием "Обвинение против оператора GOTO". Чтобы ускорить публикацию, редактор превратил мою статью в "Письмо к редактору". В процессе этого он (редактор) дал моей статье название собственного изобретения. Редактором был Никлаус Вирт.

Эдсгер Дейкстра

Возможно, мой перевод содержит ошибки. Прошу их поправить.

Автор:  Info21 [ Суббота, 16 Октябрь, 2010 15:18 ]
Заголовок сообщения:  Re: Что сказал Дейкстра в конце жизни

Владимир Паронджанов писал(а):
"A case against the goto statement"
"Дело против оператора GOTO".
Переводя на русский, следует помнить, что слово case в данном случае несёт смысл "обвинение".

Так что попытки что-то тут вычитать между букв в пользу GOTO -- неосновательны.

Автор:  Rifat [ Суббота, 16 Октябрь, 2010 15:36 ]
Заголовок сообщения:  Re: Что сказал Дейкстра в конце жизни

Основная тема данного топика о том, почему Дейкстра отрекся от названия.
На самом деле, я не считаю, что он "отрекся". Текст не передает эмоции, поэтому можно не правильно понять, что имел в виду автор.
Лучше один раз увидеть, чем сто раз услышать :)

На youtube.com есть видео с записями Дейкстры.
Откройте, Structured Programming - Part 5 of 5 http://www.youtube.com/watch?v=40CNRVHLt7A&NR=1 и посмотрите с 4:20 по 6:35.
В начале Дейкстра говорит, а сейчас "short story", то есть по идее, как бы рассказ об интересном факте, а не о том, что он отрекается или сожалеет, наоборот, он как бы делиться своим успехом, с тем, кто ему в этом помог. It is my opinion.

P.S. У Дейкстры много EWD на английском языке, было бы хорошо перевести их все на русский язык, можно найти какой-нибудь сайт для совместных переводов и переводить сообща.

Автор:  Владимир Паронджанов [ Суббота, 16 Октябрь, 2010 15:46 ]
Заголовок сообщения:  Re: Что сказал Дейкстра в конце жизни

Уважаемый Федор Васильевич!

Спасибо за указание на ошибки и неточности.
Я, разумеется, все исправил

Автор:  Владислав Жаринов [ Воскресенье, 17 Октябрь, 2010 04:56 ]
Заголовок сообщения:  О направленности обсуждения Дейкстры

Уважаемый Владимир Даниелович!
Интересно проследить точку зрения такого специалиста, как Дейкстра, на протяжении жизни. Вместе с тем нужно отметить следующее. В цитате из этого сообщения как-то внешне непротиворечиво противопоставление "неэргономичный текст - эргономичная графика" переходит в "позитивные произвольные (с допущением явных БП) шампур-структуры - негативные структурные текстовые конструкции". Это вызывает следующие возражения.
Первое. Нужно противопоставлять отдельно по каждому основанию. Тогда мы увидим, что Дейкстра предлагал и графовый вариант своих структурных конструкций - о чём Вы говорили в /Паронджанов, 2001, Гл.16/. Там Ваша т. зр. вполне рациональна - Дейкстра предложил эргономически неоптимальные варианты визуализации, Вы в шампур-методе их улучшили. Здесь же всё говорится о тексте, и конструкции Дейкстры без БП именно "как текстовые" предлагается "отправить на пенсию". Отсюда и такие вопросы:
Илья Ермаков в viewtopic.php?p=52406#p52406 писал(а):
Таким образом, и этот абзац уже оказывается ни к чему:
• Дисциплина программирования Дейкстры является неоправданно
жесткой. Она вводит излишние запреты и лишает программиста
свободы. Образно говоря, она заковывает программиста
в кандалы и затрудняет его работу.

Поясняю, почему: он даёт впечатление, что было сначала чрезмерно сильное и неверное ограничение, а вот теперь "вернулись немного назад". Но ведь это не так! Двумерное структурное идёт вперёд, а не назад. Оно решает некоторые проблемы, вводит некоторые структуры, которые раньше ещё не были придуманы. Ограничения, которые существовали, не были неверными, они просто были для текста единственно возможными. Появилась возможность их снять - и она была Вами реализована. Вот и всё. Ровный, уверенный, логичный шаг вперёд, без каких-то "откатов" и "возвратов". Разве нет?

Второе. О явности различных типов переходов. Что естественный переход показывается на графе алгопроцесса звеном вертикали - уже говорил. Да, в тексте на ЯВУ мы его только подразумеваем - но это в тексте, и эти претензии на графовую структурную запись переноситься не могут.
Какова роль явного БП? Думаю, прежде всего учебная - при разборе реализации алго/прогязыка, исследовательская - при изучении преобразований маршрутных структур. В практической визуализации деятельности нужны только те переходы, которые представлены явно в дракон-силуэте и неявно - в составных атомах (точками слияния). Необходимость лианных блоков вызывает сомнения - см. ниже.

Третье. О доказательности. Сколько-нибудь сложный материальный объект - мост, здание, трубопровод - перед созданием почему-то рассчитывают :) - почему нужно отказывать в этом информатическим объектам? В частности, алгоритмы тех же инженерных расчётов подлежат визуализации - напр. по шампур-методу - но визуализации доказательной, допускающей верификацию. Для конструкций Дейкстры такая возможность есть - а что в этом смысле можно сказать о конструкциях с произвольными БП? Мне известно (из Карпова) только то, что можно верифицировать маршрутные структуры с заменителями (т.к. Promela допускает break и continue), сочинённые неформально - но ничего не известно о том, что можно формально вывести такие структуры из формальной постановки задачи. Зато обратный пример на "структурирование промышленного цикла" есть...
Поэтому пересадки лиан при формальной визуализации считаю возможными, только если будет доказано, что можно формально выводить лианные структуры также, как атомарные.

Не является ли занятая позиция следствием того, что в настоящий момент Вы не готовы принять необходимость проектировать сколько-нибудь сложные процессы расчётно-логическим путём? Но можно ведь двигаться в направлении визуализации самих методов проектирования, о чём уже говорил в этом сообщении...
Этому есть и организационно-правовые основания. Считаю, если "для себя и узкого" круга "предметник" может создавать описания деятельности неформальным методом - то, когда эти описания становятся предметом договорных отношений (в частности, заказа решений по информатизации деятельности), описания должны становиться доказательными. Делать это может и специалист-аналитик - но его тоже нужно готовить к этому. И никакими "кандалами" это считать не следует - а освобождаться нужно от неэргономичной записи доказательств и методов их получения. Давайте к этому и двигаться...

Автор:  Владимир Паронджанов [ Воскресенье, 17 Октябрь, 2010 09:28 ]
Заголовок сообщения:  Re: О направленности обсуждения Дейкстры

Уважаемый Владислав!

Вы дали мне повод ответить Вам здесь,
а не в теме "Эдсгер Дейкстра и язык Дракон".

Уважаемые коллеги!

Сердечно благодарю всех, то высказал критику моего текста
в теме "Эдсгер Дейкстра и язык Дракон".

Обдумав критику, я пришел к выводу, что мой текст неудовлетворителен.
И поэтому должен быть удален из уже вышедшей книги.

Более того, я уже договорился с издателем, что при допечатке
или переиздании тиража в книгу будут внесены изменения.

Конечно, об этом следовало сказать в теме "Эдсгер Дейкстра
и язык Дракон". Но там продолжаются интересные сообщения
и обмен мнениями. И мне не хотелось прерывать этот разговор.
Поэтому я решил подождать, чтобы не мешать ведущейся там
плодотворной дискуссии.

Уважаемый Владислав!

Возможно, Вы считаете, что некоторые из поставленных Вами
вопросов остались без ответа.
Если да, прошу Вас задать их еще раз.

Предполагаю (но не утверждаю), что самое серьезное из Ваших возражений --
это вопрос о необходимости лианных структур.

По моему мнению, это вопрос очень важный. И его не следует обсуждать
на бегу, в случайной теме.

:arrow: Буду очень благодарен, если Вы откроете НОВУЮ тему под названием
"Нужны ли лианные структуры?"

:arrow: Буду рад, если Вы в этой теме повторите все ваши возражения и сомнения
о необходимости лианных структур.

:arrow: Было бы замечательно, если бы Вы сочли возможным изложить
Ваши соображения (возражения, сомнения и т.д.) в виде
ПРОНУМЕРОВАННОГО СПИСКА и подробных комментариев к каждому
пункту (без отсылки к другим материалам, как Вы обычно делаете).

С уважением и благодарностью за Ваш огромный и бесценный труд
Владимир Паронджанов

Автор:  Владислав Жаринов [ Среда, 20 Октябрь, 2010 05:43 ]
Заголовок сообщения:  Re: О направленности обсуждения Дейкстры

Владимир Паронджанов писал(а):
Уважаемый Владислав!
...По моему мнению, это вопрос очень важный. И его не следует обсуждать
на бегу, в случайной теме.[/b]

:arrow: Буду очень благодарен, если Вы откроете НОВУЮ тему под названием
"Нужны ли лианные структуры?"

:arrow: Буду рад, если Вы в этой теме повторите все ваши возражения и сомнения
о необходимости лианных структур.

Открыта тема: viewtopic.php?f=78&t=2919&start=0

Автор:  Владислав Жаринов [ Среда, 20 Октябрь, 2010 17:47 ]
Заголовок сообщения:  О насущных вопросах инженерной визуализации

Владимир Паронджанов писал(а):
Уважаемый Владислав!

Возможно, Вы считаете, что некоторые из поставленных Вами
вопросов остались без ответа.
Если да, прошу Вас задать их еще раз.

Предполагаю (но не утверждаю), что самое серьезное из Ваших возражений --
это вопрос о необходимости лианных структур. ...

Буду очень благодарен, если Вы откроете НОВУЮ тему под названием
"Нужны ли лианные структуры?"

Как показано в новой теме, речь идёт не о полном исключении, а об определении границ применимости структур. В то же время считаю более актуальным вопрос о представлении взаимодействия алгопроцессов.
Имею в виду, что в АО принят механизм условных критических интервалов (AWAIT), а в техноязыке, как и в специф-языке Promela для ModelChecking-верификации (конкретно - в среде Spin) - рандеву по сообщениям (send/receive). Кто сможет предложить гармонизацию этих механизмов, чтобы корректно переходить от модели с интервалами к модели с рандеву? Пока обсуждение систем процессов (называвшихся то "паралельными", то "независимыми") этого вопроса не касалось...

Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group