domain: info shs

text:
Liesbeth De Mol

Maarten Bullynck

What's in a name? Origins, transpositions and transformations of the triptych Algorithm -Code -Program. 1

The historical origins, re-appropriations and transformations in different discourses and practices of three connected and basic notions of computing, Algorithm -Code -Program are studied. These interconnected terms have a complex history and cannot be reduced to one meaning only, even today. 2

Introduction

Words such as "code", "program" and "algorithm", once specific to specialist technical discourse, now belong to popular discourse. They are used everyday to talk about what lies "underneath" technological products like Amazon, Facebook or Google. "Coding" and "programming" are considered important "skills" to teach our children and "algorithms" allegedly rule our world. But these words are not constant in meaning, they have a history and impact how history is or can be written. 3 Forgotting about their historical dimensions may lead to anachronisms, wrong interpretations or Whig history. As Karine Chemla has noted 4 : Historians often worked under the assumption that the main components of scientific text problems, algorithms and so on are essentially ahistorical objects, which can be approached as some present-day counterparts. This insight also applies to everyday usage. 5 For instance, the current usage of "algorithm" in popular and scientific discourse often no longer refers to some mathematical object but rather to what one used to call software or programs, e.g., the so-called Facebook algorithm. The mathematical origin of the word helps to obscure human bias (so-called "algorithmic" bias) and commercial interests behind the software, aiding the industry in outsourcing their accountability. 6 This paper follows the historical origins, transformations and interrelations of the triptych Code, Program and Algorithm (and Software) to render these words historically transparent. 7 We show how the technologies of the 20th century reclaimed these words and reshaped their meanings. This happened in two phases. Around 1900 early automation made its mark on the words "code" and "program" first, then, after World War II, computing adopted these words.

1 This is a preprint and draft version of a chapter published as: L. De Mol and M. Bullynck (2022), What's in a name? Origins, transpositions and transformations of the triptych Algorithm -Code -Program, in: J. Abbate and S. Dick, Abstractionss and embodiments. New histories of computing and society, Johns Hopkins, 2022. 2 Both authors are supported by the ANR PROGRAMme project ANR-17-CE38-0003-01 3 Koselleck, R., Begriffsgeschichte, Suhrkamp, 2006 4 Chemla, K., 'On mathematical problems as historically determined artifacts. Reflections inspired by sources from ancient China', Historia Mathematica, vol. 36, nr. 3, 2009, pp. 213-246, here p. 213. 5 This also applies to everyday words such as "lurking", see Kushner's chapter in this volume. 6 For algorithmic bias see O'Niel, C.Weapons of Math Destruction: How Big Data Increases Inequality and Threatens Democracy. New York, NY: Broadway Books, 2016.; Eubanks, V., Automating Inequality: How High-Tech Tools Profile, Police, and Punish the Poor. New York: Macmillan, 2017.;Noble, S., Algorithms of Oppression: How Search Engines Reinforce Racism. New York, NY: New York University Press, 2018. 7 Some work has already been done on this, specifically on the origins of "program". See: Grier, D. A., "The ENIAC, the Verb 'to program' and the emergence of digital computers", IEEE Annals for the history of computing, vol. 18, nr. 1, 1996, pp. 51-55; Grier, D.A., "Programming and planning", IEEE Annals for the history of computing, vol. 33, nr. 1, 2011, pp. 85-87; Haigh, T. and Priestley, M., "Where code comes from: Architectures of Automatic Control from Babbage to Algol", Communications of the ACM, vol. 59, nr. 1, 2016, pp. 39-44. However, we have found new sources which locate the origin of "program" more exactly.

Asking "who uses the words" and "in what context" reveals the motives at play and the shifting objectives. The words are regimented to make new distinctions, sometimes reflecting a reality of relations on the workfloor, sometimes projecting a vision onto the workfloor or onto the division of labour and its possible automation (as in the "myth" of the coder, see section 4 of this paper). The words can be reminiscent of local working practices, but also vectors of managerial phantasies, they are symptoms of how the organization of labour is negotiated between technological conditions and human work and power structures. 8 Both the computing people themselves and the management put words in the field to further their agenda, e.g., "algorithm" to further computer science, or "software" to make a service more tangible. (see section 5) As all these words later became part of general everyday discourse, it is paramount to become conscious of the economic, industrial and scientific stakes that have been invested in those words in the past.

Origins and the first technological transfers

The words "code", "program" and "algorithm" were already part of the English vocabulary long before the first computers. They are derived from Greek or Latin roots and became proper members of the English reservoir of words in the 17th century during the Renaissance.

Algorithm

The word "algorithm" probably has the most intricate history. It was originally a latinized version of Al-Khwarizmi, surname of the Arab mathematician Abu Ja'far Mohammed Ben Musa (c. 780 -c.850). His treatise on the Hindu way of reckoning is now lost in its original Arabic version, but has survived in a number of medieval Latin translations of the 12th century. Typically, a medieval, hand-copied, manuscript began by "dixit"(said), "inquit" (said) or "scripsit" (wrote) followed by the name of the original author. In this case "dixit algorismus", Al-Khwarizmi said. As the first (relevant) word of the codex, the name of the author became the way to refer to this manuscript, its title in a sense. When the treatise was translated into the vernacular, the word algorismus lost its original meaning and with time, the word came to refer to the content of Al-Khwarizmi's treatise, the Hindu system of writing and calculating numbers (viz., our decimal positional system and its rules of computation).

From this meaning, it became used to refer to other systems of calculating, either extending the decimal positional form of computation or creating new forms analogous to it, such as the algorithm of fractions or proportions, or, later, the "algorithm of infinitesimal differentials" on the Continent or "algorithm of fluxions" in Newtonian England. In the famous priority dispute between Newton and Leibniz over the invention of the calculus, the algorithm of the calculus even became a point of contention in itself, the mathematician J.K. Hauff even claiming that while Newton invented the method, Leibniz invented the algorithm, 9 thus introducing a subtle differentiation between the conceptual solution of a problem (the method) and the material or notational implementation of that solution (the algorithm). The close assocation of notation and algorithm only loosens up during the 19th century, when mathematicians will use algorithm to refer to a schematic computational process or of a stepwise procedure. Algorithm thus became one of the words, alongside method, procedure, rule or calculus, mathematicians use to denote a (semi-)formalized (numerical) solution to a (mathematical) problem. 10

Code

The word "code" derives from the Latin word "codex", that is, a collection of texts, in particular law texts. In its transferred meaning, it also refers to a collection of rules to be followed, such as a code of honour or a recipe for preparing a certain medicine. In this sense, the original meaning of"code" in Europe was closer to "algorithm" in its actual understanding. Only in the 19th century "code" started being used for a system of signs to "encode" a certain information. It had been common practice in 18th century Europe to encrypt diplomatic or important commercial messages by one long word, e.g., the short word "shamefaced" stood for "sell at current market price". These words were collected in a book or in a codex. This practice became more widespread with the telegraph, especially in the U.S., these code words being both cost-efficient and secure. These codes were then "translated" into a so-called "telegraphic alphabet" and "telegraphic language", viz. combinations of long-short signals. "Code" later shifted to refer also to this telegraphic alphabet, e.g., Morse code or 8

The Baudot-Murray code. 11 When in the early 20th century punched cards were introduced for Hollerith machines and other unit record devices, the word "coding" was introduced to denote, by analogy, the process of translating questionnaires or data sheets into the "language of punched cards", holes and notches. 12 Program Finally, the word "program" was a 17th century neologism derived from the concatenation of the two Greek words πϱo (before) and γϱαφειν (writing), a pre-scription 13 , a written notice of things to come. "Program" thus describes the ordering of an activity like, for instance, the program of a concert or, more generally, a general plan or scheme of something to be done, like an itinerary, a training schedule, a production plan etc. The word became used, along with "plan" and "schedule", by management, economists and "planning departments" as part of a vocabulary to streamline and control industrial processes in the late 19 th century. 14 As "code" met up with telegraphy, so did "program" meet up with another technological advance in the late 19th century: "program(me) clocks" developed to "furnish a convenient and practical clock, that may be set to strike according to any required programme". 15 These devices automated time schedules or production plans, ringing at preset times on a factory work floor, at railway stations or in a school. With time, more complex and general "program devices" or "program machines" were invented to automate the operations of machines such as a paper cutting machines, a washing machine etc. "Program" came to stand for the automatic carrying out of a sequence of operations or as an automated scheduler.

