\transSec{PROGRAMMERING - GRUNDLAGET 
FOR DATAMATERNES FLEKSIBILITET}{Programmierung - Die Grundlage für die Flexibilität der Datenautomaten}

\transSubSec{Programmer og maskiner}{Programme und Maschinen}

\trans{
Vi skal i dag vende os til endnu et af aspekterne af svaret på spørgsmålet om datamaternes samfundsmæssige betydning. Den del af svaret jeg i dag skal belyse i enkeltheder lyder i korthed: på grund af deres enestående evne til at omstilles fra at løse ét problem til et andet, eller endnu kortere: på grund af deres fleksibilitet. Vi skal tale om forudsætningerne for denne fleksibilitet, der hænger sammen med det der betegnes deres programmering. 

Begrebet programmering er almindelig kendt i flere sammenhæng der ikke har noget med datamater at gøre, Selve ordet program bruges om en liste over begivenheder der skal finde sted, for eksempel ved en koncert. For så vidt som de medvirkende benytter et foreliggende program som vejledning ved deres optræden er et koncertprogram et simpelt eksempel på det vi her skal tale om. Et andet velkendt eksempel, som viser hvordan en mekanisme kan udføre programmet, er styringen af en moderne vaskemaskine. Som bekendt kan sådanne maskiner udføre flere forskellige funktioner, vask, skylning, centrifugering og tørring. Ved hver brug af maskinen har man mulighed for at vælge mellem en række forskellige programmer, det vil sige udvalg af disse funktioner i visse rækkefølger. 

Dette sidste eksempel viser allerede de træk der er karakteristiske for programmering af maskiner. Fordelen er fleksibiliteten, muligheden for at det samme apparat bruges til flere formål. Prisen for denne fordel er at maskinen som den leveres endnu ikke er parat til at udføre nyttigt arbejde. Der kræves stadig en indsats fra brugeren, nemlig at han blandt de foreliggende muligheder vælger den som passer for den opgave han ønsker at få løst. 

For nu at komme til vort egentlige emne, datamaterne, så skal vi først indse hvorfra de har fået deres helt enestående fleksibilitet. Vi har allerede i den tredie forelæsning omtalt hvorledes løsningen af en opgave i en datamat må udtrykkes ved en lang serie af elementære processer, der udføres i en bestemt rækkefølge. Det springende punkt er nu at indse at det der kræves til at beskrive styringen af en datamat til at løse en bestemt opgave i sig selv kan repræsenteres ved data, og dernæst at drage konsekvensen af denne erkendelse. 

Den første del heraf er simpel nok. Der er ikke svært at forstå at hver af de elementære processer kan betegnes ved passende bogstaver eller ord, og at den samlede følge af dem kan beskrives ved at opskrive disse ord i den rigtige rækkefølge. Når dette er gjort er processen beskrevet ved data. 
}{
Wir werden uns heute einem weiteren Aspekt der Antwort auf die Frage nach der gesellschaftlichen Bedeutung der Datenautomaten zuwenden. Der Teil der Antwort, den ich heute im Detail erläutern werde, lautet in Kürze: aufgrund ihrer einzigartigen Fähigkeit, sich von der Lösung eines Problems auf ein anderes umzustellen, oder noch kürzer: aufgrund ihrer Flexibilität. Wir werden über die Voraussetzungen für diese Flexibilität sprechen, die mit dem zusammenhängt, was als ihre \emph{Programmierung} bezeichnet wird.

Der Begriff Programmierung ist allgemein bekannt in mehreren Zusammenhängen, die nichts mit Datenautomaten zu tun haben. Das Wort \enquote{Programm} selbst wird für eine Liste von Ereignissen verwendet, die stattfinden sollen, zum Beispiel bei einem Konzert. Soweit die Mitwirkenden ein vorliegendes Programm als Anleitung bei ihrem Auftritt verwenden, ist ein Konzertprogramm ein einfaches Beispiel für das, worüber wir hier sprechen werden. Ein weiteres bekanntes Beispiel, das zeigt, wie ein Mechanismus das Programm ausführen kann, ist die Steuerung einer modernen Waschmaschine. Wie bekannt ist, können solche Maschinen mehrere verschiedene Funktionen ausführen: Waschen, Spülen, Schleudern und Trocknen. Bei jeder Verwendung der Maschine hat man die Möglichkeit, zwischen einer Reihe verschiedener Programme zu wählen, das heißt, eine Auswahl dieser Funktionen in bestimmten Reihenfolgen.

Dieses letzte Beispiel zeigt bereits die Merkmale, die für die Programmierung von Maschinen charakteristisch sind. Der Vorteil ist die Flexibilität, also die Möglichkeit, dasselbe Gerät für mehrere Zwecke zu verwenden. Der Preis für diesen Vorteil ist, dass die Maschine, wie sie geliefert wird, noch nicht bereit ist, nützliche Arbeit zu verrichten. Es erfordert weiterhin einen Einsatz des Benutzers, dass er nämlich unter den vorhandenen Möglichkeiten diejenige wählt, die für die Aufgabe passt, die er gelöst haben möchte.

Um nun zu unserem eigentlichen Thema, den Datenautomaten, zu kommen, müssen wir zuerst erkennen, woher sie ihre ganz außergewöhnliche Flexibilität erhalten haben. Wir haben bereits in der dritten Vorlesung erwähnt, wie die Lösung einer Aufgabe in einem Datenautomaten ausgedruckt werden muss: durch eine lange Serie elementarer Prozesse, die in einer bestimmten Reihenfolge ausgeführt werden. Der entscheidende Punkt ist nun zuerst zu erkennen, dass das, was zur Beschreibung der Steuerung eines Datenautomaten erforderlich ist, um eine bestimmte Aufgabe zu lösen, selbst durch Daten dargestellt werden kann, und anschießend die Konsequenz aus dieser Erkenntnis zu ziehen.

Der erste Teil hiervon ist einfach genug. Es ist nicht schwer zu verstehen, dass jeder der elementaren Prozesse durch passende Buchstaben oder Wörter bezeichnet werden kann und dass die gesamte Abfolge von ihnen beschrieben werden kann, indem man diese Wörter in der richtigen Reihenfolge niederschreibt. Wenn dies getan ist, wird der Prozess durch Daten beschrieben.
}

