{'fraction_non_alphanumeric': 0.01867816091954023, 'fraction_numerical': 0.00305316091954023, 'mean_word_length': 5.140022050716648, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Computers-The software situation.

Programming is to computer science as instrumentation is to experimental science. It is the technical preliminary without which the larger enterprise will not go. Besides its role in computer science, programming plays a significant industrial role. It occupies the attention of 250,000 people within the United States and therefore is a large industrial enterprise. Programming is also the part of the computer enterprise that has gone less well than the hardware aspects. The general difficulty of programming comes from the fact that it is concerned with the construction of objects of extraordinary complexity compared to any other objects that have been built As a regular matter one deals with texts of 105 or 106 separate instructions, which is to say that one is attempting to set computer control patterns which may require something in the neighborhood of 30 X 106 or more bits of information to be set with absolute precision. This problem of complexity is fundamental to the programmiing enterprise. The basic response to it is the definitionand also implementation, because mathematical definition and implementation for purposes of experimentation must go hand in hand here-of a conceptual framework for each specific area of programming, within which its most characteristic complications are dealt with systematically. Once defined, such a framework allows the programmer's attention to focus not on the characteristic difficulties of an area but on the details that are special to his application. It is important to deal uniformly with the interconnections between the logical elements of the problem, thereby dismembering the problem into separate small pieces that can be managed independently. Once one has gotten in position to break an overall problem into this kind of fragmented rubble, it becomes easy to manage simply by accretion, but if things are intricately interwoven, it may be impossible to deal with them at large scale. One also has to develop a systematically layered approach, allowing the final product-some efficient final program or bit pattern-to evolve, by carefully controlled and mutually related stages, from an initial very abstract statement of what is to be done to its final implementation. Several major areas of programming have been studied well for at least their essential characteristics to be understood, and I would like to describe these at least briefly. One important distinction is that between monoprocess and multiprocess programming. Monoprocess programming is thecreation of a program, let us say in FORTRAN or BASIC, that does one thing at a time and is relatively simple. Multiprocess programming is characteristic of operating systems that run other jobs within large computing systems, of real-time systems that have to manage experimental or industrial equipment (which has its own timing constraints), and, to an increasing extent, of laboratory systems in which multiple processes need to run concurrently. Monoprocess programming is simpler logically and much easier to manage than multiprocess programming. Our understanding of it begins to be reasonably well organized. It is dominated by the trade-off betweenefficiency and expressivity. At the extreme expressivity end, one can work with abstract, high-level languages that say succinctly and in a kind of mathematical style what one wants to have done. On the efficiency-oriented end of the same spectrum, one finds reexpressions of those same initial specifications, but in forms that contain numerous detailed hints for attaining the same results in a much more efficient manner. Multiprocess programming, which is newer, much more complicated, and much less well understood, is dominated by the need (i) to synchronize the use of data objects that have to be shared by multiple competing processes, all running in temporal parallelism, (ii) to avoid deadlock among these processes, any of which may need to access objects that other processes are currently using, and (Mi) to preserve one's ability to respond rapidly to external events which may require immediate response. Thus, one main axis of programming is that which runs from the simpler monoprocess programs to the more complex multiprocess programs at the other end. Another significant distinction is that between systems of cooperating processes and systems of mutually suspicious processes. For example, within a laboratory system that has an integral purpose and design, one can assume (since presumably one author or some small group of authors has written all the code in that system) that the processes intend to cooperate and, if error-free, will cooperate. In larger systems-in particular, in operating systems or systems accessible from many points-this may not be a viable assumption. For example, an operating system must be able to handle programs that are erroneous, either because the programmer made some honest error or because he was malicious-e.g., was tying to get into parts of the system that he had no right to access. Of course, it is much easier to write cooperating systems of processes than mutually suspicious systems of processes. Nevertheless, one may have to administer mutually suspicious processes. To do this one requires logically well-defined systems of prohibitions, permissions, and capabilities which control what each process is allowed to do and ultimately what the responsible user of each process is allowed to do, in a way that is impossible to subvert. This also is a very important consideration