Wenn man sich die Entwicklung der Programmiersprache C seit den frühen Siebzigern bis heute anschaut, kann man ermessen, wie sehr sich das Programmieren selbst verändert hat. Bis weit in die Neunziger haben viele Auguren der IT-Szene noch damit gerechnet, dass Kodieren irgendwann eine Kulturtechnik würde wie das Lesen und Schreiben. Weit gefehlt! Heutzutage wird Software überwiegend industriell gefertigt. Da sitzen keine mehr oder weniger geniale Nerds mit geröteten Augen und Pizzaresten an der Kleidung nächtelang vor Monitoren, um eigene oder ihnen zugetragene Ideen in Applikationen zu verwandeln. Programmieren ist spätestens seit der schnellen und umfassenden Verbreitung von C++ ein arbeitsteiliger Prozess – das Arbeiten mit Skriptsprachen wie PHP und JavaScript einmal ausgenommen. Die entscheidenden Begriffe der Veränderung heißen „Bibliotheken“ (Libraries) und „Entwicklungsumgebung“ (IDE).

1973: C macht Unix möglich

Nachdem in den Sechzigern die Botschaft bei der Mehrheit der Manager angekommen war, dass beinahe jedes Unternehmen unmittelbar durch den Einsatz von Computertechnik profitieren würde, begann ein dramatischer Run auf Rechenpower. Und die mussten die allermeisten Firmen mieten, denn einen eigenen Großrechner anzuschaffen, lag kostentechnisch meist weit außerhalb aller Möglichkeiten. Die IT in den USA tendierte in Richtung Monopole, weil es Mitte der Sechzigerjahre kaum eine Handvoll solcher Mainframe-Computer gab, bei denen man sich einmieten konnte. Das war aber nicht für Business-Organisationen schlecht, sondern auch für die Universitäten. Es ist das Verdienst von Digital Equipment Corporation (DEC) diesem Trend mit der Entwicklung der ersten bezahlbaren Minicomputern etwas entgegengesetzt zu haben. Wobei die Silbe „mini“ täuscht; die Systeme der Baureihe PDP waren nur im Verhältnis zu den Großrechnern klein: Wo die ganze Säle oder Etage füllten, da passte ein PDP-Rechner mit seinen Komponenten in ein paar Schränke in einem Raum.

Gleichzeitig mit der Entwicklung dieser 12-Bit- bzw. später 16-Bit-Technologie kam der Gedanke auf, hardwareunabhängige Betriebssysteme zu formulieren, mit denen diese aufkommenden Minicomputer gesteuert werden sollten. Diese sollten außerdem die Softwareentwicklung vereinfachen; in jener Ära überstiegen die Kosten für Programme nicht selten die für die Hardware, auf der sie liefen. Darunter litt auch der Telefon-Dino Bell (später AT&T) und setzte in seinem Softwarelabor ein Team auf die Entwicklung eines solchen Betriebssystems an. Ken Thompson und Dennis Ritchie schufen so innerhalb von kaum drei Jahren das allererste Unix. Weil die erste Version noch in Assembler geschrieben war, überstieg der Aufwand für Dokumentation und Pflege rasch den für das eigentliche Kodieren. Also „erfanden“ die beiden mal eben eine passende Programmiersprache. Weil die auf einer Sprache namens B beruhte, nannte sie ihr Werk einfach C. Zumal die beiden auch schon dieses B entwickelt hatten, um eine für die kleinen Computer passende Version von BCPL zu haben.

Die Bedeutung von Unix und C auf die IT bis heute kann gar nicht hoch genug eingeschätzt werden. Das hierarchische Dateisystem, das uns heute überall geläufig ist, wurde mit Unix erstmals in die Praxis umgesetzt, und mit der von Thompson und Ritchie formulierten „Unix-Philosophie“ entstanden die Konzepte der Software-Entwicklung, die bis heute maßgeblich sind. Man kann sagen: Wir alle leben in einer Unix-Welt – und ohne C wäre Unix nicht möglich gewesen.

1975: Das Zeitalter der Libraries beginnt

Wie schon öfter erwähnt, unterschieden wird zwischen Interpretern und Compilern. Während ein Interpreter den Quellcode eines Programms einliest, analysiert und ausführt, übersetzt ein Compiler den gesamten Quellcode in ein vom Computer ausführbares Programm. Nun gibt es (wie jeder, der früher viel mit BASIC gearbeitet hat) Aufgaben, die immer wieder auf dieselbe Art auftreten und auszuführen sind. Hat man einmal funktionierende Code-Sequenzen geschrieben, verwendet man diese natürlich wieder und wieder. Das betrifft sowohl Interpreter, als auch Compiler. Aber: Die Compiler eine Programmsprache kann man von Hause aus gleich mit mehr oder weniger umfangreichen Sammlungen solcher Sequenzen bestücken, vor allem um solche, die sich um die verschiedenen Ein- und Ausgabe-Prozesse sowie das Lesen und Schreiben von Dateien drehen. Das Konzept gab es bereits, aber es waren wieder Thompson und Ritchie, die festschrieben, dass zu jedem C-Compiler eine passende Standardbibliothek mitzuliefern ist.

