Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

03.04.1978 - 

Dr. Schnupp, Softlab, diagnostiziert "jämmerlichen" Entwicklungsstand der meisten Programmiersprachen:

"Informatiker produzieren an der Praxis vorbei"

BRAUNSCHWEIG - Daß die Informatikforschung "weitgehend an den Benutzer- Bedürfnissen vorbeiproduziert", kritisierte Dr. Peter Schnupp, Softlab München. Auf der 5. Fachtagung " Programmiersprachen" der Gesellschaft für Informatik vertrat Schnupp die Ansicht, daß sich die Informatikforschung "unverständlicherweise auf die Programmiersprachen zur Umsetzung des grob geplanten Problems in das ablauffähige Maschinenprogramm beschränkt".

Dabei habe, so Schnupp bei seiner "Informatiker-Schelte", fünf Sechstel des Fehlerbehebungsaufwands seinen Ursprung in der Entwicklungsphase, in der die gewählte Programmiersprache eine Nebenrolle spiele.

Der Fachausschuß "Programmiersprachen" der Gesellschaft für Informatik (GI) hatte sich für seine fünfte Fachtagung in Braunschweig vorgenommen, "sich vor allem der Anwendung von Programmiersprachen zu widmen, um endlich die nach wie vor weit offene Lücke zwischen Hochschulforschung und der Praxis in Wirtschaft und Verwaltung überbrücken zu helfen". Dennoch befand sich unter den zehn vom GI-Fachausschuß angenommenen Kurzvorträgen nur ein Praxisbericht. Bemängelte Referent Gerhard Niemann von der Thyssen AG: "Der derzeitige Entwicklungsstand bei den Programmiersprachen ist alles andere als ideal."

Um den Mangel an praxisbezogenen Berichten auszugleichen, hatte die GI zu den vier Hauptvorträgen "bewußt Referenten mit provozierenden Themen aus der rauhen Wirklichkeit der Wirtschaft und Verwaltung eingeladen".

So sprach Frau Dr. Jean Sammet von der amerikanischen IBM über "Stand und Entwicklungstrends von Programmiersprachen"; berichtete Professor Peter Canisius von der Bundesanstalt für Straßenwesen in Köln über die "Akzeptanz der DV in Forschung und Verwaltung"; referierte Dr. Bernd Eichenauer von der Gesellschaft für Prozeßrechnerprogrammierung in München über "Prozeßprogrammiersprachen und Portabilität".

Provozierend und diskussionsanregend fiel nach Meinung einiger Teilnehmer allerdings nur der Schnupp-Vortrag ("Ist Cobol unsterblich?") aus. Schnupp ging dabei mit den Informatikforschern hart ins Gericht: " Bei denen findet der Softwarepraktiker so gut wie gar keine Unterstützung in den angebotenen Sprachen."

Dies sind die interessantesten Passagen des Schnup-Referats:

Es gibt inzwischen viele hundert Programmiersprachen. Unter Informatikern sieht man viele davon als "schlecht" an. Das Kriterium für dieses Urteil ist in der Regel, wieweit die jeweilige Sprache einen guten Programmierstil unterstützt und dem Anwender eine durchsichtige, nachvollziehbare und - wenn möglich - beweisbar richtige Steuerfluß-Struktur des in ihr formulierten Programms nahelegt.

Beispiele für in diesem Sinne "schlechte" Sprachen sind Cobol, Assembler und Fortran, entschuldbar nur durch ihr inzwischen historisches Alter - obgleich das nicht viel jüngere Algol noch heute als "gut" gilt. Aber auch manche neue Sprache ist "schlecht": etwa Basic, welches sicher noch weit unter Fortran einzuordnen ist, und PL/1, welches zwar eine saubere und leicht verständliche Programmierung ermöglicht, sie dem Durchschnittsprogrammierer jedoch sicher nicht nahebringt.

Meist aus Algol entwickelten sich aber auch zahlreiche neue, als "gut" akzeptierte Sprachen - neben dem direkten Nachfolger Algol 68 etwa Pascal und Modula für die allgemeine Programmierung, Implementierungssprachen wie Mary, C, LIS oder auch Sprachen, welche wie Ela....sonders auf die Schulung im algorithmischen Denken und Formulieren abgestimmt sind.

Daß diese neuen Sprachen die alten verdrängen, sollte selbstverständlich sein. Welcher praktisch arbeitende Programmierer wird bei diesem reichen Angebot noch so töricht sein, eine schlechte Sprache zu benutzen?

