stopsoftwarepatents.eu petition banner

Über APL

Wer APL kennen lernt, wird zum großen Liebhaber oder zum engagierten Gegner - kalt läßt APL kaum jemanden.

APL steht für "A Programming Language"- aber APL wurde nicht als Programmiersprache "erfunden", sondern als algorithmische Beschreibungssprache. Damit wurde bei der IBM in den Sechzigern die interne Architektur der damaligen Großrechner beschrieben. Dies gelang gut. Es gelang sogar so gut, daß sich eine Implementierung als Computersprache geradezu aufdrängte.

APL unterscheidet sich von anderen Programmiersprachen nicht durch die eine oder andere Feinheit - APL ist völlig anders.

APL ist ein Interpreter

Und weil APL ein Interpreter ist, kann man interaktiv damit arbeiten: Man gibt eine oder mehrere Anweisungen ein; sobald man die Enter-Taste drückt, versucht der APL-Interpreter diese Anweisungen auszuführen - und wenn man nichts verkehrt gemacht hat, erhält man sofort ein Ergebnis.

Dies ist sicher der Hauptgrund, warum Statistiker APL als Werkzeug benutzen: APL reagiert sofort. Hat man einen Fehler gemacht oder will seine Daten weiter manipulieren, kann man das sofort und unmittelbar tun.

Dies ist aber auch ein Grund, warum APL-Programmierer bei dem Wort "debuggen" keinen Schweißausbruch erleiden: APL-Programmierer verbringen eben nicht 70-90% der gesamten Zeit eines EDV-Projekts mit der Fehlersuche.

Übrigens sind auch JavaScript, PHP und Pearl interpretierte Programmiersprachen, um nur einige Beispiele zu nennen.

APL verwaltet den Hauptspeicher selbstständig

Kein anfordern von Speicher, kein freigeben von nicht mehr benötigtem Speicher. Und natürlich kein vergessen solcher Maßnahmen. Es müssen keine Garbage-Collection-Routinen programmiert werden - dies wird alles vom APL-Interpreter erledigt. Jahrelang wurde dieses Konzept kritisiert - seit .NET genau das gleiche bietet, ist diese Kritik verstummt.

APL verwaltet Pointer selbständig

APL kennt Pointer - aber weil die Verwaltung von Pointern so gefährlich und fehlerträchtig ist, übernimmt APL die Verwaltung lieber selbst - wie dies auch Java tut. Damit ist die Haupt-Fehlerquelle traditioneller C-Programme ausgeschaltet.

APL verwaltet Datentypen selbständig

Die Definition von Datentypen entfällt, weil sie vom APL-Interpreter übernommen wird. Und wenn man Integer auf Float addiert: kein Problem, APL nimmt alle notwendigen Konvertierungen selbständig vor. Puristen graust es, Praktiker seufzen erleichtert auf.

APL kennt keine Schlüsselwörter oder Befehle

Der eingebaute Sprachumfang wird mit mathematischen und grafischen Symbolen sowie einigen wenigen Zeichen aus dem griechischen Alphabet dargestellt. Übrigens spricht man bei APL von Operatoren und Funktionen, wobei Funktionen auf Daten (=Arrays) angewendet werden, Operatoren aber immer auf Funktionen und manchmal auch auf Daten. Da APL-Funktionen ebenso wie APL-Operatoren ganz außergewöhnlich mächtig sind, führt diese Art der Darstellung zu sehr kurzen Programmen, die ungeheuer viel bewirken können.

APL ist eine nicht-skalare Programmiersprache

Manchmal wird APL auch als "Array Processing Language" bezeichnet. Mit Recht. Klassische Programmiersprachen wie C (mit und ohne ++), Pascal oder Basic sind skalare Sprachen - sie können immer nur einen skalaren (=einzelnen) Wert auf einmal verarbeiten. Wenn man in diesen Sprachen die Summe eines Vektors mit zehn verschiedenen numerischen Werten benötigt, muß man eine Schleife über den Vektor legen, um die einzelnen Werte (=Skalare) zu addieren. In APL geht dies anders, denn APL kann Arrays (=jede Datenstruktur) beliebiger Dimension auf einen Schlag verarbeiten: Skalare, Vektoren und Matrizen ebenso wie multidimensionale oder geschachtelte Arrays.

