APL

Beim Stöbern durch uralte CW-Artikel, die die drei Buchstaben "APL" in dieser Reihenfolge beinhalten, habe ich einen Lobgesang von IBM auf APL gefunden - aus dem Jahre 1980. Das passiert denen heute bestimmt nicht mehr. Hier die Höhepunkte:

"Das heutige IBM-Angebot setzt die Kendallsche Tradition (erheblich erweitert) fort; APL - A Programming Language - ist immer dabei."

Das waren noch Zeiten! Good old Big Blue.

"Das allgegenwärtige APL, einsetzbar auf /370-, 43XX- und 303X-Systemen, offeriert IBM als "klare Sprache"; denn "die Integration aller Benutzer innerhalb eines Unternehmens erfordert" eben eine solche."

In Sachen "klare Sprache" in Sinne von klarer, mathematischer Struktur bin ich da ganz auf Seiten der IBM von 1980. Für die IBM der Gegenwart ist Java die "klare Sprache". Welch ein Fortschritt: Tausende Programmierer, die Tonnen von buggy Spagetti-Code produzieren. Klar ist hier nur, dass diese Codemassen jeden Fortschritt in der Hardware kompensierten.

Meine alten APL-Funktionen performen inzwischen fast so schnell wie das Licht. Hier kann ich Ernte der Realisierung des "Moorschen Gesetzes" einfahren, nicht so bei Word und Konsorten (ich sollte hier DB2 explizit aus der Kritik heraus halten). APL ist kompakt, Java ist objektorientiert, C ist weder das eine noch da andere.

Weiter im Text mit Staunen:

Auf der Suche nach meinem ersten APL-Buch habe ich einige sehr alte CW-Artikel zu APL gefunden. Ende 1981, wahrscheinlich im November, lieh ich mir zur Vorbereitung auf meinen Job als Systemanalytiker "APL 1" von Wolfgang Janko in der UB Düsseldorf aus. Das Buch musste ich natürlich wieder zurückgeben, den gelesenen Stoff habe ich behalten.

Das Buch habe ich in der Zwischenzeit nicht mehr in der Hand gehabt. Nach 25 Jahren meine ich, dass es mir fehlt. Also googlete ich nach "Janko APL" und fand einen CW-Artikel aus dem Jahre 1982. APL und 1982, da war doch was? Tatsächlich tanzte in diesem Jahr der APL-Kongress in Heidelberg und Janko war der Vortänzer. In besagtem Artikel kamen also anlässlich dieses Ereignisses einige Mitglieder des Organisationskommitees zu Worte.

Und dabei kamen interessante Aussagen heraus. Ich zitiere aus dem CW-Artikel "APL als Sprache für Manager entdeckt", übrigens ein Titel, der zum Lästern geradezu auffordert.

"APL, benannt nach dem vor 20 Jahren erschienenen Buch "A Programming Language" von Kenneth E. Iverson, hat nach Überzeugung der Kongreßveranstalter Zukunft."

Das können wir heute nach 24 Jahren beurteilen. Ich bin überzeugt, dass APL immer noch eine Zukunft haben müsste, wenn die IT-Menschheit einigermaßen vernünftig strukturiert wäre.

Das habe ich nun davon, dass ich mich nicht an eine sinnvolle Empfehlung zur Benutzung von Windows gehalten habe. Hätte ich mich aber daran gehalten, wäre ich nicht auf dieses seltsame Verhalten von DB2 gestoßen.

Meinen vorherigen Rechner "Number9" habe ich ausschließlich den User "Administrator" benutzt. Dies habe ich inzwischen für meinen aktuellen Rechner geändert. Auf unseren Linux-Systemen arbeite ich schließlich auch nicht standardmäßig als "root". Number9 hat natürlich auch ein DB2, seit Kurzem sogar in zwei unterschiedlichen Versionen. Da ich mich normalerweise unter meiner Windows UserID auch bei DB2 anmelde, habe ich mich wohl nie explizit mit UserID und Passwort mit einer Datenbank verbunden ("connect to ...") - weder über das DB2-Befehlsfenster, noch über den AP127 mit APL2. Ich bin nun mal schreibfaul.

Nun geschah es aber letzte Woche, dass DB2 von mir UserID und Passwort haben wollte (da ich mich mit dem zweiten DB2-Exemplar als entfernte Instanz verbinden wollte). Der

