Turing autocode(ID:3914/tur005)

Turing 


Turing's autocode for the ACE and Deuce, largely incomprehensible it was said

"However with the appointment of Cicely Popplewell to Electrical Engineering in the summer of 1949, effort started to be put directly into satisfying the requirements of the programming community. In 1950 Turing and Cicely designed the programming system for the Ferranti Mark 1 (Scheme A), based on their experience with the Manchester Mark 1, and Turing wrote the first programming manual for it."


Cicely Popplewell may well be the world's first SysAd! "Cicely Popplewell concentrated on the practicalities of running the Computer Service."


Related languages
Turing's code => Turing autocode   Influence
Turing autocode => Brooker Autocode   Evolution of

References:
  • Turing, A.M.; "Programmers' Handbook (1st Edition) for the Manchester Electronic Computer Mark II" Manchester 1951 view details External link: Online copy
  • A.M. Turing, revised R.A. Brooker, C.M Popplewell "Programmers' Handbook (2nd Edition) for the Manchester Electronic Computer Mark II" Manchester October 1952 view details External link: Online copy
  • Campbell-Kelly, Martin "The Development of Computer Programming in Britain (1945 to 1955)" view details Extract: Turing's awful system
    At Manchester the programming system devised by Turing for the Mark I makes a disappointing contrast with the elegance of the Cambridge work. From the point of view of notation, it is difficult to find a single redeeming feature. Probably the only feature of real merit was the concept of dividing a program into physical and logical pages. Echoes of this idea can be discerned in today's segmented computers.

    In its way, Turing's programming system did have considerable influence, for all efforts to replace it with something more suitable were curiously unsuccessful.

    Thus programmers for both Mark Is and all seven Mark Iota's had to struggle with Turing's clumsy teleprinter notation throughout the life of these machines. Here is perhaps one of the most valuable lessons of this study: poor design decisions taken early on are almost impossible to correct later. Thus even when people with a Cambridge background arrived at Manchester, they were unable to make a really fresh start. By producing two successive input routines that were not much better than Turing's, they managed to combine the worst of both worlds: an unsatisfactory programming system that was not even a stable one.

    Extract: Conclusions
    Conclusions
    When we compare the development of programming at the three centers -- Cambridge, Manchester, and Teddington -- there are several factors to consider. First, we must consider the quality of the programming system; this is a subjective issue that ranges from the purely aesthetic to the severely practical -- for example, from the elegance of an implementation at one extreme to the speed of a matrix inversion at the other. We must also consider the failures of the three centers, especially the failure to devise a programming system that exploited the full potential of the hardware. Finally, we must consider the influence of the programming systems on other groups; this is less subjective -- it was described in the previous two sections and is summarized in Figure 2.

    Few could argue that Cambridge devised the best of the early programming systems. The work done by Wilkes and Wheeler stood out as a model of programming excellence. Cambridge made several outstanding contributions to early programming: the use of closed subroutines and parameters, the systematic organization of a subroutine library, interpretive routines, and the development of debugging routines. Perhaps the finest innovation was the use of a symbolic notation for programming, as opposed to the use of octal or some variant. It is difficult for us today to appreciate the originality of this concept.
    If Cambridge can be said to have had a failure, it was the failure to develop programming languages and autocodes during the middle and late 1950s, as reflected in the second edition of Wilkes, Wheeler, and Gill (1957), of which Hamming said in a review,

    It is perhaps inevitable that the second edition, though thoroughly revised, does not represent an equally great step forward, but it is actually disappointing to find that they are no longer at the forefront of theoretical coding. (Hamming 1958)]

    By neglecting research into programming languages, Cambridge forfeited its preeminence in the programming field.

    In the early 1950s, however, Cambridge was by far the most important influence on programming in Britain. This came about partly through the excellence of the programming system and partly through the efforts that Cambridge made to promote its ideas. Two machines (I`EO and TREAC) based their programming system directly on EDSAC, and five machines (Nicholas, the Elliott 401 and 402, MOSAIC, and Pegasus) were strongly influenced by it. It is also probably true that no programming group was entirely uninfluenced by the Cambridge work. Overseas, the influence of the EDSAC programming system was just as great, largely through the classic programming textbook by Wilkes, Wheeler, and Gill (1951) (see Campbell-Kelly 1980a).

    At Manchester the programming system devised by Turing for the Mark I makes a disappointing contrast with the elegance of the Cambridge work. From the point of view of notation, it is difficult to find a single redeeming feature. Probably the only feature of real merit was the concept of dividing a program into physical and logical pages. Echoes of this idea can be discerned in today's segmented computers.

    In its way, Turing's programming system did have considerable influence, for all efforts to replace it with something more suitable were curiously unsuccessful.

    Thus programmers for both Mark Is and all seven Mark Iota's had to struggle with Turing's clumsy teleprinter notation throughout the life of these machines. Here is perhaps one of the most valuable lessons of this study: poor design decisions taken early on are almost impossible to correct later. Thus even when people with a Cambridge background arrived at Manchester, they were unable to make a really fresh start. By producing two successive input routines that were not much better than Turing's, they managed to combine the worst of both worlds: an unsatisfactory programming system that was not even a stable one.

    The one real high spot of the Manchester programming activity was Brooker's Mark I Autocode. Brooker's achievement was the most important programming event of the mid-1950s in Britain. If Brooker had not devised his autocode at that time, programming in Britain might have developed very differently. The autocodes for DEUCE and Pegasus were directly inspired by Brooker's and had considerable notational similarities with it. Beyond the time scale of this paper, Brooker's Mark I Autocode and his later Mercury Autocode (1958) were a dominant influence on British programming until well into the 1960s, when languages such as ALGOL 60 and FORTRAN came onto the scene in Britain.

    Of the three programming systems devised at Cambridge, Manchester, and Teddington, it is probably the latter that inspires the least passion. Ii the punching of programs in pure binary was an efficient method, it was also a singularly uninspiring one. Curiously, aficionados of the Pilot ACE and the DEUCE had great enthusiasm for programming these machines, which really had more to do with the joys of optimum coding and exploiting the eccentric architecture than with any merits of the programming system.

    In many ways the crudity of the programming system for the Pilot ACE was understandable: the speed of events, the lack of a backing store, and so on. But perpetuating it on the DEUCE was a minor tragedy; by replicating the programming system on the 32 commercially manufactured DEUCES, literally hundreds of rank-and-file programmers were imbued in this poor style of programming. MOSAIC (Section 3.4) shows that it was entirely possible to devise a satisfactory programming system for machines of the ACE pattern; it is most unfortunate that this work was not well enough known to influence events.

    NPL did, however, have one notable programming-success: the GIP matrix scheme devised by Woodger and Munday. This scheme became the sole reason for the existence of many DEUCES. The reliability of the mathematical programs produced by NPL, their comprehensiveness, and their speed have become almost legendary. A history of numerical methods in Britain would no doubt reveal the true role of NPL in establishing the methods of linear algebra as an analytical tool for the engineer.

    In an interview, P. M. Woodward, one of the principals of the TREAC programming activity, recalled, "Our impression was that Cambridge mattered in software whereas Manchester mattered in hardware" (Woodward and Jenkins 1977). He might well have added that NPL mattered in numerical methods.

    Because this paper has been primarily concerned with the development of programming during the period 1945-1955, Cambridge has received pride of place as the leading innovator. Had the paper been concerned principally with hardware or numerical methods, however, the ranking of the three centers would have been different. But considered purely as innovators of programming, there can be no question that Cambridge stood well above the rest.
    Abstract: By 1950 there were three influential centers of programming in Britain where working computers had been constructed: Cambridge University (the EDSAC), Manchester University (the Mark I), and the National Physical Laboratory (the Pilot ACE). At each of these centers a distinctive style of programming evolved, largely independently of the others. This paper describes how the three schools of programming influenced programming for the other stored-program computers constructed in Britain up to the year 1955. These machines included several prototype and research computers, as well as five commercially manufactured machines. The paper concludes with a comparative assessment of the three schools of programming.


          in Annals of the History of Computing 4(2) April 1982 IEEE view details
    Resources
    • From Computer 50 Org
      However with the appointment of Cicely Popplewell to Electrical Engineering in the summer of 1949, effort started to be put directly into satisfying the requirements of the programming community. In 1950 Turing and Cicely designed the programming system for the Ferranti Mark 1 (Scheme A), based on their experience with the Manchester Mark 1, and Turing wrote the first programming manual for it.

      But it was not really until Turing withdrew from active work on the Mark 1 project and R.A. (Tony) Brooker was appointed in 1951 as formal leader of the software side that Kilburn's Computer Group acquired a strong focus on users' requirements.

      Tony Brooker led the software development, first improving the programming system (Scheme B) and then addressing the problem of user languages. There was no assembly language for the Mark 1, only an ingenious but daunting method of writing programs in binary using a base-32 character set, designed by Turing. Brooker bypassed the Assembly Language stage by designing a simple "high-level language", the Mark 1 Autocode, as an alternative to Turing's method. This was gratefully received (in 1954) by the programming community!

      Cicely Popplewell concentrated on the practicalities of running the Computer Service. To provide a formal Computing Service for outside users was a requirement of the government money put into the project, and in the long term it was a major source of internal funding for future computer development. The power of the Ferranti Mark 1 was far more than was required by the department or even the University. As ever in Tom Kilburn's career the operation was a significant and pioneering one, due to the new situation created by the new computing development (though in this case Tony Brooker would have been able to bring in useful experience from Cambridge).

      external link
    • Sumner on Scheme A
      I duly went, and said that Christopher sent me over to discuss using the computer. Turing's response was "Here, read that", handing me a book. It was the Mark 1 Program- ming Manual, which he had written himself. "Then go and see Cicely Poppelwell, who will give you some time on the machine, and start programming." End of conversation.

      I disappeared for a couple of months, and discovered that the perfect way to write a tutorial textbook is to fill it full of examples, none of which work. That might be an exaggeration - let's say most didn't work. Turing was like that: if he wrote 'k' instead of 't', he knew it was 'k', so why bother to do all that proof reading? So all the programs written in Mark 1 code had slight errors in them, and by the time you had worked out what the code should have been you had become quite a competent programmer.

      You then constructed your program. You know all the things you are taught to do nowadays: write a small module with clean interfaces, employing top down design; test your procedure; embed it; test it some more - all the good stuff we still try to teach students. I didn't do any of that. They gave me a problem and I simply wrote a program to print out the answers and took it to the machine. A few months later, it worked!

      To achieve that I acquired a copy of the second edition of the manual, which was written by Tony Brooker. It is the most glorious piece of understatement you could imagine. At the beginning it says, "Much material has been taken over and altered, or only slightly modified, from the first edition written by AM Turing". `Slightly modified' meant about one character in every 20.

      Brooker acknowledges Cicely Poppelwell, Nick Hoskin, Alec Glennie - names some readers might remember. There wasn't a big group working at that time.
      external link
    • Scheme A page at Computer 50
      external link