Die Programmierung

Begriff des Programmierens

Die Programmierung ist ein sehr weit gefasster Oberbegriff. Viele assoziieren diesen Begriff zu Recht mit einem Computer und glauben: "Der kennt sich mit einem Computer bestimmt gut aus."

Das mag in gewissem Rahmen auch stimmen, doch das liegt nicht allein an der Arbeit des Programmierens. Der Computer ist mein tägliches Handwerkszeug, und deshalb sollte ich mich relativ gut damit auskennen. Ich muss wissen, wie ein Computer arbeitet und funktioniert, um vernünftig damit umgehen zu können.

Die vielen möglichen assoziativen Bilder, die mit einem Programmierer verbunden sind, lassen sich noch erweitern, wenn ich Bezug nehme auf Programmierungen, die nichts oder kaum etwas mit einem Computer zu tun haben. Viele von Ihnen mögen schon den Begriff des Neurolinguistischen Programmierens (kurz NLP) gehört haben. Ich möchte hier nicht weiter auf den Begriff eingehen, sondern nur zeigen, wie vielfältig das Programmieren sein kann. Vorgänge im Gehirn eines Menschen sollen mithilfe des NLP auf Basis systematischer Handlungsanweisungen veränderbar sein.

Die Analogie zu meiner Programmierarbeit liegt darin, dass Vorgänge in einem Computer mithilfe der Programmierung auf Basis systematischer Handlungsanweisungen veränderbar sind. Das ist natürlich sehr abstrakt und grob formuliert.

Ein Computer kann ohne jegliche Programmierung nur elektrischen Strom verbrauchen und infolgedessen aus physikalischen Gründen etwas Wärme abgeben. Zu mehr ist er ohne Programmierung nicht imstande. Jede noch so kleine Annehmlichkeit eines Computers, wie zum Beispiel das Starten eines Betriebssystems, gleich welcher Art, ist mit vorheriger, mehr oder weniger aufwändiger Programmierung verbunden. Das Betriebssystem ist im weitesten Sinne mit einem Programm vergleichbar, an dem viele Programmierer gearbeitet haben. Diese Programmierer legten mit ihrer Arbeit fest, wie der Computer arbeiten soll und welche Komponenten dazu benötigt oder geladen werden sollen. Auch sogenannte Treiber, wie etwa ein Druckertreiber, wurden wiederum von anderen Programmierern erarbeitet.

Nehmen wir als Beispiel den einfachen Taschenrechner, der mit dem Betriebssystem Microsoft Windows ausgeliefert wird. Wird dieser Taschenrechner gestartet, erscheint er auf dem Bildschirm als ein relativ einfaches Programm. Doch auch dieses Programm musste zunächst von einem oder mehreren Programmierern erarbeitet werden. Die Programmierer mussten zunächst festlegen, wie das Programmfenster aussehen soll. Sie bestimmten, wie das Ergebnis-Ausgabefeld aussieht, wo die Eingabefelder angeordnet sind und dass der Anwender möglicherweise seine Tastatur oder auch die Maus zur Eingabe bzw. Bedienung verwenden kann. Es musste ebenso genau in den Programmzeilen festgelegt werden, was passieren soll, wenn beispielsweise 5 × 5 = eingetippt wird.

Dass danach die Zahl 25 im Ausgabefeld als richtiges Ergebnis erscheint, ist keineswegs selbstverständlich; das passiert nicht einfach so. Man musste dem Taschenrechner in der Entwicklung mitteilen, was er bei solchen Eingaben tun soll, nämlich rechnen und danach eine Ausgabe auf dem Bildschirm präsentieren. Solche Aufgaben wie etwa 5 × 5 sind noch relativ einfach, doch wie sehen die Programmzeilen aus, wenn der Anwender verschachtelte Klammerrechnungen, Wurzelberechnungen oder Sinusfunktionen anwenden möchte?

Diskrepanz zwischen Anerkennung und Programmierarbeit

Manchmal entstehen im Rahmen von Programmentwicklungen gewisse Diskrepanzen zwischen Anerkennung und der Programmierarbeit. Während sich Anwenderinnen und Anwender komfortable und einfach zu bedienende Programme wünschen, programmiert der Entwickler aufwändige Programmzeilen, um dies zu realisieren. Die Anwender finden schließlich ein einfach zu bedienendes und vor allem zuverlässiges Programm vor, können jedoch kaum erahnen, welcher Entwicklungsaufwand sich hinter solch einem Programm verbirgt.