Around that time, the word "program" was also picked up in the context of radio engineering. At first, a program referred to the physical program as transmitted within a broadcasting network. With the rapidly expanding broadcasting industry and increased network complexity, scheduling "programs" in different networks became an important problem. Any program had to be connected to the right station at the right moment at so-called "switching points" Originally, this was done by an operator who had to "listen for cues indicating the end of a program, and then operate the proper keys or change connections". 16. An increase in the number of switches made this impossible and the manual switching had to be (partially) automated through (relay) switching equipment. In this context, "program" steadily transposed from radio programs to be embodied by technology itself, with terms like "program circuits", "program trunks", "program switching", "program line", "program loop", etc. 17 Though all three words (algorithm, code and program) were items present in the language's lexicon since the 17th century, they were recycled in new contexts that were both specialist and technical already in the late 19th and early 20th century. 'Algorithm' lost its footing in notation to become a more general mathematical term as 'stepwise procedure', shifting from what Kenneth O. May has called "mathematical technology" to "mathematical science". 'Code' then, was taken up by the professional telegraph users to denote any form of compression of messages, be it through code words or (binary) code symbols. From there on, 'coding' became the verb to refer to the, often repetitious and boring, activity of translating language into code words or symbols for telegraphy, telephony or also card punching. Finally, 'program' entered the engineering discourse in the mid 19th century to talk about the automation of time schedules, production plans, or, later only, the switching of radio programs in a network and the automatic sequencing of operations. Thus, even before our three words became part and parcel of computing vocabulary, they had already migrated from their general meaning to usages in specialist and technological communities. From these, they will eventually spread to computing.

The second transfer of meaning under the sign of digital computing

The semantics of 'code', 'program' and 'algorithm' shifts into computing when it encounters the large electromechanical and electronic calculators of the 1940s, mostly built to help computing ballistic tables. In these machines, the traditions of business computing, scientific computing and military command and control meet up with the reliable relay and the pioneering electronics technologies of automation.

11

Friedman, W.F., The history of the use of codes and code language, Washington, 1928. 12 Herman Hollerith, The electronic tabulating machine The mathematical field now called 'numerical analysis' slowly emerged after World War , many groups and bureaus for (manual or machine-aided) computation developing their own techniques and workflows. 18 To refer to the computational procedure and its steps to be followed, the mathematicians involved sometimes used the word 'algorithm', sometimes 'rule', 'formula' or 'procedure', but the most common word was without a doubt 'method'.

While each computation group had its own ways of organizing computation, most of them had some kind of tiered process. First came the mathematical analysis of the problem (including finding the right 'method' in the literature), then the preparation of the problem for the human computers using a "computing plan", followed by the computation itself, taking down the results using "computing sheets" and finally checking the results. When this manual (or machine-aided) process was ported to large mechanical calculators such as the ASCC/Harvard Mark I or the Bell machines, there was continuity with these practices but replacing the human by a machine changed some things. Usually, mathematical analysis of the problem still came first. After that, the method had to be prepared in a form that allowed an easy set-up on the machine, finally the machine computation itself followed by error analysis and checking. In order to prepare a problem for set-up on the machine, one had to 'code' the computation in a form that was machine-understandable, on the other hand, one had to operate the machine during execution. This whole process from mathematical analysis (planning) to setting up the problem on the machine (coding) would eventually evolve in one of the definitions of programming in the 1950s. The widespread use of the word 'program', however, did not originate in this context.

Instead, the germ of what our modern word 'program' would become, lies in the application of automatic control to calculating machines. Already in the 1930s engineers had started to build 'program devices' (See Sec. 2) to control the sequence of operations in calculating machines. With the new complexities of time scheduling and radio broadcasting, also the automation of transfer of control or even conditional transfer of control had been achieved. As IBM engineer James W. Bryce describes in a 1937 patent: "Such programming means will enable the operator to program the sequence of transfers and to selectively route the transfers from any selected accumulator to any other selected accumulato" 19 . The IBM team that would develop the ASCC/Harvard Mark I with Howard Aiken applied this technology to the machine. As a consequence, they speak in the patent of a "program tape" (instead of the later "control tape") that "schedules the operations of the machine, selecting the functions and the sequences of their performance". 20 Further mention is made of a "print program", or a "multiplying program", but in the later ASCC/Mark I manual 21 these have disappeared and are now referred to as e.g. "multiplying sequences". Grace Hopper and other members of the ASCC/Mark I team would later speak of "coding routines" or sequences. The routines frequently needed would be stored in a "tape library" containing "control tapes [that] are of general application". 22 Thus, whereas the engineers, who were thinking in terms of the automation of control via program devices spoke of 'programs', Aiken and his team, who were coming from the mathematical and human side of the computation problem, spoke of "coding routines" or, more frequently, "sequences".

From a certain viewpoint, coding the ASCC/Mark I is the automation of a machine set-up. That development can be found in other contemporary machines too. Samuel Caldwell and Vannevar Bush devised a control mechanism to automate the set-up of their improved differential analyzer in the 1940s. 23 Before, the machine had to be set-up manually connecting all the right parts of the machine -a process that took several hours. Now, the connections, empirical data and initial conditions were all coded on tape which then controlled the automatic set-up of the analogue analyzer. The Bell machine relay calculators model III to V all had a battery of Baudot-coded tapes with both data and instructions to automatically set up the right calculation to be executed. All these machines, however, could only follow a sequence of coded instructions. Coded iterations and full automatic conditional transfers were, at least initially, not possible. 24 These control structures were, however, present on ENIAC once it was ready for service (1946). That machine differed fundamentally from its mechanical and analog contemporaries because it was electronic, providing a much higher speed of computation. However, in its original form, it had to be manually set-up, not unlike the original differential analyzer. It is here where the most momentous transfer of meaning to 'program' would happen. Mauchly's original short 1943 proposal for an "electronic computer" already referred to a "program device", which later became a 'program control unit" and evolved 18 Grier, D. A., When computers were human Princeton: The ASCC/Harvard Mark I would later have a conditional stop through a special device called the "Subsidiary sequence unit" which allowed the moderator to move the tape to another position, for loops they glued tapes together. For the Bell machines, iteration was present in Model III, conditional jumps only on Model V. into the ENIAC's "master programmer" which centrally controlled the local programming circuits for sequencing loops and conditionals. It is from there that the term in ENIAC developed, playing over different semantic extensions, referring both to individual (control) units (as in "program switches"); smaller pieces of an entire program (as in "program sequences"); or the complete schedule that organizes program sequences (as in a "complete program [for which] it is necessary to put [the] elements together and to assign equipment in detail"). 25 "Program" in this context always refers to how automatic control, locally or globally, is organized.

The practice of putting computations on the ENIAC, however, rapidly made the term 'program' drift further away from hardware to be transferred to the organization of a computation. In an appendix to a 1945 report entitled Remarks on programming the ENIAC, Eckert, Mauchly and others wrote about the entire "computational program" and how to " to link the elementary programming sequences into a complex whole" using an "elaborate hierarchy of program sequences" that could be built up with the master programmer and which relied on, what they call, "sub-routines" 26 . In another report written by Haskell B. Curry and Willa Wyatt planning for ENIAC to do ballistic calculations, the problem "is studied with reference to the programming on the Eniac as a problem in its own right" 27 . They develop a method where each computation is "broken into pieces, called stages" which are defined as "a program sequence with an input and one or more outputs." Linking together the inputs and outputs, smaller program sequences could be combined into more complex programs and a general "schedule" of programs could be translated into wiring diagrams that indicate how ENIAC should be set-up. The semantics of the "program device" discourse is still at play here, but generalizes from the sequencing of operations to include also the scheduling of sequences of operations.

The intricacy and time-consuming process of manually setting up the ENIAC for computation and the sheer speed of the machine, led to ENIAC being rewired, resulting in an automation of the set-up process. In this new configuration, a sequence of coded instructions could be introduced on ENIAC, through the setting of switches or the reading of punched cards. 28 Now the logic of linking elements together in a program that automatically controlled the machine could be done through symbolic encoding. As a result, the word 'program' slowly transferred even further from hardware towards what is now called software.

