Erinnerungen an Nat Rochester (1919-2001)

Nathaniel Rochester III, wie er mit vollem Namen hieß, war der amerikanische IBMer, der als erster unmittelbaren Einfluss auf meine berufliche Laufbahn nahm. Ich kannte ihn bereits vom Namen her, bevor ich ihn im Sommer 1963 persönlich kennenlernte. Wie in diesem Blog berichtet, traf ich ihn und seinen Kollegen Pete Sheridan im französischen IBM Labor in La Gaude, kurz nachdem das Algol-Projekt, an dem ich beteiligt war, beendet worden war. Er heuerte mich für ein Projekt in New York an, aus dem später die Programmiersprache PL/I hervorging. Während meiner Abordnung in New York von Oktober 1963 bis Juli 1964 war Rochester mein Bereichsleiter. Er hatte sein Büro in White Plains, NY. Mein Abteilungsleiter in New York berichtete an ihn.

Ich traf Rochester alle paar Wochen, wenn er sich über den Fortgang unseres Projekts erkundigte. Bei dem Abendessen in einem New Yorker Hotel, das ich erwähnte, war er der Gastgeber. Für von Frankreich verwöhnte Deutsche kam es einem Kulturschock gleich, da anstatt Wein nur Eiswasser geboten wurde. Seine Frau war eine der eifrigsten mit den Strickarbeiten vor und nach dem Essen. Nat Rochester hatte eine sehr verbindliche Art mit Kollegen innerhalb und außerhalb der Firma IBM zu verkehren. Man konnte fast meinen, es mit einem älteren Bruder zu tun zu haben.

Nach meiner Versetzung nach Poughkeepsie, NY, riss unser Kontakt für eine Weile ab. Später in Böblingen besuchte er mich und meinen Bereich etwa einmal pro Jahr. Rochester gehörte in dieser Zeit bereits zu den älteren Kollegen, die keine unmittelbare Projektverantwortung mehr besaßen, aber trotzdem großen technischen Einfluss nahmen. Dies ermöglichte ihm die Position eines IBM Fellows. Er konnte jederzeit überall aufkreuzen. Seine Ratschläge, die er vor Ort erteilte, konnten sehr nützlich sein. Seine anschließenden Berichte über Dinge, die ihm gefielen oder nicht gefielen, entschieden über den Ruf des Projekts und seiner Mitarbeiter in der technischen Community. Wie zu dieser Zeit üblich, war der für uns maßgebliche, weltweite fachliche Kollegenkreis ziemlich deckungsgleich mit IBM.

Über Rochesters fachliche Beiträge gibt die oben angegebene Wikipedia-Biografie einen guten Überblick. Ich zitiere deshalb lediglich aus einer IBM-Veröffentlichung [1], die eine kurze Zusammenfassung seines beruflichen Werdegangs brachte:

1948 trat er IBM in Poughkeepsie, NY, bei. Er entwarf das Testverfahren und leitete die Architektur-Arbeiten der Bandgeräte und der IBM 701. Er schrieb das erste symbolische Assembler-Programm, einen Vorgänger von SAP [dem späteren offiziellen Assembler-Programm].  Er hatte die technische Leitung der IBM 700 Serie während der Entwicklung der IBM 703,704, 705 und dem Beginn der 709. Er wechselte zur IBM Research Division bei deren Gründung  im Jahre 1955 und leitete den Bereich Computer-Theorie und experimenteller Computer-Entwurf.  Im Jahr 1961 trat er in die Data Systems Division (DSD) ein,  den Bereich, der unter anderem für IBM die ersten beiden Timesharing-Systeme, QWIKTRAN und CPS, entwickelte und den Entwurf der PL/I- Sprache betrieb. Seine Patente auf das Rechenwerk der 701 und auf die Variable-Wortgrößen-Architektur der Bandgeräte brachten ihm einen Outstanding  Invention Award von IBM.

Hinzufügen möchte ich, dass ein Outstanding Invention Award (OIA) für Forscher und Entwickler bei IBM eine der höchstgeschätzten Auszeichnungen war. Der damit verbundene Geldpreis glich für amerikanische Kollegen zum Teil die Vergütungen aus, die deutsche Erfinder aufgrund des Erfindervergütungsgesetzes automatisch erhielten. Qwiktran (Abk. für Quick Fortran) war ein auf der Sprache Fortran basierendes Timesharing-System für die IBM 7090. Es wurde von der IBM-Gruppe im Time/Life Center in New York City entwickelt. Das Conversational Programming System (CPS) war ein Timesharing-System, das als Prototyp vom Wissenschaftlichen Zentrum in Cambridge, MA, entwickelt worden war. Es unterstützte die Sprache BASIC. Die 700-Serie war die erste Familie von elektronischen Rechnern, mit der IBM nach dem Erfolg in der Lochkartentechnik das neue Gebiet betrat. Sie waren noch mit Röhren bestückt; erst mit der IBM 7090 nahmen Transistoren Einzug.

                                    