\transSubSec{Lagring af programmet}{Speichern des Programmes}
\trans{
Den anden del af sagen gemmer en af den slags ideer som kun opstår hos et geni, men som alle vi andre bagefter hilser med reaktionen: ja, naturligvis, det siger da sig selv. Ideen opstod hos matematikerne Von Neumann og Goldstine $^{(1.1)}$ omkring 1946, da der allerede var bygget store og komplicerede regnemaskiner som ikke benytter ideen. Ideen går ud på at de data som beskriver den proces vi ønsker at datamaten skal gennemføre, lagres i datamatens indre lager, ligesom de data der skal bearbejdes ved procescen. 

Nutildags forekommer denne idé så indlysende og simpel at unge mennesker der stifter bkendtskab med datamaterne oftest slet ikke bemærker den. For at forstå den enorme gevinst denne idé indebærer må man tænke på hvordan arbejdet med de tidligere store regnemaskiner foregik. Et godt eksempel er maskinen Eniac, den første elektroniske regnemaskine fra 1946. Eniac blev styret af impulser der blev ledet gennem kabler der frit kunne forbindes gennem en stikprop i hver ende, på lignende måde som det foregår ved en gammeldags telefoncentral. For at sætte maskinen i sving med at løse en bestemt opgave måtte man først montere alle de nødvendige kabler mellem de rigtige punkter rundt i maskinen. For en enkelt opgave løb antallet af kabler der skulle anbringes op på hundreder eller tusinder. Dertil kom en mulighed for at indstille talværdier ved at dreje på knapper, der ligeledes var fordelt over maskinen i et stort antal. Det er ikke svært at forestille sig at denne måde at forberede maskinen til at løse en opgave normalt tog flere dage. Igennem hele denne tid lå maskinen uvirksom hen. 

Ved en datamat, altså en maskine der styres gennem et program der ligger i dens lager, kræves der til at forberede den til at løse en bestemt opgave at programmet overføres fra et ydre datamedium til datamatens indre lager. Allerede ved de datamater der byggedes omkring 1950 kunne denne overføring foregå med en hastighed af mange tegn i sekundet, og hvor man tidligere måtte regne maskinernes omstillingstid i dage kunne fra dette tidspunkt selv omfattende programmer overføres på få minutter eller sekunder. 

Når man hertil føjer at de programmer der kan rummes i datamaterne repræsenterer en hidtil ukendt mangfoldighed med hensyn til metoder og komplikationer, så skulle datamaternes enestående fleksibilitet være godtgjort. 
}{
Der andere Teil der Sache enthält eine dieser Ideen, die nur bei einem Genie entstehen, aber die wir alle nachträglich mit der Reaktion begrüßen: Ja, natürlich, das versteht sich doch von selbst. Die Idee entstand bei den Mathematikern Von Neumann und Goldstine $^{(1.1)}$ um 1946 herum, als bereits große und komplizierte Rechenmaschinen gebaut worden waren, die die Idee nicht nutzten. Die Idee besteht darin, dass die Daten, die den Prozess beschreiben, den wir möchten, dass der Datenautomat ausführt, im internen Speicher des Datenautomaten gespeichert werden, ebenso wie die Daten, die beim Prozess bearbeitet werden sollen.

Heutzutage erscheint diese Idee so offensichtlich und einfach, dass junge Menschen, die mit Datenautomaten in Berührung kommen, sie oft gar nicht bemerken. Um den enormen Gewinn dieser Idee zu verstehen, muss man darüber nachdenken, wie die Arbeit mit den früheren großen Rechenmaschinen ablief. Ein gutes Beispiel ist die Maschine Eniac, die erste elektronische Rechenmaschine von 1946. Eniac wurde durch Impulse gesteuert, die durch Kabel geleitet wurden, die frei durch einen Stecker an jedem Ende verbunden werden konnten, analog zu einer (bereits zur Zeit Naurs) altmodischen Telefonzentrale. Um die Maschine dazu zu bringen, eine bestimmte Aufgabe zu lösen, musste man zuerst alle notwendigen Kabel zwischen den richtigen Punkten in der Maschine anbringen. Für eine einzige Aufgabe mussten hunderte oder tausende Kabel angebracht werden. Dazu kam die Möglichkeit, Zahlenwerte durch Drehen an Knöpfen einzustellen, die ebenfalls in großer Zahl über die Maschine verteilt waren. Es ist nicht schwer, sich vorzustellen, dass diese Art, die Maschine für die Lösung einer Aufgabe vorzubereiten, normalerweise mehrere Tage dauerte. Während dieser ganzen Zeit konnte die Maschine nicht genutzt werden.

Um einen Datenautomaten -- also einer Maschine, die durch ein Programm gesteuert wird, das sich in ihrem Speicher befindet -- auf die Lösung einer bestimmten Aufgabe vorzubereiten, ist es notwendig, dass das Programm von einem externen Datenträger in den internen Speicher des Datenautomaten übertragen wird. Schon bei den Datenautomaten, die um 1950 gebaut wurden, konnte diese Übertragung mit einer Geschwindigkeit von vielen Zeichen pro Sekunde erfolgen, und während man früher die Umstellungszeit der Maschinen in Tagen berechnete, konnten ab diesem Zeitpunkt selbst umfangreiche Programme in wenigen Minuten oder Sekunden übertragen werden.

Wenn man hinzufügt, dass die Programme, die in den Datenautomaten untergebracht werden können, eine bislang unbekannte Vielfalt in Bezug auf Methoden und Funktionen darstellen, dann sollte die außergewöhnliche Flexibilität der Datenautomaten bewiesen sein.
}