Wie das geht? Ein Beispiel: A sei ein Vektor. Um die Summe aller Elemente zu errechnen, benötigen wir natürlich die Funktion +. Um diese Funktion auf alle Elemente des Vektors A anzuwenden, müssen wir ein Konzept einführen, das es in dieser Form sonst nirgends gibt: in APL gibt es Operatoren, die auf Funktionen und Arrays angewendet werden. APL-Operatoren sind also etwas völlig anderes als die Operatoren anderer Programmiersprachen.

Um die Summe des Vektors A mit APL zu errechnen, wenden wir den Operator "Reduce" auf die Funktion + und den Vektor A an:

+/A

Im APL-Sprachgebrauch ist die Funktion + ein Operand des Operators "Reduce". Daraus entsteht eine so genannte abgeleitete Funktion "Summiere", die auf ihr Argument angewendet wird: den Vektor A. Dies veranlaßt APL, die Funktion + zwischen die einzelnen Elemente (=Skalare) des Vektors A zu setzen. Es entsteht also:

A[1] + A[2] + A[3] + ... + A[n]

Es bedarf keiner Schleife, um dieses Problem zu lösen. Nicht nur das! Wir müssen nicht einmal wissen, wie viele Elemente A hat. Ob A nur ein Element hat oder 4724 oder kein einziges, immer erhalten wir die Summe aller Elemente.

Wollten wir das Produkt aller Werte von A wissen, muß nur die Funktion + gegen die Funktion x getauscht werden:

x/A

Und wenn A kein Vektor wäre, sondern eine Matrix? Zum Beispiel mit 34 Zeilen, nehmen wir an, Filialen? Und 12 Spalten, nehmen wir an, Monaten? Und wir wollen den Gesamtumsatz des Jahres wissen?

+/,A

Das Komma ist in APL eine Funktion. Mit linkem und rechtem Argument aufgerufen, verbindet es beide Argumente (=concatenate). Ohne linkes Argument aber macht es aus dem rechten Argument (hier die 34x12-Matrix A) einen Vektor mit 34x12 = 420 Elementen (=aufreihen). Und +/ addiert diesen Vektor auf, wie wir schon wissen.

Und wenn wir nur die Filialen addieren wollen? Dann müssen wir dem APL-Interpreter sagen, auf welche Achse (Zeilen oder Spalten) die abgeleitete Funktion "Summiere" angewendet werden soll: die erste Achse (=Filialen) oder die zweite Achse (=Monate):

+/[1]A

....

+/[2]A

....

Diese wenigen Beispiele zeigen bereits, wie mächtig dieses Konzept ist. In der Tat werden Projekte mit APL deutlich schneller realisiert als z.B. in C. Je nach Anwendung sprechen wir über den Faktor 5 bis 15 gegenüber C++. Eine Tatsache, die bei den heutigen Personalkosten jeden EDV-Verantwortlichen nachdenklich machen müßte, aber die Herren schielen ja lieber nach Indien, China oder die Ukraine.

In seiner schwersten Zeit, den Jahren zwischen 1980 und 1990, hat sich APL nur aufgrund des enormen Geschwindigkeitsvorteils beim Erstellen von Anwendungen halten können. Warum aber war diese Zeit für APL so schwer? Dies hat zwei Gründe:

Als interpretierende Sprache stellt APL hohe Anforderungen an die Leistungsfähigkeit eines Prozessors. Erst auf 486ern konnten APL-Programme in akzeptabler Geschwindigkeit ausgeführt werden. Hinzu kam der Speicherhunger. Durch seine Fähigkeit, Daten beliebiger Struktur und Größe mit einem Schlag zu verarbeiten stellt APL auch hohe Anforderungen an die Ausstattung des jeweiligen Rechners mit Hauptspeicher.

Auf einem MVS-System der frühen 80-Jahre mit maximal 16 MB Realspeicher oder einem Z80-PC mit 64 KB waren das K.O.-Kriterien. Auf Pentium-Systemen bei extrem gefallenen Preisen für Hauptspeicher sind dies keine relevanten Punkte mehr. Im übrigen verbraten Excel oder Word in ganz anderem Maßstab Ressourcen, als APL dies jemals tat. Da gleichzeitig auch die Großrechner erheblich zugelegt haben, ist der Einsatz von APL auch dort kein Problem mehr.