It is commonly known that the word "program" in its current meaning comes from ENIAC. 29 But it is the encounter of automating sequences and scheduling with calculation that put "program" there in the first place. Actual practice then made "program" shift further, from actual hardware to the configuration of that hardware. It is in that sense that Douglas Hartree defines "program" as "the process of drawing up a schedule of the sequence of individual operations required to carry out the calculation". 30 Compared to the Harvard Mark I team, Hartree is less focusing on planning and coding sequences (viz. the work of the human computer and its translation to the machine), but rather on how to translate the plan into a configuration of the program device that will start the required operations, either in the form of wiring diagrams or in the form of symbolic coded instructions.

Shifting frontiers in the 1950s

The work on computing in the 1950s towards reliability, mass production and standardization is also reflected in the attempts to define basic terms in glossaries and shape common practices. Looking at usages and definitions of 'program' and 'code' in different professional and local contexts brings out how fluid their meanings still are in the 1950s. Especially the development of automatic coding or programming in the mid 1950s impacted on the semantic envelope of these words.

Looking at the influential work by Goldstine and von Neumann 31 , they do not use the word 'programming', but instead differentiate between planning and coding of a problem. After the mathematical preparation of a problem, a flow-diagram is introduced to plan a coded sequence which is then used to derive the coded sequence. This distinction was often picked up, Goldstine, H.H., and von Neumann, J., Planning and coding of problems for an electronic computing instrument, Volume 2 of Report on the mathematical and logical aspects of an electronic computing instrument, part I,II and III, 1947-48, Report prepared for U. S. Army Ord. Dept. under Contract W-36-034-ORD-7481. but with the important shift that 'programming' would then be used too, referring to the whole process of planning, flowcharting and coding, whereas 'coding' would now be reduced in meaning to the machine coding part only. This is the distinction one finds the 1954 ACM Glossary, viz., Code (verb): to prepare problems in computer code or in pseudocode for a specific computer. Program (verb): to plan a computation or process from the asking of a question to the delivery of the results, including the integration of the operation into an existing system. Thus programming consists of planning and coding 32 Some definitions restrict 'programming' further and contrast it with 'coding, e.g. the Bureau of Standards in 1948 define 'program' as a "general verbal description of the method of solving a particular problem on a computer". This is even more pronounced in the IBM glossaries of the 1950s, for the IBM 650, one author even writes: "Programming and flow charting are synonymous -the remainder is mere coding." 33 This shows that 'programming' has shifted once more in the 1950s. From structuring automatic control, in some contexts it can now generalize to the whole process of planning and coding or, in some cases, even be restricted to one aspect of planning, viz., flowcharting.

While a strict differentiation was made between flowcharting and coding, usually, coding was subsumed under programming. Or, put differently, coding was just another task of the programmer besides flowcharting. This becomes explicit in a 1951 discussion: L.A. Ohlinger (Northrop Aircraft Compay): I would like to ask how many programmers and coders are employed in order to keep UNIVAC busy full time? J.L.McPherson: We do not distinguish between programmers and coders. We have operators and programmers. 34 Indeed, while both activities of flowcharting and coding can be distinguished in theory, they cannot in practice, the same person has to do both.

However, classic computing history has it that a distinction between the jobs of 'programmer' and 'coder' existed already in the 1950s, the first being occupied with problem analysis and flowcharting, the latter with porting the flowchart to the machine. 35 In practice, however, no such distinction appears and even a report from the United States Department of Labor describing the Occupations in electronic data-processing systems 36 , identifying no less then 13 different occupations in electronic data processing, only uses "coder" in reference to "coder clerks". These are people who "convert items of information obtained from reports and records to codes for processing by automatic machines", viz. the people who already coded information in the beginning of the 20th century. The coding of instructions, however, is considered to be part of the job of the programmer. What did exist was a distinction between the chief programmer or systems analyst and junior programmers. Evidently, it is reasonable to assume that flowcharting was more in the hands of the former and coding more in the latter category, even though a neat separation in practice was impossible.

It thus seems a fair question to ask where the 'myth' of the coder comes from? The answer lies in Grace Hopper's influential talks on automatic coding or programming. 37 Hopper remarks that "the analyst, programmer, coder, operator and maintenance man were separated", though, admittedly, the "distinction between a programmer and a coder has never been clearly made". Her distinction is, a programmer "prepares a plan for the solution of a problem" (viz., a flow chart), while a coder has "to reduce this flow chart to coding, to a list in computer code." The motivation for this, self-admitted, artificial separation, becomes clear in the rest of the paper: "It is this function, that of the coder, [...] that is the first human operation to be replaced by the computer itself." Thus it is the introduction of "automatic coding" (sometimes also unfortunately called "automatic programming") that accounts for a retrospective, artificial distinction.

This observation helps to explain the different ways 'coding' and 'programming' are used. In UNIVAC and IBM circles usage was mostly according to the definitions quoted above, 'coding' was translation into machine code, 'programming' was either everything from planning to coding, or the part before coding, viz. planning and flow charting. This is in part a reflection of the hierarchy on the working floor of a commercial computer installation. In other places, especially at universities, both words are used interchangeably or coding is subsumed under programming. The ambition there was often to make the computer accessible to every user, in particular scientific users not necessarily versed in engineering and 32

First ACM Glossary prepared by a committee, chairwoman machine details. This contrasts with commercial computer installations where the user had to pass through the programmers and operators to get his work done on the machine.

A symbolic 'readable' way of programming the machine directly after problem analysis, was first championed by Hartree or Wilkes in the U.K. 38 or Zuse and Rutishauser in Germany and Switzerland. On the EDSAC a symbolic assemblerlike code was developed so "the machine may be said to understand the same language as a computor". [START_REF] Wilkes | Programme Design for a High-Speed Automatic Calculating Machine[END_REF] Or, quoting Aleck Glennie on his Autocode system for the Manchester Mark I, "we must make coding comprehensible, [t]his may be done only by improving the notation of programming." [START_REF] Glennie | The Automatic Coding of an Electronic Computer[END_REF] Similarly, at M.I.T.'s Whirlwind it was decided early on to make the computer available to the "casual user" through "automatic standard subroutines" that "can be used almost as easily as an equivalent built-in order, with resultant saving in the programmer's time." Eventually this resulted in one of the first "automatic coding systems", "a comprehensive system of service routines [...] to simplify the process of coding." 41 With "automatic coding systems" of the 1950s 'coding' becomes less of an issue and 'programming' increasingly is the focus of human effort. This is tangible in the definitions of 'program'. In November 1952 a 'program' on the Whirlwind is defined as a " program is a sequence of actions by which a computer handles a problem", a definition still close to Hartree or the EDSAC team, and a 'coded program' is a "set of instructions that will enable a computer to execute a program." 42 In December 1952 then, now with automatic coding, it becomes a " program is an ordered sequence of words, written with the intention of having it typed on paper tape in the (new) Flexocode and inserted in [Whirlwind I] by the intermediary of the Comprehensive Conversion Program". 43 This shift suggests the one that will happen later, end of the 1950s, when so-called 'programming languages' would become used and 'program' will become a 'text' in those languages.

Commercial computer firms investing in automation of the programming process such as IBM or UNIVAC undergo the same evolution. The IBM FORTRAN system is "a IBM 704 program which accepts a source program in a language [...] resembling the ordinary language of mathematics, and which produces an object program in 704 machine language, ready to be run." Thus, "A FORTRAN source program consists of a sequence of source statements, of which there are 32 different types." [START_REF] Backus | THe FORTRAN Automatic Coding System for the IBM 704[END_REF] Equally, Univac's FLOW-MATIC is described as shifting "the programming effort from detailed coding to problem definition and system analysis", and MATH-MATIC "describes the problem from the user's standpoint, rather than the program required by the hardware of the computer": As a consequence writing FLOW-MATIC or MATH-MATIC 'programs' amounts to writing 'sentences' and the "conversion of the problem, expressed in pseudo-code, into the necessary program, in machine code, is performed entirely automatically and internally". [START_REF] Ash | Preliminary Manual for MATH-MATIC and ARITH-MATIC Systems for ALGEBRAIC TRANSLATION and COMPILATION for UNIVAC I and II, Automatic Programming Development[END_REF] This more 'linguistic' or even 'syntactic' definition of 'program' [START_REF] Nofre | When technology became language: the origins of linguistic conception of computer programming, 1950-1960[END_REF] would later be confirmed by ALGOL's definition of 'program': "sequences of statements and declarations, when appropriately combined, are called programs" [START_REF] Perlis | Preliminary report-international algebraic language[END_REF] , and, one year later, "A program is a self-contained compound statement, i.e, a compound statement which is not contained within another compound statement and which makes no use of other compound statements not contained within it." 48 5 Business and science, or, software and algorithm?