\transSubSec{Programmeringens problemer}{Die Probleme der Programmierer}

\trans{

Ethvert afgørende gennembrud indebærer nye problemer, simpelthen derigennem at der i en vis sammenhæng altid er ét problem der er det værste og som derfor trænger sig på. Den lette adgang til at omstille datamaterne fra den ene opgave til den anden forrykkede problemet med at få de nyttige resultater ud af datamaterne, fra at være primært knyttet til apparaterne over til brugerne og deres skriveborde. Det viste sig meget hurtigt at dette var et problem af betydelige dimensioner. Brugeren af en datamat må udforme en beskrivelse af den måde datamaten skal gå frem under løsningen af hans opgave, han må med andre ord skrive et program for løsningen. Programmet består af en række instruktioner til datamaten, som hver svarer til en af de elementære processer som den er bygget til at kunne udføre. Brugeren må derfor gennemarbejde løsningen af sin opgave på en sådan form at den fremtræder som en følge af disse simple processer. 

Denne situation har givet anledning til problemer af to helt forskellige arter, som vi skal tage op i tur og orden. For det første har det givet store vanskeligheder for dem der udarbejder programmerne at beherske de komplikationer der kan tillades i processer der kan udføres i nutidens datamater. Man kan også udtrykke det på den måde at maskinkonstruktørerne er forud for brugerne. Nutidens datamater kan inden for få minutter udføre processer der består af millioner af elementære procestrin. Men at beherske procesbeskrivelser af en sådan komplicerethed, samtidig med at der kræves den yderste, pinlige korrekthed i beskrivelsen, er et problem uden sidestykke i nogen hidtil kendt menneskelig aktivitet. De få år der hidtil er forløbet siden dette krav første gang blev stillet har ikke været tilstrækkelige til at vi blot kan skimte problemets endelige løsning. 
}{
Jeder entscheidende Durchbruch bringt neue Probleme mit sich -- einfach dadurch, dass es in einem bestimmten Zusammenhang immer ein Problem gibt, dass das größte ist und sich daher aufdrängt. Der leichte Zugang zur Umstellung der Datenautomaten von der einen Aufgabe zur anderen verschob das Problem, nützliche Ergebnisse aus den Datenautomaten zu erhalten, von den primären Verbindungen innerhalb der Geräte hin zu den Benutzern an ihren Schreibtischen. Es zeigte sich sehr schnell, dass dies ein Problem von beträchtlichem Ausmaß war. Der Benutzer eines Datenautomaten muss eine Beschreibung der Vorgehensweise ausarbeiten, wie der Datenautomat bei der Lösung seiner Aufgabe vorgehen soll. Mit anderen Worten: er muss ein Programm für die Lösung schreiben. Das Programm besteht aus einer Reihe von Anweisungen an den Datenautomaten, die jeweils einer der elementaren Prozesse entsprechen, zu deren Ausführung er konstruiert ist. Der Benutzer muss daher die Lösung seiner Aufgabe in einer Form beschreiben, die einer Abfolge dieser einfachen Prozesse entspricht.

Diese Situation hat Anlass zu Problemen von zwei völlig unterschiedlichen Arten gegeben, die wir der Reihe nach aufgreifen werden. Erstens hat es große Schwierigkeiten verursacht für diejenigen, die die Programme ausarbeiten, die Funktionen zu beherrschen, die in Prozessen zugelassen werden können, die in den heutigen Datenautomaten ausgeführt werden können. Man kann es auch so ausdrücken, dass die Maschinenkonstrukteure den Benutzern voraus sind. Die heutigen Datenautomaten können innerhalb weniger Minuten Prozesse ausführen, die aus Millionen elementarer Prozessschritte bestehen. Aber das Beherrschen von Prozessbeschreibungen einer solchen Komplexität, gleichzeitig mit der Anforderung an äußerste, peinliche Genauigkeit in der Beschreibung, ist ein Problem ohne Beispiel in irgendeiner bisher bekannten menschlichen Tätigkeit. Die wenigen Jahre, die bisher vergangen sind, seit diese Anforderung zum ersten Mal gestellt wurde, haben nicht ausgereicht, damit wir auch nur die endgültige Lösung des Problems erahnen können.
}

