Mit Peter Dietz, Dietz Computersysteme (Mülheim), sprach Dieter Eckbauer

- Herr Dietz, es geht ein Ruf wie Donnerhall durch die DV-Welt: Nehmt doch Pascal! Auch Sie bieten jetzt einen Pascal-Compiler an. War denn alles Mist, was bisher gemacht wurde ?

Bei Systemen mit einem gewissen Komplexitätsgrad, vor allem solchen, die in einer Echtzeitumgebung arbeiten, ist die Realität doch die, daß diese Systeme heute noch zu 80 Prozent in dem jeweiligen Assembler programmiert werden - mit all den Folgen, die das hat: Lesbarkeit schlecht, Dokumentation schlecht.

- Nun redet doch - zumindest in der Prospekt- Wirklichkeit - seit Jahren kein Mensch mehr von Assembler.

Das ist richtig. Aber gehen Sie mal zu Software- und Systemhäusern, oder zu Großunternehmen, die solche Systeme selbst integrieren. Fragen Sie mal, was die machen. Natürlich gibt´s sehr oft ein Beiwerk in Fortran oder Cobol. Aber die essentiellen Dinge werden in Assembler programmiert ...

- ... mit all den Folgen, die das hat - wie Sie sagen. Können Sie das präzisieren, in bezug auf die Nachteile?

Der Kardinalnachteil ist natürlich der, daß Assembler nicht portabel ist. Das kann im Interesse der Hersteller liegen, aber sicherlich nicht in dem des Benutzers. Assembler sind Abbild der Rechnerarchitektur. Viel gravierender ist, daß Assembler die falsche Ebene ist. Sie ist viel zu tief, viel zu detailliert, schlecht strukturiert, läßt dem Benutzer unendlich viele Freiheitsgrade - auch des Mißbrauchs -, und trägt viel zu sehr die persönliche Handschrift des Programmierers, mit dessen Tricks und Finessen, durch die dann kein Mensch mehr durchsteigt.

- Darf man sich eigentlich wundern, daß wir einen Programmiersprachenstreit haben, wenn die großen Hersteller unterschiedliche Sprachen forcieren ?

Das ist auf bestimmten Märkten richtig, Auf dem Teilmarkt aber, von dem ich hier rede - also dem der komplexen DV-Lösungen, die sich nicht einfach unter dem Rubrum "technisch-wissenschaftlich" oder "kommerziell" subsummieren lassen, sondern die intelligent sind, die hohe Ansprüche stellen, die Realtime-Umgebung haben - auf diesem Teilmarkt gibt es eigentlich nichts, was sich bisher etabliert hat.

- Welchen Ansprüchen müßte denn eine Programmiersprache für Prozeßrechner, Kommunikations- und Informationssysteme genügen?

Es sollte erstens eine Sprache auf einem vernünftig hohen Level sein, die international einigermaßen anerkannt ist. Sie müßte zweitens eine effiziente Implementierung ermöglichen. Der dritte Punkt ist, daß man damit Zugriff auf alle Ressourcen des Systems besitzt, ob es sich nun um Datenbanken, Prozeßperipherie, Kommunikationsprotokolle oder Screen-Management handelt.

- Um auf den Methodenstreit in Sachen Programmierung zurückzukommen: Ist dies nach Ihrer Ansicht ein Punkt, der die Benutzer interessiert?

Ob die Hardwarepreise runter - oder raufgehen - wie man gelegentlich wieder liest -, diese Frage wird in absehbarer Zeit an Bedeutung verlieren. Die ganzen Aspekte der Sicherheit und Wartbarkeit eines Systems werden dagegen eine immer größere Rolle spielen. Dafür muß man erst mal vernünftige Werkzeuge haben. Und im Bereich Echtzeitsysteme gibt es eben nur beschränkt vernünftige Instrumente, vor allem auch solche, die international anerkannt sind.

- Wir möchten auf unsere erste Frage zurückkommen: Wenn sich in diesem Bereich noch nichts etabliert hat, warum setzt Dietz dann gerade auf Pascal?

Wir haben uns entschieden, nicht irgendeine exotische Sprache zu wählen oder gar selbst eine zu definieren - da gibt´s ja auch bemerkenswerte Ansätze -, sondern etwas zu nehmen, was weltweit in den letzten zwei, drei Jahren so richtig gekommen ist.

- Es hat bisher kaum einen Schritt gegeben über Pascal als technisch-wissenschaftliche Ausbildungssprache hinaus.

Wir sind diesen Schritt gegangen, zu System-Pascal, das eine Erweiterung ist, ohne die Sprache in ihrem Kern anzutasten. Konzeptionell, oder von der Intention, geht ADA natürlich auch in diese Richtung, vielleicht Jls System-Implementierungssprache noch zwei Schritte weiter. Aber ADA ist noch nicht da.

- Über den ADA-Status haben wir schon andere Versionen gehört.

Es ist nicht anzunehmen, daß ein halbes Jahr nach Veröffentlichung der letzten ADA-Spezifikationen irgend jemand über ein Projekt verfügt, das wirklich diesen sehr komplexen Umfang hat. Kann ich mir nicht vorstellen. Aber vielleicht gibt es noch Genies.

- Sie votieren also für Pascal als das reifere Produkt, obwohl auch für diese Sprache noch keine Norm existiert?

Es ist richtig, daß es noch keine verbindliche internationale Norm für Pascal gibt. Aber es gibt ein ziemlich einheitliches Verständnis von dem, was der Pascalumfang sein sollte. Das ist nun mal eine Sprache, die nicht von einem Komitee, sondern von einem Einzelnen entworfen worden ist. Dr. Niklaus Wirth hat eigentlich ziemlich genau definiert, was es ist. Da mag es noch kleine Differenzen geben, aber dieses von Wirth vorgeschlagene Pascal wird international als Standard angesehen.