Around 1960 there is the simultaneous surge of computer service industry and slow establishment of computing as an academic discipline. Like canaries in the coal mine, the usage of two small words, viz., 'algorithm' and 'software', tells us about both. As the statistics show, the rare word 'algorithm' starts to spread from 1958 onwards, the neologism 'software' from 1961 onwards (see Image 1). 49 Their appearance and fast dissemination is indicative of the self-consciousness of new professional groups. As the prevalence of the term 'software' in the trade magazine Datamation shows, it is mainly used by

  , Journal of the Royal Statistical Society, Vol. 57, No. 4 (Dec., 1894), pp. 678-689, here p. 684. Cf. also Haigh and Priestley, idem 2016. 13 Cfr. Martin Carlé's analysis of "pro-gram" in terms of its Greek origins, see his talk Literate Programming, containerisation and the future of Digital Humanities at the Autumn meeting of the PROGRAMme project in Bertinoro. Slides are availabale here.

14 This is the context to which Grier 2011 refers, compare also with Devin Kennedy's PhD, Virtual Capital: Computers and the Making of Modern Finance, 1929-1975 (Harvard 2019), chapter 3. 15 Estell, S.F., Improvement in programme-clocks, U.S. patent nr. 98678, patented January 11, 1870. 16 Murphey, P.B., Broadcast switching system, U.S. patent nr. 2238070, filed May 10 1940, granted April 15 1941. 17 For more detail, see De Mol,L. And Bullynck, M., Roots of 'Program' Revisited, Communications of the ACM, Vol. 64 No. 4 (2021), Pages 35-37

  Curry, H.B. and Wyatt, W., A study of inverse interpolation on the Eniac, Aberdeen Proving Ground, Maryland, Report nr. 615, 19 August 1946. 26 Eckert, Presper J., Mauchly, John W., Goldstine, Hermann H, Brainerd, J.G., Description of the ENIAC and comments on electronic digital computing machines, Contract W 670 ORD 4926, Moore School of electrical engineering, Priestley, M. and Rope, C., 2016. ENIAC in action. Making and Remaking the modern computer, MIT Press, 2016. Of course, the introduction of coded instructions was inspired by the relay machines. 29 Grier, D. A., 'The ENIAC, the Verb "to program" and the emergence of digital computers', IEEE Annals for the history of computing, vol. 18, nr. 1, 1996, pp. 51-55. and Haigh et al. 2016.

	University of Pennsylvania, 30 November 1945., p. 3-7. 27 Curry, H.B. and Wyatt, W., idem, p. 6. 28 See Haigh, T.;

30 Hartree, Douglas R., Calculating instruments and Machines , Urbana, University of Illinois Press, 1949, pp. 111-112. 31

  The computer boys take over. Computers, Programmers, and the Politics of Technical Expertise, Cambridge, Massachusetts, MIT Press, 2010. 36 United States Department of Labor, Occupational Analysis Branch of United States Employment Service, Occupations in electronic data-processing systems, 1959. 37 Grace Hopper, Automatic Programming -Definitions, Symposium on Automatic Programming for Digital Computers, Office of Naval Research, Department of the Navy, Washington, D.C., 13-14 May 1954, p. 1-5.

	Grace Hopper, 1954. J. Presper Eckert, James R Weiner, H Frazer Welsh, Herbert F Mitchell, The UNIVAC system, AIEE-IRE '51: R.V. Andree, Programming the IBM 650, 1958, p. 81. Papers and discussions presented at the Dec. 10-12, 1951, joint AIEE-IRE computer conference, 1951, pp. 6-16 33 34 35 The claim is prominent, e.g., in Ensmenger, N.,

the computer service industry (later: software industry). The term 'algorithm', on the contrary, is most present in the publications of the ACM, a professional society of computer scientists. Both words were 'launched' into professional and public discourse purposefully.

'Algorithm' had been used by numerical analysts and computing professionals occasionally before 1958, but the choice to name the new international scientific programming language ALGOL, acronym of 'ALGOrithmic Language' made the word a household term. As is well-known, the origins of the ALGOL-language date back to meeting of German and Swiss mathematicians and it was allegedly Heinz Rutishauser who repeatedly used the word "algorithmic notation" since 1955, but Herman Bottenbruch who coined the phrase "algorithmic language". 50 The German mathematicians had used "algorithmischer Programm" to distinguish between a mathematical solution to a problem and the program in machine code: "Such algorithmic notations, as we shall call them, have the appearance of classical mathematical notation but include certain dynamic elements which remind one of ordinary programming." 51 While the first description of ALGOL in 1958 was still couched in mathematical terms and spoke of a 'International Algebraic Language', 52 the 1959 description moved to 'algorithmic'. With the buzz created around ALGOL in some circles, say the ACM and universities, the term 'algorithm' gained currency, while words as 'method' or 'rule' faded away. In particular, the specially created 'Algorithm section' in the Communications of the ACM, first edited by J.H. Wegstein, to publish "algorithms consisting of "procedures' and programs in the ALGOL language" (CACM February 1960. 3 (2)) helped to establish it. It also shows that 'algorithm' is situated at the boundary between 'method' and 'program' and may refer to both. So ALGOL became the "internationally accepted method of describing numerical calculations in most journals devoted to computation" 53 When Donald E. Knuth in his Art of Computer Programming series (1962-today) chose to talk about "analysis of algorithms" rather than "non-numerical analysis" as the topic of series, 54 the word 'algorithmic' became even more cemented as a key word, certainly for those who would call themselves computer scientists. 55 This also shows up in the statistics. While 'algorithm' surges around 1960 in all three publications (the ALGOL effect), it remains a rare word in the trade journal Datamation, whereas it features prominently in the Communications of the ACM since 1960, even if subject to some waves of fashion.

The neologism 'software' seems to have started as a joke in the 1950s, the other side of the more common 'hardware' of the military or the computer industry. 56 The statistics convincingly show that 'software' is first used in print 1960-1961 and then becomes a common term. It is mainly used by the computer business and service industry as represented by Datamation. The term also appears in publications of the ACM or the IEEE, but it never reaches the same prevalence among computer scientists and engineers.

In fact, the word 'software' starts its course in advertising. The first occurrences in journals on the West Coast are all in job advertisements, at first those of Ramo-Woolridge, later of other companies too. 57 On the East Coast, the word is used at first be the computer service firm C-E-I-R. 58 In both cases, the word may have been chosen for accounting reasons. Ramo-Woolridge, a primary consultant for the U.S.'s space program, was under a "hardware ban" (viz. forbidden to sell hardware to the military, to avoid monopoly). Calling their services 'software', even if that meant microprogramming computers, might have been a decoy tactics. In a similar vein, C-E-I-R had had problems capitalizing the costs incurred over training 49

The statistics of image 1 were produced with GNUplot, the data for Datamation and AFIPS were obtained by automatically searching with grep through the OCR-ed issues of the journals in question, the ACM data were obtained by using the search engine of the Many claims to first uses exist, e.g. Paul Niquette, Grace Hopper, or the RAND Corporation, but they all have in common that it was originally used as a joke-like designation of things not hardware. 57 E.g., "Senior programmers are urgently needed to help develop a large 'software' package for commercial and military applications for R-W stored logic computers", Datamation 1961, 1. 58 E.g, "The art of programming -it can scarcely be called a science yet -has grown concurrently in the past 9 or 10 years with the hardware. The resulting large systems of programs have now reached such a degree of complexity and power as to rival the machines. This 'software,' as it is currently called", Datamation, 1960, 9.