\transSubSec{Højere programmeringssprog}{Höhere Programmiersprachen}

\trans{Der er dog sket store forbedringer, og den hidtil skete udvikling giver en klar pegepind i den retning vi må vente fremtidens udvikling. Mottoet for denne er klar nok: lad datamaterne selv hjælpe brugerne også på dette område. Den første afgørende anvendelse af denne tanke har allerede siden omkring 1960 været i helt almindelig brug ved de fleste datamater. Denne anvendelse kan kort beskrives som følger: tillad brugerne at beskrive deres løsninger på en for mennesker bekvem form og overlad det til datamaten selv at oversætte disse beskrivelser til den form som kræves i datamaten selv. Tankegangen er at det som umiddelbart kan udføres ved en elementær proces i en datamat er meget lidt, samtidig med at den besked som datamaten forlanger for at udføre processen fra vort synspunkt er meget omstændelig. Ved at indføre en oversættelse som mellemled kan denne forskel mellem datamaten og brugerne få lov til at bestå uden væsentlig ulempe for nogen af parterne. 

Lad os for at illustrere denne tanke betragte et helt simpelt regnestykke, det at lægge to tal sammen. Fra den elementære matematik er vi vant til at betegne talstørrelser ved bogstaver, a og b for eksempel, og sammenlægningen udtrykkes som a+b. Et sådant udtryk optræder naturligvis ikke isoleret, men i en større sammenhæng hvor bogstaverne a og b benyttes på ensartet måde til at betegne bestemte, vedtagne ting. Vi mennesker er vant til og har let ved at opfatte sådanne tegn i en større sammenhæng — hele vor brug af sproget beror derpå. 

I en datamat kan vi slet ikke benytte os af en sådan evne til at forstå ting i en større sammenhæng. Datamaten kræver for at kunne udføre sammenlægningen af tallene en ganske udtrykkelig besked om hvor i dens lager de befinder sig. Denne besked består i en angivelse af nummeret på de celler der opbevarer værdierne. Disse numre kan ikke udtrykkes ved et enkelt tegn, da der normalt må kunne skelnes mellem mange tusinde forskellige. Alene til at udtrykke hvilke to tal der skal lægges sammen kræver datamaten derfor omkring otte tegn. Dertil kræves besked om at vi netop ønsker en addition, hvilket yderligere kræver et tegn eller to i den besked vi må give datamaten. 

Det er denne omstændelighed i datamaternes måde at beskrive de elementære processer som gør den direkte programmering af dem så ubekvem for mennesker. Denne ubekvemmelighed fjernes når man bruger de højere programmeringssprog som siden omkring midten af 1950erne har vundet stadig mere indpas ved anvendelsen af datamater. Disse programmeringssprog, der er kendt ved navne som Fortran, Algol, og Cobol, tillader netop brugerne at udtrykke sig på en bekvem og koncis form og sparer derfor brugerne både for besvær og fejltagelser. 
}{
Es sind jedoch große Verbesserungen geschehen, und die bisherige Entwicklung gibt einen klaren Hinweis auf die Richtung, in der wir die zukünftige Entwicklung erwarten müssen. Das Motto dafür ist klar genug: lasst die Datenautomaten den Benutzern auch in diesem Bereich helfen. Die erste entscheidende Anwendung dieses Gedankens ist bereits seit etwa 1960 im ganz normalen Gebrauch bei den meisten Datenautomaten. Diese Anwendung kann kurz wie folgt beschrieben werden: erlaubt den Benutzern, ihre Lösungen in einer für Menschen bequemen Form zu beschreiben, und überlasst es dem Datenautomaten selbst, diese Beschreibungen in die Form zu übersetzen, die im Datenautomaten selbst erforderlich ist. Der Gedanke dahinter ist, dass das, was unmittelbar durch einen elementaren Prozess in einem Datenautomaten ausgeführt werden kann, sehr wenig ist, während gleichzeitig die Anweisung, die der Datenautomat verlangt, um den Prozess auszuführen, aus unserer Sicht sehr umständlich ist. Durch die Einführung einer Übersetzung als Zwischenstufe kann dieser Unterschied zwischen dem Datenautomaten und den Benutzern bestehen bleiben, ohne wesentlichen Nachteil für eine der Parteien.

Lasst uns, um diesen Gedanken zu veranschaulichen, ein ganz einfaches Rechenbeispiel betrachten: nämlich das Addieren zweier Zahlen. Aus der elementaren Mathematik sind wir es gewohnt, Zahlenwerte durch Buchstaben zu bezeichnen, a und b zum Beispiel, und die Addition wird als a+b ausgedrückt. Ein solcher Ausdruck erscheint natürlich nicht isoliert, sondern in einem größeren Zusammenhang, wo die Buchstaben a und b erneut verwendet werden, um bestimmte, vereinbarte Dinge zu bezeichnen. Wir Menschen sind daran gewöhnt und haben es leicht, solche Zeichen in einem größeren Zusammenhang zu erfassen —- unsere gesamte Verwendung der Sprache beruht darauf.

In einem Datenautomaten können wir uns überhaupt nicht einer solchen Fähigkeit bedienen, Dinge in einem größeren Zusammenhang zu verstehen. Stattdessen verlangt der Datenautomat, um die Addition der Zahlen ausführen zu können, eine ganz ausdrückliche Anweisung darüber, wo sie sich in seinem Speicher befinden. Diese Anweisung beinhaltet daher die Angabe der Nummern der Speicherzellen, die die Werte speichern. Diese Nummern können nicht durch ein einzelnes Zeichen ausgedrückt werden, da normalerweise zwischen vielen tausenden (derartiger Speicherzellen) unterschieden werden muss. Allein um auszudrücken, welche zwei Zahlen addiert werden sollen, verlangt der Datenautomat daher etwa acht Zeichen. Dazu wird eine Anweisung benötigt, dass wir eine Addition wünschen, was zusätzlich ein oder zwei Zeichen in der Anweisung erfordert, die wir dem Datenautomaten geben müssen.

Es ist diese Umständlichkeit in der Art, wie die Datenautomaten die elementaren Prozesse beschreiben, die die direkte Programmierung von ihnen für Menschen so unbequem macht. Diese Unbequemlichkeit wird beseitigt, wenn man die höheren Programmiersprachen verwendet, die seit etwa Mitte der 1950er Jahre immer mehr Verbreitung bei der Nutzung von Datenautomaten gefunden haben. Diese Programmiersprachen, die unter Namen wie Fortran, Algol und Cobol bekannt sind, erlauben es den Benutzern, sich in einer bequemen und prägnanten Form auszudrücken und ersparen den Benutzern dadurch sowohl Mühe als auch Fehler.
}