In den Achtzigern war IBM der wichtigste APL-Lieferant. Leider muß man sagen, daß IBM diese Zeit schlecht genutzt hat. Nach der Ablösung des veralteten VSAPL durch APL2 hat die IBM keine einzige wirkliche Neuerung der Sprache mehr zustande gebracht. Anfang der Neunziger haben die Konkurrenzinterpreter APLX und Dyalog-APL die Führung übernommen - und seitdem wurden beide Interpreter immer weiter verbessert.

Heute lassen diese Interpreter so gut wie keine Wünsche mehr offen. Während die Verwendung von APL auf Mainframes seit Anfang der Neunziger merklich zurückgeht (alles auf Mainframes geht zurück, auch APL), steigt die Verwendung von APL auf leistungsfähigen PC`s seither an.

Obwohl sich also in den letzten Jahren vieles verändert hat, was den Einsatz von APL früher verhindert (oder jedenfalls erschwert) hat, werden manchmal auch heute noch die alten Gegenargumente angeführt. Was sind dies für Argumente?

APL ist teuer, weil es sehr viel Hauptspeicher benötigt

Da ist was dran. Gewesen. Heute befinden sich die Preise für Hauptspeicher im freien Fall...

APL kann auf PC's nicht verwendet werden, weil es zuviel CPU-Ressourcen benötigt.

Das war auf einem 80286 und auch noch 80386 sicher nicht so falsch. Auf einem 80486 lief APL schon recht ordentlich. Auf Pentium-Systemen ist das Argument hinfällig. Was sich auch in Monsteranwendungen wie Word oder Excel zeigt, die mittlerweile einen enormen Bedarf an CPU-Ressourcen entwickelt haben.

APL-Programme sind unlesbar

Dieser Vorwurf beruht auf zwei Mißverständnissen:

In einer Zeile APL passiert im Durchschnitt soviel wie in 30 Zeilen C bzw. 4 Seiten COBOL. Aber die Kritiker erwarten, daß man die APL-Zeile in der gleichen Zeit versteht, die man für das Verständnis einer Zeile C oder gar einer Zeile COBOL benötigt. Kommentar überflüssig.

Im übrigen sind die COBOL-Programme von vor 15 Jahren erheblich unleserlicher, vom technischen Standpunkt ganz einfach wesentlich schlechter, als heutige COBOL-Programme. Gleiches gilt für APL. In APL wird heute ebenfalls auf einem technisch völlig anderen Niveau programmiert als 1990 oder gar 1980.

Selbstverständlich kann man auch heute noch in APL schlechten, unleserlichen Code schreiben. In C und COBOL auch. Und es wird auch getan. Vor allem, weil es wesentlich mehr schlechte als gute Programmierer gibt...

Ein Manager, der eine Seite Code sieht, der in C oder COBOL oder Pascal oder Java geschrieben wurde, denkt: "Ich verstehe es nicht, aber wenn ich Zeit hätte und es verstehen müßte, dann würde ich es auch verstehen!".

Ein Manager, der eine Seite Code sieht, der in APL geschrieben wurde, denkt: "Ich verstehe es nicht. Und ich bin sicher, ich werde es nie verstehen!"

Dabei darf nicht übersehen werden, daß die Befehlswörter klassischer Programmiersprachen ein mögliches Verständnis suggerieren, weil man mit einem Blick Teile im Code entdeckt, die man einordnen kann. Um ein wirklich komplexes Programm zu verstehen, hilft dies jedoch wenig. Hochkomplexe, umfangreiche Programme zu verstehen, die man nicht selbst geschrieben hat, ist auch für sehr gute Programmierer eine schwierige Sache - egal, in welcher Sprache das Programm realisiert wurde.

Hätten diese Manager einmal anhand von Berechnungen etwa der Quantenphysik entscheiden sollen, ob Mathematik in Zukunft eingesetzt werden soll, wäre die Mathematik wohl wegen mangelnder Lesbarkeit gescheitert.

APL-Programme sind nicht wartbar

APL wurde und wird häufig in Bereichen eingesetzt, wo Schnelligkeit alles ist, oder jedenfalls fast alles. Ein typisches Beispiel sind Großbanken, wo Projekte auch schon mal doppelt aufgesetzt werden: die APL-Jungs machen mal schnell was, damit die Händler schon mal unterstützt werden können. Und die C-Jungs programmieren das Ganze dann nochmals "ordentlich".

Was zur Folge hat, daß die C-Projekte häufig gar nicht richtig aus den Startlöchern kommen: weil die Personalressourcen abgezogen werden auf wichtigere Projekte oder weil es das Produkt, das die Händler da gehandelt haben, schon gar nicht mehr gibt(!), wenn die C-Jungs fertig sind.

Der Zeitdruck aber, der bei der Realisierung der APL-Anwendung herrschte, führt selbstverständlich nicht zu wartbarem und fehlerfreiem Code. Man muß Prioritäten setzen: Entweder ist höchste Schnelligkeit das oberste Gebot - oder die Erstellung einer robusten, wartbaren Anwendung. Beides zugleich kann man nicht haben, die Ziele schließen sich gegenseitig aus.

Da APL traditionell vor allem da eingesetzt wird, wo es auf Schnelligkeit ankommt, entstehen dort auch entsprechende Anwendungen. Dies ist kein Mangel von APL, es ist eine Konsequenz der vorgegebenen Prioritäten.

APL unterstützt wegen fehlender Kontrollstrukturen keine strukturierte Programmierung

Stimmt. Früher. Sowohl Dyalog-APL als auch APL/Win und APLX bieten heute alle wichtigen Kontrollstrukturen. Obwohl Kontrollstrukturen in APL eine geringere Bedeutung haben als in anderen Sprachen (weil Schleifen sprachbedingt erheblich seltener verwendet werden), hat sich ihre Einführung als ganz wesentlicher Fortschritt herausgestellt: APL-Programme mit Kontrollstrukturen sind besser lesbar als solche ohne Kontrollstrukturen.

Das heute übliche "Syntax-Coloring" stellt einen weiteren großen Fortschritt in Sachen Lesbarkeit und Wartbarkeit dar. Durch farbliche Unterscheidung kann man im Editor jetzt mit einem Blick erkennen:

  • wo reservierte Wörter (Kontrollstrukturen!) verwendet werden
  • wo Systemfunktionen und -variable verwendet werden
  • wo globale Variable angesprochen werden
  • wo lokale Variable angesprochen werden
  • wo Konstanten verwendet werden
  • wo Kommentare stehen
  • wo APL-Befehle stehen
  • wo syntaktisch inkorrekte Anweisungen verwendet wurden(!)

APL kann nicht mit der "Außenwelt" verbunden werden

Falsch. Dyalog-APL wie APL/Win und APLX können beide sowohl als OLE-Client wie als OLE-Server eingesetzt werden. Mit beiden können ActiveX-Module verwendet werden. Beide beherrschen DDE. Beide können über ODBC oder Verwendung von DLLs jede übliche Datenbank "anzapfen", wobei insbesondere relationale Datenbanken hervorragend mit APL zusammenarbeiten: SQL ist, wie APL, eine nicht-skalare Programmiersprache!

Alle APL-Interpreter "verstehen" TCP/IP. Alle erlauben es, beliebige DLLs direkt zu verwenden. Alle haben eine definierte Schnittstelle für den Aufruf von Modulen bzw. Programmen, die in anderen Sprachen erstellt wurden.

Dyalog APL und APLX haben beide die Systemfunktion []XML implementiert, mit der APL Arrays in XML in beide Richtungen umgewandelt werden kann.

Dyalog APL/W gehört sogar zum exklusiven Kreis der Microsoft-zertifizierten .NET-Sprachen.

APL bietet keine moderne Entwicklungsumgebung

Falsch. Sowohl Dyalog-APL als auch APL/Win wie APLX verfügen über hoch entwickelte Editoren und Debugger. Kontrollstrukturen werden farblich hervorgehoben und automatisch eingerückt. Breakpunkte, in APL Stopvektoren genannt, können mit einem Mausklick gesetzt und entfernt werden. Ein Explorer erlaubt rasches suchen und ersetzen.

APL eignet sich nur für mathematische Anwendungen

Richtig ist, daß APL als mathematisch orientierte Sprache sich für Mathematiker sicher besonders eignet. Tatsächlich wird APL bei Statistikern zum Zwecke der Datenanalyse gerne eingesetzt, und auch in der Versicherungsmathematik ist APL verbreitet. Daraus folgert nun aber nicht, daß APL auf solche Anwendungen beschränkt ist.

APL-Anwendungen können keine modernen GUI`s nutzen