- Herr Dietz, Ihrem Plädoyer für Pascal haftet etwas der "Self-Fullfilling-Prophecy-Geschmack" an. Worin liegen die Stärken dieser Sprache?

Durch ihre klare Struktur ist diese Sprache nicht in Gefahr, wie Cobol oder Fortran, daß jeder noch etwas dranhängen will, weil von vornherein Ungereimtheiten vorhanden sind. Beispiel: Wenn Sie einen Swimming-Pool haben, in dem sowieso schon Blätter herumschwimmen und Papier dann schmeißt jeder noch etwas rein.

- Herr Dietz, Sie erwähnten Fortran. Nun gibt´s aber auch noch Pearl als speziell prozeßorientierte Sprache. Ist das, was in die Entwicklung und Normung von Pearl gesteckt wurde, rausgeschmissenes Geld gewesen?

Diese Frage ist furchtbar schwer zu beantworten. Aber ich glaube das eigentlich nicht, und zwar deshalb, weil man dabei sehr viel gelernt hat. Die Leute, die Pearl definiert und implementiert haben - bei den Herstellern, bei den Anwendern und bei den Hochschulen -, die haben tatsächlich sehr viel gelernt.

- Zurück zu Pascal. Wie ist die Situation heute ?

Die meisten Pascal-lmplementierungen, die es bisher gibt, sind irgendwo isoliert. Das heißt, sie stellen dem Benutzer nicht alle Betriebsmittel eines Systems zur Verfügung - vor allem auch keine Realtime-Werkzeuge, Werkzeuge für komplexe Systeme, in denen mehrere Prozesse miteinander kommunizieren.

- Wenn Sie von komplexen Systemen sprechen, meinen Sie auch Distributed Processing?

Ganz eindeutig. Gerade da, wo es um Vernetzung geht, um Computer-Kommunikation, gibt es Echtzeitaspekte, insofern als nämlich viele Prozesse im Computer quasi gleichzeitig ablaufen.

- Welche Chancen geben Sie jetzt Pascal?

Was mich frappiert: Pascal ist die Idee eines Mannes. Es hat Sprachen gegeben, Werkzeuge und Konzepte, die entweder von großen nationalen und internationalen Instituten oder von sehr großen Unternehmen propagiert wurden. Man hat viel Geld hineingesteckt - und Autorität. Ohne großen Erfolg. Pascal dagegen macht den Leuten offensichtlich Spaß, und es ist auch eine gute Sache.

- Der große Wurf ist es noch nicht.

Das hängt davon ab, welche Ansprüche gestellt werden. Wenn sehr mächtige Statements verlangt werden, dann läßt Pascal sicher etwas zu wünschen übrig. Aber das ist natürlich auch sehr gefährlich. Denn das ist äußerst schwer implementierbar und die Effizienz ist eben auch in Frage gestellt. Ein ganz anderer, mir wichtig erscheinender Aspekt: Diese Werkzeuge sind algorithmische Sprachen. Sie müssen Schritt für Schritt beschreiben, was im Programm ablaufen soll. Es ist die Frage, ob die Entwicklung und Verfeinerung der algorithmischen Sprachen immer noch sinnvoll ist, oder ob es nicht Programmvorgaben gibt, die keinen schrittweisen Ablauf darstellen, sondern Parameter für eine vordefinierte Makrofunktion verwenden.

- ADA kommt dem aber doch schon sehr nahe.

Überhaupt nicht. ADA ist eine algorithmische Sprache wie jede andere auch. Ich denke da an etwas total anderes, von dem die wenigsten Leute heute eine präzise Vorstellung haben. Entscheidungstabellen und so etwas gehen ein bißchen in diese Richtung. Aber es ist die Frage, ob man nicht 1990 über diese Dinge ganz anders denkt. Man wird dann zwar noch algorithmische Programmiersprachen einsetzen, ohne jeden Zweifel - aber ob´s dann noch der letzte Heuler sein wird?

- Stichwort "Mikrocomputer": Auch hier konnten sich die Hersteller nicht auf Pascal als einheitliche System-Implementierungssprache einigen.

Ja, es gibt eine Pascal-Front bei den Mikroprozessor-Herstellern, und dann gibt es eine Front, die aus traditionellen Gründen entweder Assembler oder die sogenannten PL-Sprachen bevorzugt.

- Noch ein Komitee wäre also nicht schlecht ...

Bei den Mikroprozessoren ist es besonders wichtig, daß gute Werkzeuge zur Verfügung stehen, sonst werden die Effekte, die man erzielen will in keiner Weise erreicht. Nur ist es offensichtlich wahnsinnig schwer, eine vernünftige Standardisierung zu erreichen, die gleichzeitig noch aktuell ist und drittens den technischen Fortschritt nicht behindert. Im Grunde stecken da Zielkonflikte drin. Normen sollte man eigentlich erst setzen, wenn man Erfahrung besitzt, und wenn man das sichere Gefühl hat, wenn wir das jetzt festschreiben, dann machen wir nichts falsch. Gewisse Irrwege sind da schon erkannt worden und werden nicht mehr gegangen. Das heißt aber, daß Normung nicht aktuell sein kann. Darin liegt ein Widerspruch in sich. Genauso ist es eben auch mit der Frage der Behinderung des technischen Fortschritts. Wenn man etwas normt, dann schreibt man es ja fest, das heißt, man bremst die weitere Entwicklung und das teilweise durchaus im Interesse der Anwender, und durchaus auch der Hersteller. Aber man behindert Neues. Also auch hier gibt´s ein Spannungsverhältnis - und es ist wohl schwer zu lösen.