connect to apl2lib9 user Administrator

im Befehlszeilenprozessor funktionierte klaglos. Aber der Connect über AP127 zickte: Nach

CTL127←'CONNECT' 'APL2LIB9' 'Administrator' PASSW

beschwert sich AP127 mit einem(1 0 0 1 162): "THE USERID ARGUMENT TO CONNECT MUST BE A CHARACTER VECTOR OF LENGTH 1 TO 8".

Ted Codd mag zwar Anfang der 90er den Begriff OLAP (Online Analytical Processing) kreiert haben, aber er hat damit nicht die mehrdimensionale Speicherung und Analyse von Daten erfunden.

Dies geschah lange bevor Codds meinte, die Computerwelt mit seinen komischen 12 OLAP-Regeln beglücken zu müssen.

1998 schrieb Mark Hammond in der PC Week unter dem Titel "It's not Greek to me":

OLAP has its roots in a multidimensional language called APL, developed in 1962, that used Greek symbols and ran on IBM mainframes.

Für einen APLer war und ist das Denken in und das Arbeiten mit multidimensionalen Strukturen selbstverständlich. Von daher haben wir den Hype um OLAP nie so recht verstanden. Wir hatten ja schon lange alles, was OLAP angeblich ausmacht, und noch vieles mehr.

Anbieter von OLAP-Software können noch viel von APL lernen. Nur die Speicherung von dünn besetzten Würfeln ist bei den meisten OLAP-Systemen effizienter gelöst.

Das Highlight des letzten APL2 Release (CSD 8) ist definitiv der APL2 Library Manager. Wieder ein Tool, das dem APL2 Workaholic viel Zeit spart. Es spricht für die sachliche Bescheidenheit der Entwickler, dass sie diese Erweiterung nur kurz und knapp aus einer rein technischen Perspektive beschreiben. Wer es lieber deutsch mag, schlage bei DPC nach.

Seitdem hat mir der APL2LM schon oft das APL2-Leben erleichtert.

Ich habe tatsächlich verschiedene Versionen eine Workspaces vergleichen. Das ist an und für sich nichts Neues. Es gab ja schon vor dem APL2LM den 1 WSCOMP. Mit dem APL2LM muss ich dazu nicht extra eine Workspace laden.

Und hier liegt der eigentliche Gewinn, den ich durch den Library Manager habe. Wenn ich mal schnell in einem Workspace etwas nachschauen will, brauche ich diesen nicht mehr zu laden. Dazu stelle man sich folgendes vor:

APL und Virtuelle Maschine hat einen neue Bedeutung bekommen. Aber zuerst habe ich Bernd für diesen interessanten Tipp zu danken. Interessant und beachtenswert, oder gar mehr?

Wenn ich Virtuelle Maschine bis vor einigen Jahren gehört habe, dachte ich gerne an das gute alte IBM VM zurück. Ein Betriebssystem, auf dem man mehrere und verschiedene Mainframe-Betriebssysteme parallel fahren konnte. VM gaukelt den Gastsystemen ihre Hardware nur vor. VM ist inzwischen leider Geschichte, wie viele guten Dinge aus dem Hause IBM.

Daher ist VMware keine Erfindung der 90er. VMware macht unter Windows oder Linux das, was VM auf IBM Mainframes tat. Also keine neue Idee, nur eine andere Plattform, aber das alleine war schon eine gute Idee.

APL läuft natürlich unter beidem, VM und VMware, denn es gibt APL-Implementierungen für MVS, CMS, Windows und Linux (und viele mehr).

Dann gibt es da ja noch die berühmte Java Virtuelle Maschine, eine Erfindung der 90er. Die gaukelt niemanden was vor, zumindest keine Hardware. Die verschiedenen systemabhängigen JVM-Implementierungen gleichen aus Sicht des Java-Entwicklers plattformspezifische Unterschiede aus. Als Java-Programmierer produziere ich damit nur noch plattformunabhängigen Bytecode.

Dies ist auch die Idee hinter "Parrot":

"Parrot is a virtual machine designed to efficiently compile and execute bytecode for interpreted languages"

Und APL ist eben ganau solch eine interpretierte Sprache. APL ist sogar einer der ältesten Interpreter, nur etwas jünger als Basic. APL wird Ende November 40.

Doch zurück zu Parrot.