Die Antwort auf diese Frage brachte eine Marktuntersuchung, die Infratest 1975 für uns bei Anwendern von Siemens- und IBM-Großzechnern durchführte: Alle!

Die Spracheinführung als Marketing-Problem

Die Situation ist absurd, unerfreulich und frustrierend. Bedenkt man den hohen Einsatz an Zeit, Geist und Geld, welcher seit Jahren in die Entwicklung immer besserer Programmiersprachen investiert wurde, so sollten die entstandenen Produkte endlich auch außerhalb des Hochschulbereichs bekannt und praktisch genutzt werden.

Sicher gibt es Gründe für die mangelnde Akzeptanz der neuen Sprachen in der Praxis. Die großen Hersteller werden häufig genannt, welche bewußt "eigene" Sprachen wie Pl/1, forcieren und aus verschiedenen Gründen den anderen neuen Entwicklungen feindlich gegenüberstehen würden. Daß dieses Argument kaum stichhaltig ist, zeigt der Erfolg von Basic, einer neuen Sprache, die sich ohne jede Herstellerunterstützung vor allem im Kleinrechnerbereich durchgesetzt hat, obwohl sie vielleicht zu den ,schlechtesten" überhaupt gehört.

"Marktlücke" freilich ist weder in der Informatik noch in der EDV-Praxis ein eingeführter Fachbegriff.

Könnte es sein, daß gerade dies der wichtigste Grund für das Versagen praktisch aller neuen Sprachentwicklungen im breiten Markt der "Konsumprogrammierung" ist? Daß zwar viel über die technische Konstruktion des Produktes "Programmiersprache" nachgedacht wird, nicht aber über seinen "Vertrieb" ?

Und Produktentwicklung in diesem Sinne betrieb auf dem Gebiet der Programmiersprachen bis jetzt allenfalls IBM mit PL/1 und APL . . .

Akzeptanzprobleme im Benutzer

Häufig wird offenbar von Sprachentwicklern übersehen, daß der Programmentwickler in der Industrie und bei EDV-Anwendern kein Informatiker, kein Mathematiker und meist sogar noch nicht einmal ein Naturwissenschaftler ist. Deshalb liegt ihm oft das Denken in Algorithmen ferner als das in statischen Strukturen, vor allem Datenstrukturen und deren Transformationen. Das gilt vor allem in der kommerziellen Datenverarbeitung, wo die zu behandelnden Probleme in der Regel komplizierte Datenbasen, jedoch nur sehr einfache Verarbeitungsalgorithmen erfordern.

Dies erklärt den Erfolg strukturorientierter Sprachen und Programmiermethoden, seien es nun Entscheidungstabellen, Datenbank-Sprachen, RPGs und NPGs, oder auch der "Jackson-Methode" zur syntaxorientierten Entwicklung des Programms aus den Datenstrukturen. Und es erklärt teilweise die starke Stellung von Cobol, welches unter den älteren Sprachen die ausgefeiltesten sprachlichen Mittel zur Beschreibung von Datenbasen zur Verfügung stellt und darin auch nur von wenigen modernen Sprachen übertroffen wird.

Was bei der Entwicklung neuer Programmiersprachen offenbar häufig versäumt wird, ist etwas, was jeder ordentliche Anwendungsplaner inzwischen als selbstverständlichen Teil der Problemanalyse empfindet: die Erforschung und exakte Definition eines "Benutzermodells" mit einer möglichst genauen Beschreibung der Aufgaben, Wünsche, Fähigkeiten, Vorlieben und Arbeitsweisen der künftigen Anwender.

Akzeptanzprobleme in den Benutzerbedürfnissen

Daß die neueren Programmiersprachen fast nicht zur Kenntnis genommen werden, ist jedem, der viel mit Anwendungspraktikern verkehrt, offensichtlich. Also liegt der Verdacht nahe, daß ihre Vorteile gegenüber den alten als nicht sehr wesentlich empfunden werden.

Welche Vorteile werden denn für die neueren Sprachen propagiert? Es ist primär die bessere Eignung für die "strukturierte Programmierung" im engeren Sinne, die Möglichkeit, in ihnen die logische Ablaufstruktur eines Algorithmus klarer und problemnäher zu codieren als in Cobol oder Fortran. Manche Anwender halten dies aber nicht einmal für sinnvoll, und kaum einer glaubt, daß dadurch die Programmproduktion nennenswert verbessert wird.