\transSubSec{Programoversættelse}{Programmübersetzung}

\trans{
Til gengæld kan et program der er udtrykt på denne form ikke umiddelbart udføres i en datamat. Det må først oversættes til den mere omstændelige form som datamaten kræver. Denne oversættelse kan dog udføres af datamaten selv når først der foreligger et oversætterprogram. At udarbejde et oversætterprogram er en ret omfattende, men dog overkommelig, opgave, og den behøver kun at gennemføres én gang for en bestemt datamat og et bestemt programmeringssprog, derefter kan oversætteren bruges til at oversætte stadig nye programmer i det uendelige. En væsentlig fordel ved mellemvejen over en oversætter er at denne kan udformes således at den giver rapport til brugeren om visse typer af fejltagelser, stavefejl, og lignende, som brugeren kan have begået selv i det bekvemme programmeringssprog. 

Når der bruges et højere programmeringssprog foregår en kørsel med datamaten på følgende måde. Først udarbejder brugeren sit program som et sædvanligt skrevet manuskript. Når dette er færdigt overføres det til et af de datamedier som datamaten kan læse, for eksempel hulstrimmel eller hulkort. Dette arbejde udføres af hullepersonale der læser teksten og trykker på taster på en skrivemaskine, der er koblet til en hullemaskine. Når datamaten derefter bliver til rådighed sættes den først til at adlyde oversætterprogrammet. Dette må muligvis først læses ind i dens lager fra et datamedium, men hertil vælges normalt et hurtigt medium således at tiden dertil er ubetydelig. Under styring af oversætterprogrammet læses nu brugerens tekst fra hulstrimlen eller hulkortene og underkastes dels en nøje kontrol for fejl, dels en omdannelse til instruktioner af den form som kan styre datamaten selv. Mens oversættelsen står på behandles disse instruktioner blot som data der skal gemmes til side til senere brug. Først når hele brugerens program er oversat til instruktioner på den form som datamaten kræver overtager det styringen af datamaten og først på dette stadium udføres den proces som brugeren har foreskrevet. Denne proces vil også normalt kræve tilført data udefra, for eksempel fra magnetbånd, ligesom den må aflevere sine resultater på et ydre medium som kan bruges uafhængigt af datamaten. 

Hele denne følge af skift mellem forskellige arter af processer gennemføres under styring af programmer i datamaten selv og en ringe mængde indgreb fra en operatør. For mindre programmer med beskedne datamængder kan det hele afvikles på få sekunder. Hvis en kørsel varer mere end få minutter er det som oftest fordi der er en stor mængde data at bearbejde. 
}{
Im Gegenzug kann ein Programm, das in dieser Form ausgedrückt ist, nicht direkt in einem Datenautomaten ausgeführt werden. Es muss stattdessen zuerst in die umständlichere Form übersetzt werden, die der Datenautomat benötigt. Diese Übersetzung kann jedoch vom Datenautomaten selbst durchgeführt werden, sobald ein Übersetzungsprogramm vorliegt. Die Erstellung eines Übersetzungsprogramms ist eine ziemlich umfangreiche, aber dennoch machbare Aufgabe, und sie muss nur einmal durchgeführt werden, für einen bestimmten Datenautomaten und eine bestimmte Programmiersprache -- danach kann der Übersetzer verwendet werden, um immer wieder neue Programme beliebig oft zu übersetzen. Ein wesentlicher Vorteil des Umwegs über einen Übersetzer ist, dass dieser so gestaltet werden kann, dass er dem Benutzer Bericht erstattet über bestimmte Arten von Fehlern, Rechtschreibfehlern und Ähnliches, die der Benutzer selbst in der bequemen Programmiersprache gemacht haben könnte

Wenn eine höhere Programmiersprache verwendet wird, erfolgt ein Lauf mit dem Datenautomaten folgendermaßen: Zuerst erstellt der Benutzer sein Programm wie ein gewöhnlich geschriebenes Manuskript. Wenn dies fertig ist, wird es auf eines der Datenträger übertragen, die der Datenautomat lesen kann, zum Beispiel Lochstreifen oder Lochkarten. Diese Arbeit wird vom Lochkartenpersonal ausgeführt, das den Text liest und auf die Tasten einer Schreibmaschine drückt, die mit einer Lochmaschine verbunden ist. Wenn der Datenautomat dann zur Verfügung steht, wird er zunächst so eingestellt, dass er dem Übersetzungsprogramm folgt. Dieses muss möglicherweise zuerst von einem Datenträger in seinen Speicher geladen werden, aber dafür wird normalerweise ein schnelles Medium gewählt, sodass die Zeit dafür unbedeutend ist. Unter der Steuerung des Übersetzungsprogramms wird der Text des Benutzers nun von den Lochstreifen oder Lochkarten gelesen und einerseits  einer genauen Fehlerüberprüfung unterzogen und anderseits in Anweisungen umgewandelt, die den Datenautomaten selbst steuern können. Während der Übersetzung werden diese Anweisungen lediglich als Daten behandelt, die zur späteren Verwendung beiseitegelegt werden. Erst wenn das gesamte Programm des Benutzers in Anweisungen übersetzt ist, in die Form, die der Datenautomat verlangt, übernimmt es die Steuerung des Datenautomaten, und erst in diesem Stadium wird der Prozess ausgeführt, den der Benutzer vorgeschrieben hat. Dieser Prozess erfordert normalerweise auch Daten von außen, zum Beispiel von Magnetbändern, ebenso wie er seine Ergebnisse auf einem externen Medium ausgeben muss, das unabhängig vom Datenautomaten verwendet werden kann.

Die gesamte Abfolge von Wechseln zwischen verschiedenen Arten von Prozessen wird unter der Steuerung von Programmen im Datenautomaten selbst durchgeführt und mit geringem Eingreifen eines Bedieners. Für kleinere Programme mit bescheidenen Datenmengen kann das Ganze in wenigen Sekunden abgewickelt werden. Wenn ein Lauf länger als ein paar Minuten dauert, liegt es meist daran, dass eine große Menge an Daten bearbeitet werden muss.
}