UNIQUE ist nicht die einzige Neuerung der Version 6.2. Da gibt es noch vier weitere bemerkenswerte Dinge:

⎕MOM-Objekte enthalten jetzt ⎕FX als Methode zur Erstellung einer Funktion in einem Objekt. So wird mit

mom_obj.⎕FX cr

die Zeichenmatrix cr zu einer Funktion innerhalb des Objekts mom_obj erhoben.

)OUTPUT wurde bereits mit Version 6.0 eingeführt und erhält in Version 6.2 mit STRICT eine weitere Option. Sowohl )OUTPUT ERROR als auch )OUTPUT STRICT sind sinnvoll, um nicht gewollte implizite Ausgaben in Funktionen aufzuspüren.

)OUTPUT STRICT ist eine Verfeinerung von )OUTPUT ERROR. Bei dieser Option wird nur dann ein "IMPLICIT OUTPUT" Error ausgeworfen, wenn eine sichtbare implizite Ausgabe produziert wurde. Die Fehlermeldung erscheint nach der Ausgabe.

APL+Win hat mit der Version 6.2 eine neue Grundfunktion spendiert bekommen: UNIQUE. Damit einher geht auch die Notwendigkeit für die Belegung eines Symbols. Das ist typisch für APL. Es ist nicht gerade überraschend, dass für UNIQUE "Cup" ∪ gewählt wurde.

Syntaktisch ist ∪x äquivalent zum Unique-Idiom:

((x⍳x)=⍳⍴x)/x

Also: rechtes Argument ist ein beliebiger Vektor. Das Ergebnis ist wiederum stets ein Vektor, der alle unterschiedlichen Element des rechten Arguments enthält in der Reihenfolge ihres ersten Auftretens.

Die Implementierung von UNIQUE scheint keine Performance-Vorteile im Vergleich zum Idiom zu bringen. Der Vorteil der Nutzung liegt also alleine in der bequemeren Schreibweise.

Ich halte das für ausreichend, um ∪ statt des Idioms zu nutzen.

Sowohl UNIQUE als auch das Idiom sind vergleichsweise sehr langsam für Floating Point Argumente. Das liegt wohl daran, dass hier jeweils zur Bestimmung von Gleichheit ⎕ct herangezogen werden muss.

Kaum ist die Version 6.0 raus und verfügbar, schon gibt es ein Upgrade. Das ist gut und nicht schlecht. Denn die Version 6.2 enthält einige interessante Neuerungen und Erweiterungen.

APL+Win 6.2 ist verfügbar für Kunden mit einer APL+Win 6.0 "Subscription", das ist eine Lizenz zum Upgraden. Eine Vollversion soll demnächst angeboten werden.

Die erste Neuerung ist die UNIQUE-Grundfunktion. Für mich eine freudige Überraschung. Das ist eine sehr nützliche Spracherweiterung!

Wie die neue Grundfunktion aussieht und wie sie funktioniert lässt sich aus der Ankündigung nicht ersehen. Genauso wenig wie Details zu den weiteren neuen Features:

"The implementation of ⎕FX for ⎕MOM object system objects.

The new ")OUTPUT STRICT" state that only produces "IMPLICIT OUTPUT"
errors when visible output is generated.

The new Zip class for ⎕wi that will allow zipping and unzipping of files.

The new Session Manager printer margin settings."

Spannend und bestimmt nützlich ist auch die Unterstützung für zip.

Also werde ich auf 6.2 upgraden.

Wohl dem, der eine "Subscription" hat.

Mit der Version 6.0 unterstützt APL+Win nun auch Unicode-Daten.

Dies hatte ich in meinem Blog-Eintrag zu den Neuerungen dieser Version nicht erwähnt - aus zwei Gründen: Die Unterstützung ist noch nicht vollständig und ich hielt den Bedarf hier im Lande für nicht so gravierend. Falsch, letzteres ist falsch. Also Schade über mein Haupt. Ich gelobe Besserung.

APL2000 schrieb zur Unicode-Unterstützung

Initial Support for Unicode Character Data
⎕UCS system function supports a 32-bit Unicode character data representation. Initially support is provided for some primitives and planned for others and the other primitives yield the appropriate NONCE or DOMAIN error messages.
Unicode character data displayed in the Session Manager will be shown as <<<UCS Characters>>>.
The ⎕WI interface with Windows has been enhanced to interchange Unicode character data with ActiveX controls. The unicodebstr property has been added to control this behavior.