programmers or developing programs 59 and might thus have come up with a new term to make this investment more tangible.

The term certainly stuck quickly. It surfaces in the development of COBOL and, at first, is mainly used to refer to programs that help to program, such as compilers, assemblers, utility or monitor programs. 60 But soon 'software' became the generic term used by the programming services industry for talking about programs as a commodity, as a commercial product. The prominent role of C-E-I-R's president H.W. Robinson at ADAPSO may have played an important role in establishing the word. IBM, who had had a quarrel with C-E-I-R around a rental of their STRETCH computer, at first dismissively defines 'software' as a 'slang term for programming system' but will adapt the term eventually in their programming service bureaus. As the graphs of Datamation show, the spread of 'software' correlates with a slow but steady decline of the word 'program', substituting the 'neutral' program for the 'commercial' software, turning the 'programming service industry' into 'software industry'.

Discussion and Outlook

The semantic 'tectonics' still goes on. The further evolution of program' and 'code' may be gleaned from the statistical graphs. As 'automatic coding' and 'programming languages' gain currency the frequency of "coding" goes down, while "programming" goes up. "Coding" in most cases now mainly refers to coding data or encoding or decoding practices. In the 1980s and, more recently in the 2010s, 'coding' and 'coder' became slightly popular again. 'Coding' now has become a colloquial term for 'programming' emphasizing the recreative side of programming, closer to 'hacking', contrasting it with the professional business of programming applications. 61 One can also observe from the graphs that the popularity of 'programming' has fallen since the economic crisis of 1973, while at the same time 'software' continued its upwards trend. If the ACM statistics (the only ones going beyond the 1980s) are representative, it would seem this evolution was returned around 2000 when 'software' lost ground to 'program(ming)' and to 'code(ing)' again. 'Algorithm' seems subject to some 'seasonal' variation. After its ALGOL-popularity around 1960, it is barely mentioned in the trade magazine Datamation, whereas AFIPS proceedings show steady use, but the ACM publications feature it most prominently. It peaks around 1975 with a downwards trend afterwards until 2000 when it goes up again. The heydays of structured programming might play a role here, but there is also a hint from the fact that the Algortihms section of the ACM becomes a journal in its own right, Transactions on Mathematical Software, changing the focus from algorithms to programs or even software again. 62 More research would be needed to correctly interpret these data. Illustration 1: Above, data from the AFIPS Proceedings (1951-1987); middle data from the Communications of the ACM (1954-today); below data from Datamation (1957-1989).

It is important, finally, to note that nowadays the word 'algorithm' has begun to be used in a broader sense still. 63 Examples are Google's algorithm, Facebook's algorithm, algorithmic trading or even algorithmocracy, a state form where political decisions are influenced or even formed by algorithms. This signification of 'algorithm' extends from the stepwise recipe-like numerical or non-numerical procedure to the complex or system of programs and parameters that underly parts of technological infrastructure. This recent evolution of the word would certainly merit detailed historical and political scrutiny, especially given its boost in popularity with the latest wave of artificial intelligence. A superficial browsing of our data seems to suggest that its roots are to be found in the late 1960s or early 1970s when engineers began to speak of 'scheduling algorithms' in operating systems. 64 It further gained traction in the 1970s and 1980s when some communities started using the word in a more general way, viz. for any method that is programmed within a software project. Such usage can be found in research on predictive, genetic, backtracking etc. algorithms in artificial intelligence (e.g. David Rummelhart or David Marr), research in query and update algorithms for data base structures, or in economists' programs for automatic trading on the stock market. 65 As it becomes invested with economic or political interests, as it did for "algorithm" in the 21 st century, it silently but not innocuously becomes part of the often subconscious set of values and distinctions that characterize everyday vocabulary. Looking beyond the screen of words is a necessity and history helps to identify and critically engage with the forces that drive words today.

63

See also Babinsteva's chapter in this volume that shows how the word "algorithmic" changes in meaning in a Soviet and, later, financial context. 64 'Scheduling algorithm' and the like account for a large part of the increase in using the word 'algorithm' in the AFIPS proceedings. 65

The economists knew the word through 'linear programming', a mathematical theory developed in the late 1940s. See Devin Kennedy's PhD, chapter 4 for more details.


Logic, programming and computer science: Local Perspectives. 1Liesbeth De Mol CNRS -UMR 8163 Savoirs, Textes, Langage, Université de Lille This special issue offers new perspectives on the question of how and why logic became intertwined with computing and programming. It focuses on the locality of programming and computing practices, highlighting their relation to formalist practices and concepts to provide a deeper understanding of the historical relations between these different practices.

The theoretical and technical considerations that tie logic and computing together have been historically contingent on the local and national structures in which they unfold. The pioneering historian of computing, Michael Mahoney, once noted that "the computer in itself embodies one of the central problems of the history of technology, namely the relation of science and technology" [START_REF] Mahoney | The History of Computing in the History of Technology[END_REF]. It follows that the social processes that have guided the articulation of the relationships between logic and computing substantiate and detail how this relation between science and technology is negotiated locally in the practices of computing and programming.

This issue is grounded on scholarly works in computer science, the history of computing, and intersections between the two fields. These works do not form a cohesive framework. By consequence, they have often yielded vastly different-if not conflicting-conclusions on the relationships between computing as a science and computing as a technology and on the role that logic plays in shaping those relationships. In response, this issue suggests that a focus on the locality of logic offers a unique opportunity to study how the rather arcane and abstract field of logic was put into action locally. Methodologically, it requires the integration of internal and external readings to offer a more global if not longue durée perspective on why and how logic was transposed into the discourse.

COMPUTER SCIENCE PERSPECTIVES

A prominent belief amongst computer scientists states that the technology of computing is founded upon theoretical insights. In other words, as physicist Nicholas Metropolis had noted, "Theory is the captain, and application the soldier." [20, xvi] This can lead to the assumption that the logical foundations of computing can be historically retraced, directly or indirectly, to the foundational debates in early 20 th century mathematics to resolve a number of fundamental logical problems. One school of thought at the time, the so-called formalist school anchored in the work of David Hilbert, hoped to resolve those problems by developing a specific kind of "pure" formalism. According to logician Alonzo Church, this required a formalism that"makes it possible to abstract from the meaning of the symbols and to regard the proving of theorems (of formal logic) as a game played with marks on paper according to a certain arbitrary set of rules" [4, p. 842]. It is here that we find one of the roots of what later became known as the foundational models of computer science:combinators, lambda-calculus, general and partial recursive functions , Post production systems and, of course, Turing machines. While these formalisms were of basic relevance to the field of mathematical logic, for many years, the results were rather arcane and known only to the initiated which included, amongst others, John von Neumann. 2Today, these formalist views have certainly been influential on some developments in computer science. One prominent view for instance that emerged in the late 1960s and 1970s, and which is connected quite directly to the ambitions of Hilbert's program, is the idea that programs can be treated as formal objects for which one can then prove formal correctness. Roughly speaking this comes down to the idea of proving that a program is correct with respect to its specification, that is, it can be proven that is doing what it is supposed to be doing. 3 But this does not necessarily imply that computer science and, with it, the computer, is historically grounded in (or can be reduced to) logic. As is well-known amongst historians, logic is but one dimension of the history of computer science. In order to understand then why, amongst certain communities of computer scientists, there exists a conviction that logic does play such a basic role for their field, the challenge for the historian is to disentangle the actual use of logic within the practice and the theory from the social forces at work in the shaping of those practices and theories. For instance, It was only in retrospect that a specific community in computing and programming identified their foundations with logical foundations and that they integrated logical methods in their work. 4 One epistemological explanation for this is the increased need for more controlled methods of programming against the background of a looming software crisis but there is also a string socio-historical dimension to be taken into account: that of an emerging new field that struggled with its disciplinary identity and that wanted to achieve independence by providing a mathematical foundation. Clearly, such explanations require an integration of internalist with externalist methods.

While today, such logically-founded views are perhaps less dominant than they were in the 1960s and 1970s, there is still a common conception, amongst a specific group of academic computer scientists, that the origins and foundations of computing are to be found in logic and mathematics. For instance, logician Martin Davis has advocated for the conviction that the abstract model of the Turing machine was basic to the construction of the first computers [START_REF] Davis | The universal computer. The road from Leibniz to Turing[END_REF].