Beispiel: Eines von vielen Projekten, welches ich in der Vergangenheit entwickelte, war ein sogenannter Submitter. Dieser hatte die Aufgabe, zahlreiche URLs und Domain-Informationen eines größeren Unternehmens aufzunehmen und weltweit an möglichst viele Suchmaschinen im Internet zu übermitteln. Nach Fertigstellung des Projekts fand man ein relativ übersichtliches und einfach zu bedienendes Programm vor. Nach dem Beladen der notwendigen Informationen, wie etwa URLs- bzw. Domain-Angaben, brauchten die Anwender nur noch auf einen Startknopf zu klicken. Alle weiteren Arbeiten übernahm das Programm vollautomatisch.

Die Anwender sahen nur wenige Objekte – wie etwa Kontrollfelder oder den Beenden-Button auf der Programmoberfläche. Sie konnten jedoch nicht ahnen, dass sich hinter dem Programm mehr als 15 000 notwendige und teils komplexe Programmzeilen in verschiedenen Modulen verbargen.

Die Entwicklungszeit

Man mag vermuten, wenn man sich noch nie an eine Programmierung herangewagt hat, dass die meiste Entwicklungszeit in die Realisierung der einzelnen, direkten Programmaufgaben investiert wird. Doch jeder Programmentwickler wird bald merken, sofern er Wert auf fehlerfreie und zuverlässige Programme legt und vor allem durchdachte Strukturen einfließen lassen möchte, dass er für die unmittelbare Umsetzung der Programmaufgaben meist nur ein Drittel der Gesamtzeit benötigt. Die restliche Zeit wird für zusätzliche Verbesserungen, Tests und Fehlervermeidung aufgewendet.

Beispiel: Nehmen wir wieder den oben erwähnten Taschenrechner. Die Zeitplanung für ein solches Programm mag vielleicht relativ einfach erscheinen, solange der Entwickler, was vorausgesetzt wird, einigermaßen in die Mathematik involviert ist. Doch was ist bei Fehleingaben des Anwenders? Wir wissen: Eine Division durch Null ist nicht erlaubt. Der Programmentwickler muss dennoch einplanen, dass der Anwender es darauf anlegen könnte, eine Division durch Null durchführen zu wollen. Oder was passiert, wenn der Anwender statt Zahlen und mathematischer Symbole plötzlich fließenden Text eingibt?

Ein weiteres Beispiel wäre mein bereits erwähnter Submitter. Daten an eine Suchmaschine zu senden, ist relativ einfach. Doch Fehler können auch unvorhergesehen auftreten. Der Anwender könnte vergessen haben, vor Arbeitsbeginn eine Verbindung mit dem Internet herzustellen. Eine mögliche Fehlerbeseitigung wäre, dass das Programm dies vor Beginn überprüft und ggf. selbst eine Verbindung herstellt. Doch auch hier können wiederum Fehler entstehen, etwa wenn der Anwender falsche Zugangsdaten eingegeben hat. Oder der Rechner ist online, aber die Suchmaschine vorübergehend nicht erreichbar. Vielleicht besteht während der Arbeit eine plötzliche Internetstörung. Wie dem auch sei: Die Liste der möglichen Fehlerquellen ist sehr lang. Diese müssen bei einem zuverlässigen Programm stets in die Entwicklung eingeplant werden.

Die Entstehung eines Programms

Doch wie entsteht eigentlich ein für den Computer ausführbares Programm? Ein Computer kann unsere menschliche Sprache nicht verstehen. Würden wir auf einem Rechner eine Datei rechner.exe abspeichern und darin schreiben: "Schreibe auf dem Bildschirm das Ergebnis von 5 * 5", so könnten wir beim Ausführen dieser Datei keinen Erfolg haben, weil der Prozessor diese Anweisung nicht versteht und somit nicht verarbeiten kann.

Ich möchte übrigens dringend davon abraten, dieses Experiment auszuprobieren, da dies insbesondere bei älteren Betriebssystemen, wie etwa MS-DOS, zu einem fatalen Systemabsturz führen könnte.

  Program Rechnen;
    uses crt, dos;
    var Zahl: Integer;
  BEGIN
    Zahl := 5*5;
    Write(Zahl);
  END.
  

Das waren noch Zeiten, als solch ein Code geschrieben wurde. Ich persönlich habe noch Turbo Pascal für MS-Dos Version 3.14 kennengelernt.

Ich möchte an dieser Stelle die einzelnen Programmzeilen nicht im Detail erläutern. Es soll lediglich veranschaulicht werden, wie eine vorgeschriebene Syntax, also eine "menschennahe Sprache", für dieses kleine Ausgabebeispiel aussehen kann. Um diese vergleichsweise einfachen Anweisungen auf dem Computer auszuführen, wird ein sogenannter Compiler benötigt, der die "menschennahe Sprache" in eine maschinenlesbare Form, ein sogenanntes Compilat, übersetzt.

Es gibt zahlreiche weitere Programmiersprachen, von denen ich einige auf den folgenden Seiten noch näher beschreiben werde.