Auf den DPC-Seiten findet man

Unicode-Unterstützung
APL+Win V6 bietet erstmals eine Unterstützung für Unicode-Daten. Die Unterstützung von Unicode ist noch nicht in vollem Umfang implementiert und soll in späteren Releases weiter ausgebaut werden. Zunächst unterstützen nur die APL-Funktionen JOIN bzw. RAVEL (,⍪), SHAPE bzw. RESHAPE (⍴), PICK (⊃), ENCLOSE (⊂) und FIRST (↑) diesen Datentyp.
Eine neue Systemfunktion ⎕UCS dient zur Erzeugung von Textvektoren aus Unicode, ⎕DR wurde um den Datentyp 322 für Unicode-Textvektoren erweitert.

An diesem Text hatte ich noch selbst rumkorrigiert.

Mein erster Einwand bleibt richtig: Die Unterstützung ist noch nicht vollständig. Schön ist, dass APL+Win die gleiche Systemfunktion für die Konvertierung von und zu Unicode-Zeichen verwendet wie APL2.

Im Vergleich zur Darstellung von Umlauten in einem Grid ist die Situation bei Listviews komplexer. Das Wesentliche vorweg: Auch hier gibt es Unterschiede zwischen CSD 8 und CSD 7 (und früher).

Betrachten wir zuerst Schriftarten, die keine APL-Zeichen enthalten, also z.B. MS Shell Dlg, MS Sans Serif oder Tahoma. Sollten mit CSD 7 Umlaute auch als solche in einem Listview dargestellt werden, mussten sie vorher z.B. durch APL2_TO_WINDOWS umgesetzt werden. Mit CSD 8 sollte man das nicht tun, denn sie werden bereits ohne Umwandlung korrekt angezeigt.

Unicode-Fonts enthalten zwar APL-Zeichen, verhalten im Vergleich von CSD 7 und CSD 8 wie Schriftarten ohne APL-Zeichen.

Mag sein, dass der Computer nicht ausschließlich in den USA erfunden wurde, aber die EDV- bzw. IT-Standards wurden eben dort in den letzten Jahrzehnten gesetzt. So auch die Zeichensätze, seien es ASCII oder EBCD. Und was dort nicht bekannt war, floss eben nicht in die Definitionen ein.

Dazu gehören leider auch unsere Umlaute und das Eszet. Nach nun mehr als 30 Jahre Arbeit mit Computern befürchte ich, dass wir allgemein länderspezifische Sonderzeichen immer noch nicht im Griff haben (Unicode lässt grüßen). Das fällt diesmal beim Wechsel von APL2 CSD7 auf CSD 8 auf, zwar nur marginal, aber immerhin:

Die Darstellung der Umlaute in einem APL2-Grid war schon immer abhängig vom gewählten Zeichensatz. Sie wurden korrekt ausgegeben, soweit der Zeichensatz der Wahl z.B. "APL2 Image" war, bei anderen wurden Umlaute erst als solche angezeigt, wenn sie vorher z.B. durch APL2_TO_WINDOWS (aus 2 WINDOWS) umgewandelt wurden.

Dies gilt auch fast so für die CSD 8, aber nur fast: Den Unterschied macht die Schriftart MS Sans Serif. Das ist der Font, der verwendet wird, soweit kein spezieller Font spezifiziert wurde. Schickt man nun Umlaute vorher - wie bei früheren Releases nötig - durch APL_TO_WINDOWS, so werden im Grid irgendwelche Zeichen ausgegeben, aber keine Umlaute.

Nach dem Start von APL2 sind werden sofort und automatisch zwei Shared Variables deklariert. Dies kann man mit dem APL2 SVP Monitor gut beobachten:

Entweder die apl2svpt.exe im APL2 bin-Verzeichnis ausführen oder - seit CSD 8 - den Monitor einfach durch Klick auf das "APL2 SVP Monitor"-Symbols in der Werkzeugleiste aktivieren. Dort findet man unter Info/Processors die mit APL2 gestarteten Partnerprogramme: den Session-Manager (AP120), den Interpreter (AP1), den Stacksprozessor (AP101) und die ID der Sitzung.