Historians do not always accept views such as Davis'. This was clear for instance in the wake of the Turing centenary in 2012, a celebration of Alan M. Turing which reinforced the image that computing is based on logical insights, with misinformed claims that Turing invented the modern computer. Several historical pieces in the U.S. flagship magazine for computer science, Communications of the ACM, corrected these claims by showing that they misrepresented the more complex historical reality and that these views are mostly a side-effect of a discipline's need for heroes [START_REF] Daylight | A Turing tale[END_REF][START_REF] Daylight | Why did computer science make a hero out of Turing[END_REF][START_REF] Haigh | Turing Did Not Invent the Computer[END_REF]]. 5

HISTORIOGRAPHICAL PERSPECTIVES

Despite the history of computing's tremendous development since historians first approached the subject in the 1980s, the field does not yet have a broad intellectual history of computer science. Mahoney, one of the pioneering scholars, had set out to write such a history in the 1990s, which he provisionally titled The Structure of Computation: Mathematics and Theoretical Computer Science 1950-1970, but was never able to finish that project. 6 Bill Aspray's John von Neumann and the Origins of Modern Computing [START_REF] Aspray | John von Neumann and the origins of modern computing[END_REF] and Donald MacKenzie's Mechanizing Proof and Mark Priestley's A science of operations [START_REF] Priestley | A Science of Operations. Machines, Logic and the Invention of Programming[END_REF] have made important inroads in the history of computer science, but a work of the kind Mahoney had envisioned is still lacking.

There are two possible reasons for this. First, while Mahoney certainly adhered also to a more "scientific" reading of the computing field, he concluded that the history of computing has its proper home within the history of technology. 7 The inscription of the main community of historians of computing within the Society for the History of Technology has been an affirmation of that viewpoint 8 though it is clear that in recent years attention for the topic within history of science is increasing. 9 A second, complementary reason, is the supposed opposition in the historiography of computing between what is classically called internalist and externalist history. On the one hand, internalist history is often, but not necessarily, associated with people from the field writing their own technical histories. Their critics call these works histories of ideas and rebuke them for being too Whiggish. 10 On the other hand, externalist history is often considered a good practice within historiography but it does not engage deeply with developments of computing and programming techniques. 11 This tension between externalist and internalist history, where the former is associated with "professional" history and the latter with history written by practitioners, became explicit when Donald Knuth, prominent computer scientist, gave a personal reply to a paper by Martin Campbell-Kelly that was published in Annals [START_REF] Campbell-Kelly | The history of the history of software[END_REF]. Knuth's Kailath lecture at Stanford University, titled Let's not dumb down the history of computing (2014), regretted that Campbell-Kelly applauded a development within history of computing from being a history driven by technical details to a more external way of writing history. The analysis of this debate by Tom Haigh pointed out quite clearly that the kind of history computer scientists would like to see--that is, one that is can be treated as mathematico-formal objects [START_REF] Parnas | Software aspects of strategic defense systems[END_REF]. 6 As Haigh explains: "[t]his was the first, and so far the only, attempt to write a reasonably broad intellectual history of computer science." [START_REF] Haigh | Unexpected connections, powerful precedents, and big questions: the work of Sean Michael Mahoney on the history of computing[END_REF] 7 "What is truly revolutionary about the computer will become clear only when computing acquires a proper history [...] Pursued within the larger enterprise of the history of technology, the history of computing will acquire the context of place and time that gives history meaning" [18, pp. 122-123] 8 For a historiographic analysis of the relation between the historiography of computing (in relation to the historiography of mathematics) and the particular role of Mahoney's work in this context, see [START_REF] Mol | Making the history of computing. The history of computing in the history of technology and the history of mathematics[END_REF] 9 This is due to amongst others the increased relevance of so-called computational science. 10 Even though it does not necessarily follow that internalist history is Whiggish. 11 In this context it is interesting to point out that the Springer book series History of Computing, edited by a number of well-known historians of computing, aims at "high-quality books which address the history of computing, with an emphasis on the 'externalist' view of this history". engaged with technical details--is not the kind of history-writing valued at US history departments [START_REF] Haigh | The tears of Donald Knuth[END_REF]. But it also pointed at a deeper tension between internalist and externalist histories.

TOWARDS LOCAL HISTORIES

Within recent historiography of computing, it has become clear that global histories alone do not account for the richness of local practices and tend to raise above the local only one perspective. This results in too simplistic and one-sided accounts of the history of computing. 12 Within that framework, a growing number of scholars have engaged also more deeply with the history of computer science, by zooming in on local interactions between logic, mathematics, and computing in the context of local practices against the background of longer term problems, concepts and ideals. They engage with the specificities of these contexts -its local technical, social and scientific challenges -and overcome the too strict distinction between science and technology, on the one hand, and, on the other, that between external and internal analyses. Scholars like Troy Astarte, Maarten Bullynck, Edgar Daylight, Liesbeth De Mol, Stephanie Dick, Thomas Haigh, Elisabetta Mori, David Nofre and Mark Priestley have traced down to what extend certain logical ideals and techniques became transposed or not into a set of particular engineering and programming contexts and views. Ksenia Tatarchenko and Pierre Mounier-Kuhn have succesfully contextualized and enriched global developments in the history of computer science through an analysis of more local contexts in the case of Russia and France [START_REF] Mounier-Kuhn | L'informatique en France de la seconde Guerre Mondiale au Plan Calcul[END_REF][START_REF] Tatarchenko | A house with the window to the West: The Akademgorodok computer center[END_REF].

While such local histories enable to work against an all too linear, monolithic and progressive history, it also has a basic pitfall: it does not give a clear answer to how such local perspectives (re-)connect to and can be (re-)integrated in more global perspectives. Indeed, as Renn pointed out in 1996 [START_REF] Renn | Historical epistemology and the advancement of science[END_REF]:

The emphasis of recent historical studies on the local circumstances of the practice of science have certainly helped us to question the universals superimposed on the history of science by a dogmatic and normative philosophy of science but they should not induce us to consider the microscope alone to be the legitimate instrument of historical analysis, when there are obviously structures that can only be identified with a telescope.

[…] we should neither think in terms of a strict distinction between internal and external determinants nor in terms of an alternative between local and universal structures governing the historical development of scientific thinking, but in terms of a manifold of structures living on different time-scales and crossing -each in its own way -the borders between science and its contexts. Renn found solace in the reliance on long-range studies which reveal the "interplay between its local and its more global structures." Such approachtelling local histories without assuming that they cannot transcend their own local boundaries-is the key methodological contribution of this issue. Each of the contributions opens up a particular longue durée perspective, by focusing on a specific local context.

LOCAL-GLOBAL HISTORIES

12 That point that was made already by Mike Mahoney with his notion of so-called "communities of computing" approach for doing history of computing and which proposed to look at different practices from different communities concurrently [START_REF] Mahoney | The histories(s) of computing[END_REF].

As explained in Sec. 1, within computer science, there exists a dominant view that logic provides a foundation for the field of computing not just theoretically but also historically. Such views are often focused on a few pioneering figures who were working in mathematics and logic and then started work on computing machines. In the paper "German Encounters of Logic and Programming (1948)(1949)(1950)(1951)(1952)(1953)(1954)(1955)(1956)(1957)(1958): Three Readings of Turing Machines", Maarten Bullynck contextualizes different readings of Turing's 1936 paper [Turing 1936-37] in a German context (1948)(1949)(1950)(1951)(1952)(1953)(1954)(1955)(1956)(1957)(1958). He shows how much a particular reading of the Turing machine is dependent on and determined by local contexts and how the problems and goals that the different practitioners were facing shaped their readings. These can be more institutional and mathematical (as was the case of Hans Hermes) or more practical and machine-oriented (as was the case with Corrado Böhm). Understanding these local contexts requires a more externalist reading of the different cases, whereas the analysis of how the Turing machine was integrated in those works, is achieved through a more technical analysis of the Turing machine concept and the different ways it was used to solve or frame a certain problem. Through these different readings, Bullynck shows that one should be careful when inscribing local histories in a more global history, in this case ALGOL, since it risks to create too simplistic histories that do not do justice to the local practices underpinning those very same histories. In other words, by zooming in on one very specific problem, "How was Turing read in the German and Swiss context?" the local contexts that had faded in the international history of ALGOL become visible again. Their chronology tells us of the rapidly moving objectives that drive computing and programming in those days.