In der Zeit, als ich mit Nat Rochester in Kontakt stand, waren es außer Programmiersprachen und Timesharing-Systemen noch zwei weitere technische Themen, die ihn persönlich beschäftigten. Ich will kurz an sie erinnern.

Dilemma der Tastaturbelegung

Jeder, der heute eine Tastatur benutzt, fragt sich warum die Buchstaben so angeordnet sind, dass oben links die Reihenfolge QWERTY (oder in Deutschland QWERTZ) entsteht. Es hat mit der Häufigkeitsverteilung von Buchstaben in der englischen Sprache zu tun. Dabei kann für die beiden ersten Buchstaben QW auch AZ stehen. Schon lange weiß man, dass diese Belegung aus ergonomischer Sicht alles andere als optimal ist. Es gibt daher eine Menge Vorschläge, die Tastaturbelegung zu ändern. Durchgesetzt hat sich noch keiner. Was Millionen sich angewöhnt haben, ist sehr schwer zu verdrängen.

Nat Rochester hatte als Fellow ein Projekt namens Chord Keyboard (deutsch: Akkord-Tastatur), das die Problematik des Tippens neu anging. Es gab zwölf Tasten für die vier Finger, an den Seiten und Ecken gewölbt, so dass ein Finger zwei Tasten gleichzeitig drücken konnte, oder vier Tasten, wenn sie übereck lagen. Es gab drei Daumentasten, auch mit der Möglichkeit, zwei auf einmal anzuschlagen. Experimente zeigten, dass es mit der Tastatur leicht möglich war, alle Grundfunktionen des Tippens auszuführen. Sie hatte große Vorteile für diejenigen, die bereit waren, eine große Anzahl von Silben (oder Akkorden) für allgemeine Wörter und Sätze zu lernen. Ähnliche Konzepte werden heute weltweit von Stenografen bereits benutzt. Leider fehlte dem Ansatz die Akzeptanz in der Praxis und wurde daher nicht in ein Produkt überführt.

Geburtshelfer der ‚Künstlichen Intelligenz‘

Wie das Software Engineering so führt auch das Forschungsgebiet Künstliche Intelligenz seine Entstehung auf eine Tagung zurück. Im Sommer 1956 gewannen John McCarthy und Marvin Minsky Nat Rochester und andere Industrievertreter dazu, eine Konferenz am Dartmouth College zu sponsern, bei der McCarthy den Begriff der Künstlichen Intelligenz (engl. artificial intelligence) populär machte. Rochester startete anschließend mehrere Projekte innerhalb von IBM, die sich mit automatischem Beweisen und Computerspielen befassten. Dazu gehörten Arthur Samuel's Dame-Programm, Herbert Gelernter's Theorem-Beweiser und Alex Bernstein's Schach-Programm. Um 1958, als Gastprofessor am MIT half er John McCarthy bei der Entwicklung der Programmiersprache Lisp.

Auf Druck von Kunden und Aktionären entschloss sich IBM um 1960, alle Aktivitäten auf dem KI-Gebiet einzustellen. Durch die übertriebenen Aussagen der KI-Protagonisten auf der ganzen Welt gerieten Computer als solche ins Zwielicht. IBM legte fortan Wert darauf zu sagen, dass Computer für sehr nützliche Aufgaben verwendbar sind, und nicht zum Spielen da sind. Außerdem tun sie nur genau das, was man ihnen sagt und entwickeln keine eigenen Ideen. Erst eine ganze Generation später wagten IBMer es wieder, das Wort KI in den Mund zu nehmen. Seit Deep Blue, ein von IBM gebauter und programmierter Rechner, einen Schachweltmeister schlug, hat sich die Einstellung geändert. Auch das Projekt Watson, mit dem IBM in jüngster Zeit wieder viel Aufmerksamkeit in der Presse bekam. gibt offen zu, dass dabei KI-Methoden im Spiel sind.

Ein Schlussgedanke

Vielleicht wundert es, dass ein Hardware-Mann wie Nat Rochester später sein Interesse so sehr auf Software verschob. Im Oral History Interview der IEEE über seine Anfangsjahre bei IBM begründet er sein Interesse für Software wie folgt:

We were concerned with software right from the beginning, because we realized that in some sense software was more reliable than hardware. That is, once you got it de-bugged it would stay de-bugged, whereas the hardware would wear out and deteriorate.

Gut, auch einmal daran erinnert zu werden! Natürlich gibt es auch Software-Fehler. Nur haben sie ganz andere Ursachen als Hardware-Fehler. Es sind fast nur Entwicklungsfehler, genauer gesagt Entwurfsfehler. Es ist dies eine sehr ernüchternde Einsicht. Es kostet einige Überlegungen, um darauf vernünftig zu reagieren.

Referenz:

1. IBM Journal of Research and Development: 25th Anniversary Issue, 1981. Seite 842