Überholt. Seit Dyalog Anfang der Neunziger das erste APL mit echter GUI-Anbindung vorgestellt hat, haben die beiden führenden Interpreter alle Neuerungen sehr schnell implementiert. Heute können problemlos APL-Anwendungen realisiert werden, die sich äußerlich durch nichts von Anwendungen unterscheiden, die in C++ oder Delphi oder was auch immer realisiert wurden.

Die APL-Sonderzeichen erschweren den Einsatz von APL aus technischen Gründen

In der Tat war dies in der Vergangenheit ein Problem. Aber heute sind die Zeiten vorbei, wo man eine spezielle Hardware für den APL-Zeichensatz brauchte - heute reicht die Installation eines APL-Zeichensatzes. Ohnehin gilt dies nur für den Arbeitsplatz, an dem programmiert wird. Für den Anwender ist der APL-Zeichensatz nicht notwendig.

APL ist langsam

APL ist langsam, wenn es sich um einzelne "Datenteilchen" kümmern muß, weil es sich als interpretierende Sprache dann von seiner schlechten Seite zeigt. Auf einem 80486 war es deshalb problematisch, einen in APL geschriebenen KeyPress-Handler einzusetzen, der bei jedem Tastendruck ausgeführt wird. Auf Pentium-Maschinen ist selbst dies kein Thema mehr.

