Programmiersprachen der vierten Generation, was immer man darunter versteht, sind derzeit die Verkaufsschlager auf den Hitlisten der Branche. Fragt man drei Experten, was darunter zu verstehen ist, so erhält man normalerweise drei verschiedene Antworten. Bei dem Versuch, diese Frage zu klären, ist der Blick in die Vergangenheit oft der wichtigste Schlüssel zum Verständnis der Gegenwart.
Die erste Generation der Programmiersprachen war die reine Maschinensprache oder der Native Mode. Im Native Mode wurden für die Operationen bestimmte Code-Zeichen verwendet, die keine spezielle Beziehung zu der auszuführenden Operation hatten und meist einer Tabelle entstammten. Adressen von Datenfeldern wurden durch den Programmierer direkt festgelegt. Über die Bedeutung der Adressen mußte der Programmierer nebenher eine separate Tabelle führen.
Diese erste Generation der Programmiersprachen wurde sehr bald durch die zweite, nämlich die der Assemblersprachen, abgelöst. Assemblersprachen verwendeten symbolische Operations-Schlüssel, und vor allem symbolische Feldnamen, die dem Programmierer einen großen Teil seiner Codier-Arbeit abnahmen. Die Zuordnung der Adressen zu den symbolischen Feldnamen erfolgte über einen Compiler. Ein Assemblerprogramm war sowohl für den Programmierer als auch für den Außenstehenden wesentlich besser lesbar und brachte damit eine wesentliche Steigerung der Produktivität. Wäre damals der Begriff "Endbenutzer" schon bekannt gewesen, so hätte man den Assembler sicher eine Endbenutzer-Sprache genannt - und das durchaus nicht zu Unrecht, eröffnete er doch einem mit Sicherheit erweiterten Benutzerkreis erstmals den Zugang zu einem Computer.
Kreis der direkten User weitet sich aus
In nur geringem zeitlichen Abstand folgte dieser zweiten Generation die dritte, nämlich die der sogenannten "High-Level-Sprachen". Das waren Sprachen, die die vielen Operationen der maschinennahen Assemblersprachen zu anwendungsorientierten Makro-Befehlen zusammenfaßten.
Ein Beispiel hierfür aus dem kommerziellen Bereich ist Cobol. Die Syntax dieser Sprachen ist völlig losgelöst von den einzelnen Instruktionen der Maschine und erlaubt dem Programmierer vielfach eine klartextähnliche Formulierung seiner Aufgabenstellung und die Verwendung von Rechenformeln in fast arithmetischer Schreibweise.
Cobol galt folglich als Endbenutzersprache schlechthin und wurde nur deswegen eine anwenderorientierte Sprache genannt, weil der "Endbenutzer" zu diesem Zeitpunkt immer noch nicht erfunden war. Es ist jedoch unbestreitbar, daß auch Cobol den Kreis der direkten Benutzer des Computers erweiterte.
Der Wechsel von der ersten zur dritten Generation vollzog sich dabei in weniger als einem Jahrzehnt, zu Beginn der sechziger Jahre. Bei dem Versuch, sich einmal in diese Zeit zurückzuversetzen, läßt sich feststellen, daß externe Speichereinheiten zu diese Zeit noch eine sehr untergeordnete Rolle spielten. Die Sprache befaßte sich also von ihrer Entwicklung her im wesentlichen mit dem Ablauf des Programms im Hauptspeicher. Die Ein- und Ausgabe war Sache der Betriebssysteme und wurde somit von den Entwicklern der Programmiersprachen fast völlig ignoriert.
Aus heutiger Sicht hätte der dritten Generation unmittelbar eine vierte folgen müssen, die die externen Speicher in die High-Level-Sprachen integrierte. Dieser Schritt hätte für die externen Speicher das nachvonziehen müssen, was der Assembler für den Hauptspeicher gebracht hatte - nämlich die Loslösung der Datenfelder von ihren festen Speicheradressen.
Man kann sich vorstellen, daß Datenverarbeitung heute sehr viel einfacher wäre, wenn diese wirkliche vierte Generation zur rechten Zeit zur Verfügung gestanden hätte. Zur rechten Zeit, das heißt zu dem Zeitpunkt, als die Unternehmen, die heute über Anwendungsstau klagen, begannen, ihre Anwendungen zu entwickeln. Die fehlende Einbindung der Datenbestände in die Programmiersprachen überforderte die Programmierer in mehrfacher Hinsicht.
Sinnvolle Wartung erwies sich als fast unmöglich
Zunächst waren sie gezwungen, bei der Festlegung der Datenbestände die zukünftige Entwicklung des Unternehmens weitgehend vorherzusehen. Dies resultierte meist in einer Überdimensionierung der erforderlichen Datenstrukturen. Unvorhersehbare organisatorische Änderungen führten wegen des starren Konzepts sehr leicht zur Improvisation. Änderungen, die eine solche Vorgehensweise nicht zuließen, erforderten normalerweise eine völlige Neukonzeption der Anwendung. Eine sinnvolle Wartung erwies sich damit als fast unmöglich.
Dieses Problem wurde denn auch sehr bald von den Software-Entwicklern erkannt und führte zur Entwicklung eines völlig neuen Sprachtyps, der Datenbanksprache. Die Datenbanksprache verstand sich dabei als Ergänzung der etablierten Programmiersprachen und befaßte sich folglich nur mit dem Zugriff zu den Datenbeständen. Sie war frei von prozeduralen Elementen. Die Kommunikation mit der Programmiersprache erfolgte im Handshake-Verfahren.
Die Datenbanksprache befreite zwar den Programmierer von der festen Adressierung externer Datenfelder, kompensierte aber diesen Vorteil wieder durch den Nachteil einer starren Übergabe-Schnittstelle. Die Akzeptanz dieses Sprachtyps war dann auch folglich nicht sehr groß, weil durch die erforderliche Neukonzeption der Datenbank der Anwendungsstau eher verstärkt wurde. Eine weitere Ursache der mangelnden Akzeptanz war sicher auch die Trägheit der Programmierer, die jetzt: neben der gewohnten Programmiersprache eine weitere Sprache völlig neuen Ursprungs erlernen sollten.
Mangelnde Akzeptanz aber fordert immer die Reaktion der Entwickler heraus. Diese gingen jetzt dazu über ihre Sprache um einfache prozedurale Elemente zu erweitern, die dem Benutzer unter Umgehung der Programmiersprache einfache Abfragen der Datenbestände erlaubten. Die Datenbanksprache wurde zur Query-Language erweitert.
Query-Sprachen wurden bedingungslos akzeptiert
Query-Sprachen wendeten sich gezielt an den Endbenutzer und wurden von dort auch bedingungslos akzeptiert, weil sie volle Unabhängigkeit von der konventionellen DV suggerierten. Diese euphorische Akzeptanz ermutigte die Entwickler, die einfachen Abfrage-Befehle zu einer neuen Art von Programmiersprache zu erweitern. Man faßt diese Sprachen heute unter dem Begriff "Sprachen der vierten Generation" zusammen, obwohl sie zu den ersten drei Generationen in keinerlei Beziehung stehen und in Wirklichkeit die zweite Generation der Datenbanksprachen sind.
Ihr Ursprung ist vielfältig und basiert fast immer auf dem Datenbanksystem ihres Entwicklers. Eine Verbindung zu konventionellen Sprachen ist meist nicht möglich.
Query-Sprachen sind einfach zu handhaben, auch von qualifizierten Endbenutzern. Die gewachsene DV-Organisation erfährt dadurch zunächst eine sinnvolle Ergänzung. Die einfache Handhabung verführt jedoch dazu, nach und nach auch Aufgaben zu lösen, die die konventionelle DV bereits teilweise oder sogar voll abdeckte oder aus Performance-Überlegungen vorerst zurückstellte.
Der Begriff "Performance" ist dem Endbenutzer völlig fremd. Für ihn zählt das Ergebnis seines Programms, und er fühlt sich völlig unschuldig, wenn andere plötzlich über schlechte Antwortzeiten klagen. Unbelastet durch die Kenntnis der Zusammenhänge verkündet er nicht ohne Stolz, daß das von ihm selbst geschriebene Programm bestens läuft, und daß dies nur bestätigt, daß die DV mit alten Werkzeugen arbeitet. Die Prügel bezieht dann der DV-Leiter, spätestens wenn er das nächstgrößere System beantragt. Das größere System aber ist vorprogrammiert, wenn man glaubt, daß Endbenutzer ohne DV-Verstand jetzt in kürzester Zeit all das nachholen, was Fachleute in den letzten Jahren nicht geschafft haben.
Die erwartete Überwindung des Anwendungsstaus, die der eigentliche Anstoß war, verkehrt sich ins Gegenteil, da die Fachleute in der DV-Abteilung jetzt gänzlich in die Defensive gedrängt werden. Es ist unter anderem erforderlich:
- vorhandene Anwendungen an schneller wachsende Systeme anzupassen;
- die Auswirkungen zeitkritischer Laien-Anwendungen zu neutralisieren;
- unter Umständen neue Endbenutzer-Datenbanken zu installieren, die euphorische Laien vom Tagesgeschäft fernhalten,
- erweiterte Schutzmaßnahmen zu treffen, um Update-Zugriffe von jedermann zu unterbinden.
Sprachen der vierten Generation sind, sofern sie diesen Titel zu Recht führen, arbeitsteilige Sprachen mit unterschiedlichen Werkzeugen für den System-Ingenieur, den betriebswirtschaftlich orientierten Anwendungsprogrammierer und den Endbenutzer. Sie sind konsequente Weiterentwicklungen der dritten Generation, die im zentralen Teil dem Anwendungsprogrammierer "seine" Programmiersprache voll zur Verfügung stellen. Die Arbeit des Anwendungsprogrammierers wird dabei auf den betriebswirtschaftlichen Ablauf konzentriert. Die Steuerung peripherer Einheiten und die Kenntnis ihrer Steuer- und Verwaltungssysteme gehört in den Bereich des System-Ingenieurs. Allein das Layout der Information auf dem Bildschirm ist Sache des Anwenders, der ein Werkzeug braucht, um die Information exakt seinem Bedarf anzupassen, ohne daß er dazu erst das Programmieren erlernen muß.
Produkte, die dem Endbenutzer vorgaukeln, daß er jetzt die Datenverarbeitung alleine macht, gehören in den Bereich des Showbusineß, wo mit Masken und Kosmetik Illusionen erzeugt werden. Bei diesem Geschäft zahlt man üblicherweise die Eintrittskarte vor Beginn der Vorstellung, und Jeder weiß: Kein Geschäft ist besser als dieses, zumindest aus der Sicht des Schaustellers.
Programmierer vom Codier-Ballast befreien
Dies alles könnte Zil der Feststellung verleiten, daß man doch besser bei der bewährten Methode der High-Level-Sprachen bleibt und erst mal abwartet, wie sich die Umwelt weiterentwickelt. Aber gerade das wäre grundfalsch.
Programmiersprachen der dritten Generation gehören längst zum alten Eisen und sollten zu den Akten gelegt werden, denn sie belasten wertvolle Programmierer mit überflüssigem Codier-Ballast. Es gibt seit Jahren produktivere Anwendungsentwicklungswerkzeuge, die den Codier- und Wartungsaufwand erheblich reduzieren. Niemand, der in der Branche ernst genommen werden will, würde heute vorschlagen, auf Hardware-Einrichtungen der 60er Jahre zurückzugreifen. Bei den Software-Werkzeugen jedoch findet man dabei kaum etwas Böses - oder hat man vergessen, daß Cobol für Lochkartenmaschinen mit Ferritkernspeichern entwickelt wurde?
Bevor jemand über Anwendungsstau klagt, sollte er seine Werkzeugkiste überprüfen und auf den Stand der Technik bringen. Hierbei ist allerdings höchste Vorsicht geboten. Die Entscheidung sollte keinesfalls aufgrund eines Labels getroffen werden, denn viele Produkte tragen dieses Label zu Unrecht. Seriöse Anbieter räumen dem Anwender sicher eine angemessene Probezeit ein.