Schaut man sich die gemeinsamen Variablen zu diesen Prozessoren an, so sieht man, dass bereits zwei Variablen zwischen dem AP120 und dem AP1 deklariert wurden: AP120_SIGNAL und APL2. Öffnet man ein APL2-Objekt in den Object Editor, so gesellt sich als dritte Variable AP120_EDIT hinzu.

Über die Variable APL2 beschickt der Session Manager den APL2-Interpreter mit allen möglichen APL2-Anweisungen und Kontrollsignalen. Im Gegenzug erhält die Variable APL2 vom Interpreter das Ergebnis der Ausführung der Anweisung bzw. Informationen über aufgetretene Fehler.

Es geht aber auch ohne den Session Manager. Jedes beliebige selbst geschriebene Programm kann über das APL2 SVP Programming Interface die Variable APL2 ansprechen. Sobald der Interpreter als AP 1 ein Angebot für eine gemeinsame Variable namens APL2 erhält, wird dieses auch akzeptiert und der Interpreter erhält seine Anweisungen von jenem Programm.

So kann jeder, der der C-Programmierung mächtig ist seinen eigenen Session Manager schreiben. Ich kann mir aber kaum vorstellen, das dies irgend jemand ernsthaft tun würde.

Die Kommunikation mittels der Variablen APL2 mit dem Interpreter wird im User's Guide unter der Überschrift "Shared Variable Interpreter Interface" ab Seite 120 beschrieben. Das "SVP Programming Interface" ist dort wird ab Seite 604 dokumentiert.

Dies geht nur mit "vernünftiger" Software:

Bisher hatte ich keine Probleme APL2 Sessions mit verschiedenen CSD-Levels auf meinem Rechner zu fahren, und das sogar parallel.

Sicher ist sicher, daher speichere ich bei jedem APL2-Upgrade auf einen neuen CSD-Level den alten Stand in ein eigenes Verzeichnis. So ist zur Zeit die aktuelle CSD8 unter "[...]\ibmapl2w" abgelegt, den vorherigen Stand hatte ich nach "[...]\ibmapl2w CSD7" kopiert. Dass dies keine Probleme bereitet, ist selbstverständlich.

Ich kann nun mit oder ohne Batch-Dateien nacheinander, aber auch parallel, die jeweiligen apl2win.exe starten. Die "Beginning Session"-Meldung bestätigt mir den erwarteten CSD-Level. Bisher konnte ich so problemlos parallel mit CSD7 und CSD8 arbeiten. Und das ist nicht selbstverständlich.

Auch APL2 bedient sich, wie fast jede Software unter Windows der Registry. Das scheint aber so unkritisch zu sein, dass es bisher zu keinem offensichtlichen Versionskonflikt kam.

Daher kann ich immer mal wieder die Änderungen von CSD7 zu CSD8 auf meinem Rechner parallel darstellen.

Der APL2 Object Editor ist ein eigenständiges Programm und kommuniziert mit dem Session Manager über das Shared Variable Interface. Doppelklick auf einen Funktionsnamen bedeutet, dass die Funktion über eine Shared Variable (AP120_EDIT) an den Editor geschickt wird und dort in einem eigenen Fenster angezeigt wird.

Aber was heißt hier "die Funktion"?

Nach den Problemen, die wir mit dem Editieren einer gigantischen Funktion hatten, kann man davon ausgehen, dass die besagte Funktion in ihrer Character Representation verschickt wird. Alleine der Versuch diese Funktion, deren CR größer als 12 MB ist, in den Editor zu klicken, schlägt mit der Meldung "System Limit - Interface capacity" fehl. Erhöhung des Wertes für MAXSV auf 13 MB führt zumindest dazu, dass die Funktion ordentlich im Editor angezeigt wird.

Die CR einer Funktion zu transferieren bedeutet im vorliegenden Fall. extrem viele irrelevante Leerzeichen durch den Kanal zu schieben. Diese werden zum Auffüllen der Zeilen auf die Länge der längsten Zeile - hier der 6 KB langen Kopfzeile - produziert. Lässt man diese nichtssagenden Blanks außer Acht, ist die Funktion nur noch knapp 100 KB groß. Eine solche offensichtlich wesentlich sparsamere Darstellung einer Funktion erhält man mit 2 ⎕TF, einer Darstellung, die auch von )OUT benutzt wird.

Warum wird also die CR durch den Kanal zum Editor geschoben?