APL ist aber ausgesprochen schnell, wenn es große Datenmengen mit einem Schlag verarbeiten kann - weil die intern notwendigen Schleifen dann in hoch spezialisierten Routinen ablaufen. Das ist auch der Grund, warum APL-Programme, angewendet auf große Datenmengen, so manches C-Programm in der Laufzeit ausstechen - das C-Programm muß dann erst getunt werden, um gleichzuziehen oder sich einen kleinen Vorteil zu sichern...

APL ist nicht objektorientiert

Seit 2005 bietet Dyalog APL die Möglichkeit, objektorientiert zu programmieren, seit 2008 auch APLX.

Es gibt zu wenige APL-Programmierer

Das ist etwas dran. Aber mit dem Argument müßten wir die Entwicklung neuer Programmiersprachen per definitionem ablehnen - es kann dafür ja keine Programmierer geben. Und ich kenne auch keine Firma, die den Einsatz von SAP mit der Begründung ablehnt, es gebe dafür zu wenige Fachleute - obwohl dies über viele Jahre in der Tat so war!

Wenn man APL-Programmierer benötigt, bildet man halt welche aus: APL läßt sich schnell erlernen, jedenfalls im Vergleich mit anderen Programmiersprachen.

SimCor, Marktführer für Portfolio-Verwaltungssoftware, hat in den letzten 15 Jahren ein rasantes Wachstum vorgelegt. Stand 2010 arbeiten für die Firma über 1.000 Mitarbeiter, davon 160 APL-Programmierer. Die weitaus meisten hat SimCorp selbst ausgebildet.

Was bleibt, sind die Vorteile: Ein enormer Geschwindigkeitsvorteil bei der Programmerstellung bei großer Zufriedenheit der Programmierer bedingt durch die hohe Produktivität. Diesen Punkt sollte man nicht unterschätzen, die Motivation der Mitarbeiter ist schließlich für deren Leistungsfähigkeit und Einsatz ganz wichtig.

Und wenn dem APL-Programmierer genügend Zeit für ein sorgfältiges Design der Anwendung gegeben wird, entstehen zudem auch Programme, die ausgesprochen wartungsfreundlich sind.

Hier einige Beispiele für die Mächtigkeit von APL:

Kai Jaeger in 2014

© Kai Jaeger http://www.kai-jaeger.de Email: kai@kai-jaeger.de Impressum Letzte Änderung: 2005-05-14