\transSubSec{Fuldstændige beskrivelser af dataprocesser}{Vollständige Beschreibung von Datenprozessen}

\trans{
De problemer vedrørende datamaternes programmering vi indtil nu har omtalt har været af forholdsvis triviel natur; et fremtrædende tema har været den større eller mindre bekvemmelighed. Vi skal nu drøfte et problem af en ganske anden art, som rummer langt dybere perspektiver, nemlig det bagved programmeringen liggende problem at udtrykke kendte aktiviteter i form af klart definerede processer. 

Lad os først bemærke at selve begrebet en fuldt defineret proces ikke hidtil har været ukendt. Når vi i de første skoleår træner børnene i regning er det netop sådanne mekaniske dataprocesser der indøves. Men lad os også med det samme erkende at dette begreb har ført en noget hensygnende tilværelse, i alle tilfælde i skoleundervisningen. Det er især bemærkelsesværdigt at selve de regneprocesser der indøves med så stor iver i de tidlige skoleår ikke i den senere matematikundervisning betragtes som eksempler på mere generelle dataprocesser. 

Enhver vejledning i at gøre noget er en procesbeskrivelse, og af sådanne træffer vi mange i dagliglivet. Man behøver blot at minde om hobbymandens byggevejledning og pigernes strikkeopskrifter. Inden for forvaltning og erhversliv træffer vi procesbeskrivelser i form af instrukser, ligesom en væsentlig del af lovgivningen består af procesbeskrivelser, for eksempel de love efter hvilke skatten beregnes, eller valgloven med reglerne for hvordan mandatfordelingen beregnes. Også en stor del af mere krævende konstruktivt arbejde drejer sig om processer. Hvad enten man ønsker at konstruere huse, broer, eller biler er det afgørende at finde frem til en fornuftig arbejdsgang, hvilket igen kræver en beskrivelse af arbejdsprocessen. 

Ved de fleste af de her nævnte eksempler er de processer der er tale om hidtil blevet udført af mennesker. Følgen heraf har været, dels at beskrivelserne har kunnet være temrnaelig ufuldstændige, da mennesker besidder en overordentlig evne til fornuftigt at indføje det manglende, dels at den opfattelse har været gældende at de pågældende processer simpelthen krævede menneskers medvirken ved deres gennemførelse, altså ikke ville kunne automatiseres. 

Denne situation har ændret sig radikalt ved datamaternes fremkomst. Datamaterne stiller ubønhørlige krav om en komplet beskrivelse af de processer de skal udføre. I første omgang er dette en ny og besværlig belastning for dem der skal løse opgaverne. Det har dog i utallige tilfælde vist sig at dette nye krav om præcision snart har udviklet sig til et betydeligt gode, gennem den tankemæssige klarhed det bringer i sit kølvand. Ved at arbejde med fuldstændigt formaliserede beskrivelser af det vi har med at gøre lærer vi det at kende på en ny og inspirerende måde, vi opdager muligheder ved dem vi ikke før har set, og vi indser hvordan overflødigheder kan fjernes, med en tilsvarende gevinst i klarhed og økonomi. 

Utallige fagfolk fra vidt forskellige områder har ved deres første praktiske brug af en datamat til at løse problemer inden for deres eget felt erkendt sandheden i følgende udtalelse, som tilskrives den kendte amerikanske datalog, Alan Perlis: »Når man lærer om et emne tror man at man forstår det. Når man underviser 1 det er man overbevist om at man forstår det. Men man forstår det først når man har programmeret det for en datamat.« 
}{
Die Probleme bezüglich der Programmierung von Datenautomaten, die wir bisher besprochen haben, waren von relativ trivialer Natur; ein hervorstechendes Thema war die größere oder geringere Bequemlichkeit. Wir werden nun ein Problem ganz anderer Art erörtern, das viel tiefere Perspektiven eröffnet, nämlich das der Programmierung zugrunde liegende Problem, bekannte Aktivitäten in Form klar definierter Prozesse auszudrücken.

Lasst uns zuerst bemerken, dass das eigentliche Konzept eines vollständig definierten Prozesses bisher nicht unbekannt war. Wenn wir in den ersten Schuljahren die Kinder im Rechnen schulen, sind es genau solche mechanischen Datenprozesse, die eingeübt werden. Aber lassen Sie uns auch sofort anerkennen, dass dieses Konzept ein eher kümmerliches Dasein geführt hat -- zumindest im Schulunterricht. Es ist besonders bemerkenswert, dass gerade die Rechenprozesse, die mit so großem Eifer in den frühen Schuljahren eingeübt werden, im späteren Mathematikunterricht nicht als Beispiele für allgemeinere Datenprozesse betrachtet werden.

Jede Anleitung, etwas zu tun, ist eine Prozessbeschreibung, und solchen begegnen wir häufig im Alltag. Man braucht nur an die Bauanleitungen des Hobbyhandwerkers und die Strickmuster $^{(4.1)}$ der Mädchen zu denken. Im Bereich der Verwaltung und der Wirtschaft begegnen wir Prozessbeschreibungen in Form von Instruktionen, ebenso wie ein wesentlicher Teil der Gesetzgebung aus Prozessbeschreibungen besteht, zum Beispiel die Gesetze, nach denen die Steuern berechnet werden, oder das Wahlgesetz mit den Regeln, wie die Mandatsverteilung berechnet wird. Auch ein großer Teil anspruchsvollerer Konstruktionsarbeiten dreht sich um Prozesse. Ob man nun Häuser, Brücken oder Autos entwerfen möchte, ist es entscheidend, einen vernünftigen Arbeitsablauf zu finden, was wiederum eine Beschreibung des Arbeitsprozesses erfordert.

Bei den meisten der hier genannten Beispiele wurden die betreffenden Prozesse bisher von Menschen ausgeführt. Die Folge davon war einerseits, dass die Beschreibungen recht unvollständig sein konnten, da Menschen eine außerordentliche Fähigkeit besitzen, fehlende Informationen vernünftig zu ergänzen, und anderseits, dass die Auffassung vorherrschte, die betreffenden Prozesse erforderten einfach die Mitwirkung von Menschen bei ihrer Durchführung -- das heißt, sie könnten nicht automatisiert werden.

Diese Situation hat sich durch das Aufkommen der Datenautomaten radikal verändert. Die Datenautomaten stellen unerbittliche Anforderungen an eine vollständige Beschreibung der Prozesse, die sie ausführen sollen. Zunächst ist dies eine neue und schwierige Belastung für diejenigen, die die Aufgaben lösen müssen. Es hat sich jedoch in unzähligen Fällen gezeigt, dass diese neue Anforderung an Präzision sich bald als ein erhebliches Gut erwiesen hat, durch die geistige Klarheit, die es mit sich bringt. Durch die Arbeit mit vollständig formalisierten Beschreibungen dessen, womit wir es zu tun haben, lernen wir es auf eine neue und inspirierende Weise kennen, wir entdecken Möglichkeiten, die wir vorher nicht gesehen haben, und wir erkennen, wie Überflüssiges entfernt werden kann, mit einem entsprechenden Gewinn an Klarheit und Effizienz.

Unzählige Fachleute aus ganz verschiedenen Bereichen haben bei ihrem ersten praktischen Einsatz eines Datenautomaten zur Lösung von Problemen in ihrem eigenen Fachgebiet die Wahrheit der folgenden Aussage erkannt, die dem bekannten amerikanischen \alt{Datalogen}{Informatiker} Alan Perlis zugeschrieben wird: \enquote{Wenn man über ein Thema lernt, glaubt man, dass man es versteht. Wenn man es lehrt, ist man überzeugt, dass man es versteht. Aber man versteht es erst, wenn man es für einen Datenautomaten programmiert hat.}
}