In The Work of Writing Programs: Logic and Inscriptive Practice in the History of Computing a different perspective is offered on locality: through the analysis of a number of quite distinct local practices, David Dunning develops a particular way of looking at how logic got entangled with computing. It inscribes programming and logic practices within a broader history of (re)writing, introducing the notion of inscriptive systems. That notion is used as an umbrella term for any kind of notational practice allowing for an open-ended range of uses for written symbols. It gives a more general methodological framework from which to study both logical and programming practices. While each clearly has its own own material, social and technological conditions, that perspective allows to reveal a connection between logic and computing which renders understandable their historical linkage. The motivation for this lies exactly in trying to resolve the rather strict separation that is often made between mathematics and technology in, amongst others, Mahoney's work. In the paper, mathematical logic, rather than being considered as the immaterial spirit of the computer's material body, is rematerialized as an activity which always takes place in a physical medium too thus reconnecting the mathematics and the technology of computing. In order to add strength to that view, the first case of the paper is a particular reading of some work on 19 th century mathematical logic for which Dunning shows that already at that time, formalist practices were connected to problems of mechanization thus thus providing a broader horizon from which to read their later linkage within the context of computing.

In the final paper of this issue Russian Logics and the Culture of Impossible which consists of two parts, Recovering Intelligentsia Logics and Reinterpreting Algorithmic Rationality, the locality of the Russian imperial and soviet context, relying on a longue durée perspective, offers an alternative understanding of the central notion of "algorithm" as it appeared in the Soviet context, countering a dominant and US-centered narrative that introduces "algorithm" as going hand-in-hand with a shift from humanistic ideals towards so-called cold war (algorithmic) rationality. The two parts of this paper show, in contrast, that the notion of algorithm in the Russian context is much more tied to a set of humanist ideals, inscribed in a general vision of educating and shaping minds and which has its roots in pre-revolutionary intelligentia science and logic. The "culture of impossible" as it was named by Vladimir Uspensky, captures that idea: the thinking around and tinkering with mathematical objects to develop, extend and explore ones own human limitations and capacities. As such, this two-part paper shows that also "general" histories are locally-determined and require to be complemented and engaged with other "local" histories in order to write a truly general history of, for instance, the algorithm. A central notion is poznaniye which ties together the diversity of intelligentia logics in the Russian empire and enables to embed and explain "algorithm" from this more humanist perspective. Poznaniye, in contrast to znaniye (knowledge), focuses on the process of knowledge acquisition which is always incompletable. It is here that one finds the roots of a performative pedagogical culture and a deep connection between the abstract and the concrete. The fact that "algorithm" as a global notion can at least be partially retraced to the Russian imperial and soviet context thus opens up alternative readings of the science-technology dichotomy within the broader history of programming and computing: from this perspective, there need not be such a strong tension -the changing disciplinary dynamics between logic and cybernetics as developed in Part II makes this clear. Moreover, the continuity between pre-revolutionary logics and cybernetics shows that influences of logic on computing should not be reduced to developments in Western mathematical logic and so asks for a broader reading of the history of logic too. Finally, in order to offer this alternative reading it was necessary to integrate a set of different methodologies and competencies which require both the close reading of a number of logico-mathematical papers to decode the basic continuities with the pre-revolutionary intelligentia logic as well as a deep understanding of the social forces that enables the kind of continuities uncovered in this paper.

This is a preprint and draft version of the guest editor's introduction to a special issue published in IEEE Annals of the history of computing: L. De Mol, Logic, programming and computer science: Local perspectives, IEEE Annals of the History of Computing, vol. 43, nr. 4, pp. 5-9,

More specifically, these formalisms allowed to prove the impossibility of solving certain general problems in mathematics and so resulted in the partial failure of Hilbert's program.

See e.g.[START_REF] Hoare | An axiomatic basis for Computer Programming[END_REF] for a strong version of this view.

For instance, as was shown by scholars like Mark Priestley and Matti Tedre. As they both emphasize in their work, this only concerned a particular academic community and should not be generalized to the computing field at large. See[START_REF] Priestley | A Science of Operations. Machines, Logic and the Invention of Programming[END_REF][START_REF] Tedre | The Science of Computing: Shaping a Discipline[END_REF]

Also within the computing field itself, the view that computer science is anchored in logic, is not shared by everyone and has given rise to several heated debates if not divides between those who insist on the need for logical foundations versus those who seek other foundations[START_REF] Denning | Great principles of computing[END_REF] and/or those who have warned that there are basic pitfalls if one assumes that programs

Acknowledgment

This special issue is anchored in a roundtable "The introduction of mathematical logic in computing: Comparing local / national processes" that was moderated by Pierre Mounier-Kuhn at the first autumn workshop of the ANR PROGRAMme project at the University Residential Centre in Bertinoro, Italy. We would like to thank Pierre Mounier-Kuhn for his initial contributions to this project. We would also like to thank all the members of PROGRAMme who participated in the roundtable. The work on this issue was partially supported by the project ANR-17-CE38-0003-01. Special thanks are due to Con Diaz. Not only did he guide me and the authors through the process of getting to final versions by providing very clear comments, suggestions and advices, but he also learned me a lot about what it means to be a good, open-minded and engaged editor.


Sandra Bertezene
email: sandra.bertezene@lecnam.net

Philippe Michel

ESOE Jacques Martin
email: jacques.martin@wanadoo.fr

Have health professionals become do-it-yourself professionals?

Keywords: coronavirus crisis, health care organization, behaviours of health professionals

The coronavirus crisis completely disrupted the operations of hospitals and created a situation of utter uncertainty. Consequently, health professionals had to quickly find ways to adapt to this unprecedented situation and find solutions to take care of the persons hit by the virus. As classic pre-established processes and protocols designed by 'engineers', could no longer work, they resorted to Do-It-Yourself and worked out makeshift solutions. This dramatic situation had a positive aspect in that it spurred new behaviours and relationships between health professionals, fundamentally based on cooperation and the breakdown of the established structure of the organization. However, only after a few months, the old ways and habits reappeared, creating a situation of misunderstanding and mistrust among health establishments. One strategic and organizational lesson that can be drawn from this crisis, is that health establishments should combine the positive aspects of the 'engineer' and the 'DIY' approaches to find more flexible, adaptive and reactive approaches, and weave closer and cooperative relationships between health professionals resulting in better care of patients.

Methodology:

The analysis was based on the observation of a number of hospitals during the crisis and exchanges with health professionals.

Introduction

On 31 December 2019, the Chinese authorities informed the World Health Organization about several cases of an unknown type of pneumonia in the city of Wuhan. In May 2020, five months after the official announcement of first cases of the new coronavirus, almost five billion people had to respect measures of confinement in order to avoid contamination. Two years later (Spring 2020), more than 450 m people, nearly 6% of the world population, a figure certainly underestimated, have been contaminated by the virus and more than 6 m people have died. The world was then confronted with a major and brutal crisis. In this never seen context, hospitals found themselves on the front line. How could the management of hospitals be organized to face the unknown in an extremely short time? How could they integrate this new uncertainty and the fear that went with it into their routines? What can we learn from this crisis about the management and needed transformation of hospitals? We will base our analysis on the case of French hospitals.

To answer this question, we will recourse to the archetypes of the do-it-yourself person and the engineer developed by the French anthropologist and ethnologist Claude Levi-Strauss in his book "La pensée sauvage" (Wild thought) published in 1962. Our analysis shows how inside hospitals health professionals became real DIY persons as soon as March 2020 (Section 1), and then three months later resumed being the engineers they were before the crisis (Section 2). The pandemic also offered the occasion to professionals to experiment a third archetype, that of the reflective practitioner [START_REF] Schön | The reflective practitioner: how professionals think in action[END_REF], able to articulate engineering and DIY both in a situation of routine and one of uncertainty.