Akzeptanzprobleme im Produkt

Selbst wenn die neueren Programmiersprachen einwandfrei besser wären als die alten, wäre somit ihre breite Durchsetzung infolge des zu geringen Bedürfnisses bei den prospektiven Anwendern nicht ganz einfach. Oft werden jedoch bei ihrem Entwurf Entscheidungen getroffen, die vielleicht für ihre Anwendung in wissenschaftlichen Instituten Vorteile bringen, vom Standpunkt des Praktikers in der industriellen Softwareproduktion jedoch als grobe Designfehler gewertet werden müssen und ihre Vorteile gegenüber den älteren Entwicklungen zumindest teilweise wieder aufheben.

Akzeptanzprobleme in der Vertriebsunterstützung

Gleichgültig, wie gut eine Programmiersprache ist - sie braucht ebenso wie jedes andere Produkt eine Vertriebsunterstützung. Dazu gehören

- Prospekte, Beschreibungen, Gebrauchsanleitungen,

- Referenzen und Benutzungsbeispiele.

In beiden Punkten mangelt es bei neuen Sprachentwicklungen. Die Literatur besteht oft nur aus der Sprachbeschreibung, manchmal überhaupt nur aus der formalen Definition der Syntax und Semantik, welche für 90% der praktisch arbeitenden Programmierer unverständlich ist. Und wenn es sich dann gar noch um eine mehrstufige Grammatik handelt, wie etwa im Falle von Algol 68, steigt dieser Prozentsatz sicher auf 99 Prozent! Das wäre vielleicht nicht so schlimm. Denn kaum ein Programmierer erlernt in der Praxis eine Sprache aus dem Manual oder gar der formalen Beschreibung. Der Praktiker läßt sie sich von einem Kollegen erklären oder absolviert eine kurze Schulung und greift dann zu Programmlisten, die er durchliest und - zumindest am Anfang seiner Bemühung um die neue Sprache - ausschnittsweise abwandelt und kopiert.

Sprachentwicklung für den "Massenmarkt"

Um die alten Sprachen nicht nur in einzelnen Forschungsprojekten, sondern auf dem breiten Markt der Anwendungsprogrammierung zu verdrängen, müssen neue Sprachentwicklungen nicht nur besser sein, sondern auch als besser empfunden werden. Da man in Cobol, Fortran und Assembler durchaus gut programmieren kann, ist das letztere nur durch das zu erreichen, was im Marketing " Zusatznutzen" genannt wird: neue Sprachentwicklungen müssen mehr sein als konventionelle Programmiersprachen. Sie müssen dem Programmierer helfen, Software zu entwickeln und nicht nur zu kodieren.

Und industrielle Softwareentwicklung ist weit mehr als die eigentliche Formulierung des

Programms, ob strukturiert oder unstrukturiert.

Für die Formulierung jeder der Wechselbeziehungen zwischen

- Programmentwickler,

- Aufgabe,

- Auftraggeber und

- Zielrechner

werden sprachliche Mittel und Darstellungsmethoden benötigt - nicht nur zur Abbildung der Aufgabe auf dem Zielrechner.

Solange die Programmiersprachen-Entwickler sich ausschließlich mit dieser relativ kleinen Teilaufgabe beschäftigen, wird Cobol unsterblich sein. Cobol ist bekannt, überall implementiert und gar nicht so schlecht, wie manche Ästheten es machen möchten.

Sprachen oder Sprachfamilien, die es ablösen möchten, müssen nicht nur mindestens ebenso gut sein - wobei gut hier nicht nur im Sinne der Ablaufstrukturierung verstanden werden soll sondern auch die Datenstrukturierung, das Datenmodell für die Ein-/ Ausgabe und die Integration in das Betriebssystem umfaßt. Sie müssen vor allem auch die Planung und Analyse unterstützen: die Durchdringung und Formulierung der eigentlichen Aufgabe und ihre Diskussion mit dem Auftraggeber.

So verteilen sich die Kosten eines typischen Anwendungs-Programm-Systems. Nut etwa vier bis acht Prozent des Gesamtaufwandes entfallen auf die Codierung und den Komponententest - den Teil des Entwicklungsprozesses, der die Wahl der Programmiersprache primär zum Besseren oder Schlechtern beeinflußt. Lohnt es sich wirklich, darüber viel nachzudenken?