Ein Leserbrief von Frank Berger*
In der CW Nr. 1 vom 4. Januar 1991 wurde im Rahmen eines "C"-Schwerpunktes auf Seite 22 ein Beitrag gedruckt, der die Eignung von C beziehungsweise Cobol für die Anwendungsentwicklung zum Thema hatte. Zwar ist der Wert einer solchen Gegenüberstellung, die ein wenig an einen Vergleich von Äpfeln und Birnen - erinnert, eher zweifelhaft, die Art und Weise wie dieser Beitrag das Thema zu behandeln wußte, verlangt allerdings nach einer Richtigstellung.
Der Beitrag beginnt mit der Behauptung, Cobol und C seien für fast alle Aufgaben geeignet. Natürlich, wissen wir seit Turing, daß dies prinzipiell richtig ist - aber eben nur - prinzipiell. Versuchen Sie mal eine Interrupt-Anforderung in Cobol zu bedienen oder den Kompressionsalgorithmus LZHUF zu codieren. Viel Vergnügen.
Immerhin räumt der Autor ein, daß man auch in C komplexe Systeme programmieren kann. Darin zählt er jedoch jene Vorteile von Cobol auf, die hier kommentiert werden sollen. So führt er die große Programmierergemeinde an, als ob diese ein Wert an sich sei.
In der Folge merkt er an, daß es "ineffektiv sei, die Zeit mit dem Erlernen neuer Programmiersprachen zu verbringen, die die Produktivität oder die Fähigkeit der Zielsysteme nicht verbessern". Recht hat er. Aber genau hier liegt der springende Punkt: C ist mächtiger als Cobol und kann demzufolge die Entwicklung besser unterstützen. Beschränkt man sich in seinen Problemstellungen freilich auf Drucklisten und einfache Satzgruppenverarbeitung, reicht Cobol durchaus; leider ist dies aber, wie zumindest meine berufliche Realität zeigt, nicht immer möglich. Im weiteren argumentiert er, daß die überwiegende Zahl der kommerziellen Programme in Cobol geschrieben und so leicht nicht zu ersetzen seien. Zwar ist diese Feststellung korrekt, aber daraus läßt sich nicht ableiten, warum neue Entwicklungen nicht auch in C erfolgen können.
Über die Struktur der Programmiersprache weiß er mit der Bemerkung zu glänzen, Cobol sei nicht alt, sondern ausgereift. Soll tatsächlich wahr sein, daß der theoretischen Informatik seit Ende der 50er Jahre nichts besseres eingefallen ist? Führt man sich vor Augen wie oft Cobol verbessert werden mußte - nämlich in den Jahren 1968, 1974 und 1985 -, dann kann die Konzeption nun doch nicht so weitblickend gewesen sein.
C kann man nicht als Newcomer bezeichnen
C - mit fast 20 Jahren auf dem Buckel sicher nicht der Newcomer, als der er vom Autor apostrophiert wird - bedurfte nur geringer Verbesserungen, ein Hinweis darauf, wie stimmig hier der Entwurf im Gegensatz zu Cobol ist.
Sodann vergleicht er die Sprachelemente der beiden Kontrahenten. Die leichte Erweiterbarkeit durch Funktionen die einen Teil der Ausdrucksstärke von C ausmacht, erwähnt er, weiß aber auch zu berichten, daß der Einsatz von selbsterstellten oder gekauften Toolboxen zu einer Erhöhung des Aufwandes für Training und Wartung sowie zu einer mangelnden Portabilität führt.
Natürlich muß man die Funktionen einer Toolbox erlernen, dieser Aufwand ist aber erfahrungsgemäß gering. Die Alternative, immer alles aufs neue zu erfinden, zu kodieren und zu testen, ist ja wohl indiskutabel (wie sagt die Werbung einer amerikanischen Toolbox: The wheel ... not a bad idea ... until you have to reinvent it).
Gerade die Wiederverwendbarkeit ist auch in der von ihm angesprochenen objektorientierten Programmierung ein Hauptansatzpunkt. Toolboxen bieten genau das: die Wiederverwendung von ausgereistem, ausgetesteten und qualitativ hochwertigem Code. Warum dieser weniger portabel sein soll, ist mir unverständlich, gibt es doch Systeme, die auf einem halben Dutzend verschiedener Plattformen identische Funktionalitäten bieten. Auf der anderen Seite ist mir nicht Vorstellbar, wie der Autor zum Beispiel grafische Benutzeroberflächen unterstützen und ausnutzen will, ohne Abstriche bei der Portabilität zu machen.
Außerdem vermißt der Autor die leichte Formatierbarkeit in C. Hierzu sollte er lieber die zugegebenermaßen nicht triviale Beschreibung der Print-Familie lesen.
Hier gibt es einige Möglichkeiten, die man in Cobol vermißt; auf der anderen Seite wäre es sehr einfach, die bei C fehlenden Möglichkeiten innerhalb von ein bis zwei Tagen nachzurüsten. Und es fehlt der Sort? Der Autor sollte doch zumindestens erwähnen, daß es diese Möglichkeit sehr wohl in einigen Standardbibliotheken (zum Beispiel von Unix) gibt.
Die mangelnde ISAM-Verwaltung läßt sich leicht durch Kauf erledigen. Da man solche zum Teil durchaus leistungsstarke Systeme zu erstaunlich günstigen Bedingungen im Sourcecode erhält, ist nicht einzusehen, warum die Abhängigkeit von externen Faktoren erhöht wird. Nach der Meinung des Autors sollte auf solche Privatdateien aber zugunsten eines unternehmensweiten Datenmodells in einer Datenbank verzichtet werden. Und eine Datenbank hat auch Cobol nicht integriert.
Ein echtes Manko für die kommerzielle Entwicklung stellt bei C das Fehlen eines standardmäßigen Datentyps mit BCD-Arithmetik dar. Zwar ist es nicht so, daß die Ergebnisse "unvorhersehbar" sind, wie der Autor schreibt, das Auftreten von Rundungsfehlern muß vom Entwickler aber gelegentlich berücksichtigt werden. Obwohl C durch eine Funktionssammlung leicht diese Funktionalität erhalten könnte, ist die Syntax doch etwas umständlicher, da man keinen Operator nutzen kann.
Schwachpunkte von C werden nicht erwähnt
Was er zur Verständlichkeit bemerkt, ist immerhin subjektiv, wie er selber sagt; einem Japaner werden seine Schriftzeichen auch verständlicher sein als unser Alphabet - natürlich nur rein subjektiv.
Interessant ist aber auch, was der Autor an Vorteilen der Sprache C hervorhebt, beziehungsweise welche Schwachpunkte - die es natürlich auch gibt - er nicht erwähnt. Dies ist für mich ein Indiz, daß ihm möglicherweise die nötige Erfahrung für eine fundierte Beurteilung fehlt.
Zeigen wir nur einige der unerwähnten Highlights. Neben der Eigenschaft, Werte zurückzuliefern, können Funktionen und Prozeduren auch rekursiv aufgerufen werden. Einem gestandenen Cobol-Programmierer erscheint dieses Konzept vollkommen überflüssig. Programmierer, die diese Möglichkeit verinnerlicht haben, finden in vielen Situationen Einsatzmöglichkeiten, die den Code vereinfachen beziehungsweise eine halbwegs übersichtliche Implementierung erst ermöglichen, insbesondere bei rekursiven Datenstrukturen.
Die Konzeption der Zeiger läßt einige sehr effiziente Lösungen zu und ermöglicht zudem eine klarere Strukturierung, wie es zum Beispiel durch den Einsatz von Zeigern auf Funktionen möglich ist. Insbesondere mit letzterer Konstruktion läßt sich ein Code erzeugen, der knapp und effizient ist und zusätzlich noch an Übersichtlichkeit gewinnt.
Große Bedeutung kommt, sich auch der Möglichkeit zu, sich
zur Laufzeit Speicher zu allokieren. Wer kennt nicht das Dilemma mit Arrays. Entweder sind sie zu klein oder man verschwendet Unmengen Speicher. Mit einer dynamischen Anforderung ist man dieser Probleme
enthoben.
Zur besseren Lesbarkeit und Strukturierung tragen auch die lokalen Variablen bei, die die Lokalität der Information erhöhen. Alles dies sind Konzepte, die in keinster Weise von Cobol erbracht werden können. Gegen die BCD-Arithmetik aufgewogen, bleibt also ein eindeutiger Zugewinn.
Geschwindigkeit ist ein wichtiger Faktor
Aber sind dies nicht alles theoretische Spielereien? Zählt nicht allein die Performance?
Auch wenn die Entwicklungszeit (inklusive Nachdenken) nicht in einem Benchmark zum Ausdruck kommt, ist die Geschwindigkeit doch ein wichtiger Faktor. Und da weiß der Autor erstaunliches zu berichten. Zählte es doch zu meinen festen (Vor-)Urteilen, daß C eine der schnellsten Hochsprachen ist. Die Zahlen in dem Artikel beweisen jedoch scheinbar das Gegenteil.
Zunächst ein Wort zu Benchmarks allgemein. Natürlich kann jede Sprache durch den Compiler so optimiert werden, daß hocheffizienter Code generiert wird. Es gibt überhaupt keinen theoretischen Grund, warum ein Programm in Modula-2 langsamer sein sollte als ein ebensolches in C. Durch die maschinennähere Struktur ist es aber leichter, einen wirksamen Optimierer im Compiler zu implementieren, was gemeinhin auch durch die Benchmarks belegt wird.
Wie kommt es nun zu den guten Cobol-Ergebnissen, die ja nicht ohne weiteres von der Hand zu weisen sind? Der Autor höchstselbst zweifelt alle Benchmarks an, die er nicht selbst gefälscht hat. Die angeführten Tests geben das Verhalten von Cobol-Programmen wieder, die nach C portiert wurden. Hatte der Autor die nötige Erfahrung, die Programme in Strukturen umzusetzen, die C-gemäß sind? Welche Funktionen hat er benutzt?
Möglicherweise sind die langsamen Funktionen benutzt worden, die über das Dateisystem gehen anstatt derjenigen, die über das BIOS laufen. Vielleicht wurde gar in den Bildschirmspeicher geschrieben. Dann wäre allerdings leicht ein Unterschied um den Faktor 40 möglich. Wenn die Übersetzung ohne Optimierungen durchgeführt wurde, dann kann auch das zu einer Halbierung der Laufzeit geführt haben.
Insbesondere ist zu bedenken, daß diese Tests wahrscheinlich Möglichkeiten abdecken, die in Cobol effektiv ausdrückbar sind; was ist aber mit den erwähnten Problembereichen, die in Cobol kaum mit vertretbarem Aufwand zu lösen sind?
Betrachten wir den Siebtest. Natürlich ist eine Primzahlberechnung kein Anwendungsfall, wie der Autor süffisant erwähnt. Dieser Test mißt in etwa die Geschwindigkeit von Integer-Berechnungen, Array-Zugriffen und Schleifen. Und wie durch ein Wunder benötigt in diesem Test, der in beiden Sprachen angemessen ausdrückbar ist, der C-Compiler mir zirka 40 Prozent der Zeit, was wahrscheinlich der Realität bei nicht Cobol-spezifischen Testprogrammen näherkommt.
Interessant auch die Bemerkung, das Ratfor ein Vorläufer von C sei. Auf allen mir bekannten Rechnern ist Ratfor (rational fortran) ein Precompiler, der dem guten alten Fortran ein paar Elemente der strukturierten Programmierung beibringen soll. Eine sprachliche Verwandschaft, zu C kann ich kaum erkennen.
Natürlich hat C Mängel. Einige sind meiner Einschätzung nach sogar gravierend. Zunächst ist diese Sprache, wie allgemein bekannt, keinesfalls leicht zu erlernen. Trotz des geringen Umfanges des Sprachkerns erfordert es einige Praxis und fundierte Kenntnisse, um diese Sprache angemessen zu benutzen. Das ist zumindest meine, Erfahrung, und ich hatte durchaus Gelegenheit, Anfängern in C über die Schulter zu schauen. Bemerkenswert ist, daß trotzdem nach einer ersten schmerzhaften Zeit keiner der Umsteiger mehr mit Cobol programmieren wollte.
Weiterhin erzwingt C keine sauberen und übersichtlichen Programme wie beispielsweise Modula-2. Man kann durchaus den schlimmsten Spaghetti-Code produzieren, unlesbar, unportabel und ineffizient. Es gehört schon eine gewisse Erfahrung mit strukturierter Sprache und auch Assembler dazu, C-Programme zu schreiben, die leistungsstark und lesbar sind. Der Umstieg zum Beispiel von Cobol auf C oder von Basic auf C, gepaart mit einem einwöchigen Kurs, führt meiner Erfahrung nach nicht zum Erfolg.
Weiterhin bietet insbesondere das klassische C kaum immanente Sicherheiten. Man geht davon aus, daß der Programmierer weiß, was er tut. So werden kaum Typenüberprüfungen vorgenommen, weder innerhalb eines Sourcecodes noch zwischen Dateien. Neuere Entwicklungen wie ANSI-C oder sehr viel stärker noch C + + oder Objective-C, haben aber hieraus gelernt.
Als Fazit kann man sagen, daß bei entsprechender Qualifikation der Entwickler die Programmiersprache C in jedem Falle vorzuziehen ist, da die Sprache ein leistungsfähiges Universalinstrument darstellt, das nahezu jedem Problem adäquat gewachsen ist.