The fruitful DIY in hospitals to face the arrival of the new coronavirus

As soon as the pandemic arrived in 2020, professionals in front-line hospitals observed two simultaneous phenomena. On the one hand they could no longer solve the problems they were confronted with as their magnitude was too big, on the other hand they were facing unprecedented difficulties for which there was no planned solution. On the medical plane, the lack of knowledge of the new coronavirus was total and on the managerial plane there were logistical problems (lack of stocks, difficult supplies of some equipment), human resources problems (lack of personnel) and organizational problems, particularly concerning work, as, of course, no procedure can anticipate something unpredictable, notwithstanding all the safety and quality provisions. The Regional Health Agencies also met difficulties. They could no longer answer the needs of the population, nor ensure totally the effectiveness of the health system according to the health plans of the national health strategy. So, they put their trust in hospitals and let them organize themselves as they thought best to fight the pandemic. Thus, the Agencies gave professionals the legitimacy for becoming DIY persons and use makeshift solutions with disparate materials and tools as no adequacy was any longer possible with the current situation.

The DIY person is only equipped with his tool box (with a limited number of tools), his 'repertory' according to the word of Levi-Strauss, to tackle an unexpected situation and overcome obstacles to find a solution. Thus, hospitals began to make makeshift overalls and masks outside the regulatory certification channels, to look for suppliers without respecting the purchasing procedures, to put personnel 'on the job' without previous training, to try and adapt treatments with the current as new information (reliable or not) about the virus came up. This chaotic situation was worsened by the hectic and incoherent communication of governmental authorities and the cacophony of experts (real or supposed) [START_REF] Martin | Covidalculation and Covidmunication, Some methodological insights[END_REF]. The structure of the organization was spontaneously reconfigured on the basis of an unformalized cooperation between the different specialties, between the medical and administrative personnel, between the hierarchical levels, between establishments, between public and private sectors (with some delay), etc. Health professionals revealed themselves as being competent, creative and wise DIY people who knew their tools well and found together the best (or least bad) possible solutions to meet the challenge facing them. They demonstrated an agility in acting which permitted to continue to take care of patients. At that stage, the crisis seemed to produce a positive evolution; debates began to take place on the changes already under way and to come. The health workers, who were on strike before the general confinement of March 2020, found again a meaning to their work, establishments were supported by their overseeing authorities, and all health personnel were supported by the general public. seemed that the evolution was on a good track, but as soon as the confinement was lifted in May 2020, the return to 'normality' was organized; the "white plans" were gradually lifted, the tool box was back in the cupboard and DIY disappeared.

The end of DIY and the return of the engineers

The episode of DIY finished, the overseeing authorities became again the chief engineers that they had been before the coronavirus. The vertical management of establishments was back, with at the very bottom of the pyramid the personnel in direct contact with the patients (medics and paramedics). Their unique expertise recognized a few weeks before was no longer sufficient to justify their leadership. Contrary to the DIY person, the engineer always "seeks to find a way and see beyond… he operates according to concepts." He defines a project and "uses materials and tools designed and supplied to fit his project." (Levi-Strauss, 1962). The engineers do not improvise. They follow the plan established by the national health strategy, the multi-year contracts of objectives and means, and all the specific projects, procedures and protocols. Whatever his position in the chain of command, the engineer identifies and seeks the resources necessary to achieve the mission assigned to him. He is encouraged in this approach as his work is evaluated according to the gap between the forecast and the final result in terms of patient safety, quality of care, respect of budgetary constraints, etc. But in such an unstable period as the coronavirus crisis, the measurement criteria are rarely compatible with reality of the work of DIY medical personnel. The engineer of Levi-Strauss has the rational legal power of Weber (1961). Rules define the extent and the limits of his capacity to do. When the task is beyond the limits of his knowledge, it is handed over to another expert. Contrary to the DIY person, he cannot think and act by encompassing the whole of a project. He thinks and acts according to the parts that have been assigned to him without there being necessary a link between them. Personnel in nursing homes for the elderly for example needed indications on how to deal with deaths in a dignified way. The answer of the Regional Health Agency was to send them a protocol established for hospitals which was ill-adapted to nursing homes whose personnel lack the competencies and equipment to apply it. This type of injunction reinforces in the eyes of the personnel the lack of legitimacy of the overseeing authority which is not close to the patients, has not got the expertise of the sector, is far from down-toearth problems and does not recognize the limits of its expertise.

Therefore, from May 2020, mistrust replaced trust, in spite of some efforts made by the government to re-establish trust through negotiations that were given the name of Segur de la santé.

DIY-engineers or engineer-DIY persons : reflective practitioners to seize uncertainties better in health establishments ?

When the coronavirus tide arrived, the principles of the Weberian bureaucracy exploded. The engineers became paralyzed and made way for DIY, both as a process and result (Levi-Strauss, 1962). Cooperation was preferred to the division of work and the hierarchical structure, on-the-job training was selected to the detriment of the classic way of recruiting, hoc solutions were looked for, day in day out, without abiding by the established rules, the mobilization and mutual help of the personnel swept away the impersonal character of relationships. DIY transformed a work based on pre-established rules into a work more based on the person thanks to the autonomy acquired from the overseeing authority. DIY means "giving something of oneself" (Levi-Strauss, 1962), which makes all the more difficult going back. Therefore, two worlds clash with each other. The positivist approach of the engineer leads him to think that the laws that govern a phenomenon (like a sanitary crisis) apply even if these laws are not all known. His work then consists in finding these laws and the possible cause-effect links between them (Le Moigne, 2012). For example, when a law says that a lack of hygiene is a cause of the spreading of the virus, the engineer concludes that there is a positive correlation between the use a hydro-alcoholic gel in hospitals and the spread of the virus. The DIY person does not reason in the same way. Its constructivist epistemology leads him to make knowledge emerge which cannot be dissociated from the construction process which is at its origin (Le [START_REF] Moigne | Les épistémologies constructivistes, Que sais-je[END_REF][START_REF] Piaget | L'épistémologie génétique[END_REF]. Engineers and DIY persons are then right at the same time. But considered independently the knowledge of the former can come into conflict with the knowledge of the latter, whereas the problem to solve is the same. The different stakeholders seem to be converging today towards the ambition of permitting to professionals to become 'reflective practitioners' [START_REF] Schön | The reflective practitioner: how professionals think in action[END_REF]) that can ensure the improvement of the quality and security of care, and find meaning in their work. A reflective practitioner develops his thoughts in action and acting. When a situation is unprecedented, fuzzy and uncertain, he reorients himself to find another way and tries to model problems to be able to solve them (Le [START_REF] Moigne | Les épistémologies constructivistes, Que sais-je[END_REF]. He tests solutions, scenarios, including unexpected ones, so that there is a movement of redefining problems as he goes along, giving new meanings to the situation. The reflective practitioner ponders on the problem as he constructs it. There is an articulation between the positivist epistemology and the constructivist epistemology to develop an epistemology of praxis. This does not mean, however, that the problems of hospitals would be solved if the overseeing power of authorities were transferred to the health care personnel. Each has their expertise, role and legitimacy. It is more a question of making the organization permeable to the contribution DIY-engineers can make at all the hierarchic levels and inside the different bodies involved in the global health system.

Conclusion

A health system relying on DIY-engineers requires the development of a practical wisdom, a φρόνησις (phronesis), which is highly important at a time when there is a widespread denial of scientific knowledge and expertise when we hear such things as 'the virus is destroyed by heat, 5G is at the origin of Covid-19, the vaccine modifies our DNA, etc. The phronesis comes from Aristotle (Nichomachean Ethics) and Nonaka and Takeuchi apply it to enterprises (2011). It implies the following:

-Sharing values of equality, neutrality, adaptability and continuity of health care and act according to these values; -Seizing the complexity of phenomena to better convey the raison d'être of hospitals residing in ensuring safe and quality health care and designing preventive actions; -Exercising power with benevolence and assuming one's responsibilities in all circumstances and functions; -Developing an environment fostering the creation of knowledge, its transmission and learning through doing.

The management of the system should encourage professionals to acquire a practical wisdom and to become reflective practitioners equipped with the talents of both the engineer and the DIY person to make decisions that are both true and just.