Mit der Weiterentwicklung von Unix und der Spaltung dieser Betriebssystem-Urmutter in einen kommerziellen und einen Open-Source-Zweig wurde das Prinzip der Libraries allumfassend. In den Linux-Systemen sind beispielsweise alle Anwendungen abhängig von Bibliotheken, die Teil des Betriebssystems sind. Und alle modernen Programmiersprachen verfügen über jede Menge solcher Standardbibliotheken – vorgemacht hat es C und in verstärktem Maße seine Nachfahren. Vor allem das von Bjarne Stroustrup bei AT&T (vormals Bell Laboratories) entwickelte und 1983 veröffentlichte C++.

1998: Die Standardisierung der Programmiersprache C++

Es ist ein Meilenstein in der Geschichte der Programmiersprachen: 1998 wurde nach jahrelanger Arbeit, an der Tausende von ITlern beteiligt waren, C++ nach den Regeln der International Organisation of Standardization (Internationale Organisation für Normung, kurz ISO) genormt. Das bedeutet salopp ausgedrückt: Wo C++ draufsteht, ist auch C++ drin. Jeder C++-Code nutzt dieselben syntaktischen Elemente, dieselben Schlüsselwörter und dieselben Standardbibliotheken. Damit wurde die arbeitsteilige, quasi industrielle Entwicklung von Software erst möglich.

Dies in Verbindung mit der fast allumfassenden Verbreitung von Unix-Derivaten als Betriebssystem veränderte die IT-Industrie grundlegend, weil sich Entwickler um viele Details funktionierender Anwendungen überhaupt nicht mehr kümmern müssen. Das verkürzt den Prozess des Testens, Pflegens und Dokumentieren so sehr, dass die Kosten für die Anwendungsentwicklung dramatisch gesunken sind. Gleichzeitig haben sich die Paradigmen des Programmierens aber auch enorm verändert: Die Ära der Entwicklungsumgebungen konnte beginnen.

1991: Visual Basic bringt die integrierte Entwicklungsumgebung

Nein, Microsofts Visual Basic war nicht die erste Programmiersprache mit integrierter Entwicklungsumgebung, aber die erste, mit der die Brücke vom klassischen Kodieren zur computergestützten Softwareentwicklung (CASE) geschlagen wurde. Tatsächlich handelt es sich um einen BASIC-Dialekt, der etliche Nachteile der BASIC-Versionen, die Hobbyprogrammierer auf ihren Homecomputern genutzt hatten, ausmerzt. Gleichzeitig bietet das System eine Fülle an Werkzeugen, mit denen die Anwendungsentwicklung drastisch beschleunigt werden konnte. Die diversen Tools nehmen dem Kodierer eine Menge an wiederkehrenden Aufgaben ab und helfen beim Testen, Kompilieren, Pflegen, Warten und Dokumentieren. Dies vor allem dank einer grafischen Benutzeroberfläche und integrierten Werkzeugen zum Entwickeln grafischer Benutzeroberflächen.

Heute unterscheidet man zwischen einem Software Development Kit (SDK) und einer integrierten Entwicklungsumgebung (IDE), wobei das SDK die Basis für eine Entwicklungsumgebung bildet, also alle grundlegenden Bibliotheken und Werkzeuge umfasst, nicht aber die Anwendung, mit der dann tatsächlich Anwendungen entwickelt werden. In der Praxis beinhalten einige SDKs für Betriebssysteme (z.B. für Android) keine IDE, während bei anderen die Entwicklungsumgebung Teil des Kits ist.

2017: Microsofts Q# öffnet den Weg zum Quantencomputer

Ja, es gibt schon Quantencomputer. Und, ja, die Prinzipien der Quantencomputerei sind für Laien und selbst wissenschaftlich interessierte Menschen kaum zu verstehen. Was daran liegt, dass sich die Quantenmechanik von allen physikalischen Prinzipien, die wir so aus dem Alltag kennen, deutlich unterscheidet. Wo die klassische Physik sich um
Materie und Energie und deren Wechselwirkungen in Raum und Zeit kümmert, beschreibt die Quantenphysik Phänomene auf atomarer bzw. subatomarer Ebene. Wo ein klassischer Computer Nullen und Einsen als binäre, elektrische Zustände versteht, wertet ein Quantencomputer eben quantenmechanische Zustände – z.B. den Spin eines Elektrons – aus. Diese Zustände werden aber nicht einfach als Werte interpretiert, sondern als Vektoren, die nicht zwangsweise sich widersprechend sein müssen, sondern sich einfach nur unterscheiden. Und weil sie sich überlagern können, lassen sich quantenmechanisch nicht nur An-Aus-Zustände beschreiben, sondern auch das, was dazwischen liegt.

In der Theorie funktioniert das schon seit Jahrzehnten, in der Praxis stießen die Physiker aber auf eine Fülle Probleme, die aktuell nur mit gigantischem technischen Aufwand lösbar sind. Also handelt es sich bei den existierenden Quantencomputer bestenfalls um Experimentalsysteme. Damit die aber überhaupt als Computer funktionieren können, brauchen sie Betriebssysteme und passende Programmiersprachen. Im September 2017 hat Microsoft also das Konzept der Programmiersprache Q# (sprich: Q sharp) vorgestellt und gleichzeitig ein Quantum Development Kit angekündigt. Beides zielt nicht nur auf das pure Programmieren von zukünftigen Quantencomputer, sondern vor allem auf die Entwicklung von Quanten-Algorithmen, also von Befehlsfolgen, mit denen Probleme unter den besonderen Bedingungen der Quantencomputerei gelöst werden können. Insofern darf man Q# als Bindeglied zwischen dem, was wir heute unter Programmierung verstehen und der zukünftigen Welt der Quantencomputer darstellen.