\transSubSec{Datamaterne og planlægningen}{Datenautomaten und Planung}

\trans{
Som sidste punkt i denne forelæsning er der grund til at tale et par ord om datamaternes forhold til planlægningen, som er så stærkt fremme i den offentlige debat. Herom kan der siges to ting. For det første burde det nu være klart at programmeringen af en datamat frem for alt drejer sig om planlægning. Et program er simpelthen en detailleret plan for hvad datamaten skal gøre, hvordan den skal opføre sig over for alle de eventualiteter der kan opstå under dataprocessernes afvikling. Der kan ikke gives nogen bedre træning i planlægningens tankegang end praktisk arbejde med programmering af datamater. Som en vigtig erfaring fra dette arbejde bør fremhæves menneskers begrænsninger overfor denne type af arbejde. Det er ganske enkelt dagens orden at et program der afleveres fra en programmør, selv en mester i faget, har fejl i sig, måske kun trivielle, men sådanne som når programmet prøvekøres i datamaten får den til at løbe helt vild. Lad denne kendsgerning være et memento til dem der vil have os til at tro at alle problemer kan løses gennem mere planlægning. 

En helt anden side er datamaternes eventuelle brug som hjælpemidler i planlægning. Dertil er først at sige at for så vidt planlægning forudsætter opsamling og bearbejdning af data om situationen som den eksisterer for øjeblikket vil datamaterne naturligvis være nyttige. Det er dog vigtigt at bemærke at datamaternes muligheder rækker langt videre, idet de gør det muligt at erstatte planlægning med styring, det vil sige en stadig overvågning af situationens udvikling og en sideløbende beregning af de til enhver tid mest gunstige forholdsregler. Min personlige vurdering er at der vil komme den dag da planlægning vil forekomme forældet som hjælpemiddel i samfundslivet, fordi datamaterne vil gøre det muligt for politikerne at gennemføre en hensigtsmæssig styring. 
}{
Als letzter Punkt in dieser Vorlesungseinheit gibt es Anlass, ein paar Worte über das Verhältnis der Datenautomaten zur Planung zu sagen, die so stark in der öffentlichen Debatte im Vordergrund steht. Dazu können zwei Dinge gesagt werden. Erstens sollte jetzt klar sein, dass die Programmierung eines Datenautomaten vor allem eine Frage der Planung ist. Ein Programm ist schlicht und einfach ein detaillierter Plan darüber, was der Datenautomat tun soll und wie er sich gegenüber allen Eventualitäten verhalten soll, die während der Durchführung der Datenprozesse auftreten können. Es gibt kein besseres Training für die Denkweise der Planung als praktische Arbeit mit der Programmierung von Datenautomaten. Als wichtige Erkenntnis aus dieser Arbeit sollte hervorgehoben werden, dass die Begrenzungen des Menschen gegenüber dieser Art von Arbeit bestehen. Es ist ganz einfach an der Tagesordnung, dass ein Programm, das von einem Programmierer, selbst von einem Meister des Fachs, abgegeben wird, Fehler enthält, vielleicht nur triviale, aber solche, dass, wenn das Programm im Datenautomaten getestet wird, es dazu führt, dass er völlig außer Kontrolle gerät. Lasst diese Tatsache eine Mahnung sein für diejenigen, die uns glauben machen wollen, dass alle Probleme durch mehr Planung gelöst werden können.

Eine ganz andere Seite ist der mögliche Einsatz von Datenautomaten als Hilfsmittel in der Planung. Dazu ist zuerst zu sagen, dass Datenautomaten hier natürlich nützlich sein werden, wenn diese Planung die Erfassung und Verarbeitung von Daten über die Situation, wie sie im Moment besteht, voraussetzt. Es ist jedoch wichtig zu bemerken, dass die Möglichkeiten der Datenautomaten weit darüber hinausreichen, indem sie es ermöglichen, Planung durch Steuerung zu ersetzen -- also durch eine ständige Überwachung der Entwicklung der Situation und eine gleichzeitige Berechnung der zu jedem Zeitpunkt günstigsten Maßnahmen. Meine persönliche Einschätzung ist, dass der Tag kommen wird, an dem Planung als Hilfsmittel im gesellschaftlichen Leben veraltet erscheinen wird, weil die Datenautomaten es den Politikern ermöglichen werden, eine zweckmäßige Steuerung durchzuführen.
}