Gerade ältere Semester tendieren dazu, APL’s Kinderkrankheiten zu überschätzen, weil sie ihre Erfahrungen mit APL in den Siebzigern oder Achtzigern sammelten.

Die gängigsten Irrtümern möchte ich hier klären.

Das war mal ein Argument.

Man glaubt das ja nicht mehr.

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.

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.

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. Reguläre Ausdrücke sind ein ein weiteres Beispiel.

APL wurde und wird häufig in Bereichen eingesetzt, wo Schnelligkeit in der Entwicklung alles ist, oder jedenfalls fast alles.

Ein typisches Beispiel sind Großbanken, wo Projekte auch schon mal doppelt aufgesetzt werden: die APLer machen schnell was, damit die Händler schon mal unterstützt werden können.

Und die C-Programmierer machen 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 zugunsten wichtigerer Projekte. Ich habe auch erlebt, dass es das Produkt, das die Händler da gehandelt haben, gar nicht mehr gab(!), wenn die C-Jungs fertig waren.

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.

Stimmt. Früher.

Sowohl Dyalog-APL als auch APL/Win bieten heute alle wichtigen Kontrollstrukturen.

Kontrollstrukturen haben in APL eine wesentlich geringere Bedeutung als in anderen Sprachen weil…

  • Schleifen sprachbedingt erheblich seltener verwendet werden.
  • APL-Funktionen wesentlich kürzer sind.

Dennoch hat sich ihre Einführung als Fortschritt herausgestellt: APL-Programme mit Kontrollstrukturen sind oft besser lesbar als solche ohne Kontrollstrukturen.

Das heute übliche “Syntax-Colouring” stellt einen weiteren 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 syntaktisch inkorrekte Anweisungen verwendet wurden(!)
Dyalog-APL wie APL/Win 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 bietet die Systemfunktion []XML, 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.

Sowohl Dyalog-APL als auch APL/Win 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.

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.

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.

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, 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.

Schon auf Pentium-Maschinen war dann 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…

K (und sein Ableger Q) sind ebenfalls Sprachen der APL-Familie, und werden in der Finanzindustrie wegen ihres enormen Geschwindigkeitsvorteils gegenüber z.B. C-Pogrammen akzeptiert und in Big-Data-Anwendungen eingesetzt.

Da 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.

Ich kenne übrigens 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.

SimCorp, Marktführer für Portfolio-Verwaltungssoftware, hat in den letzten 20 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.