APL

Keine Angst vor der Übergabe großer Variablen als Argument einer Funktion! Es ist nämlich nicht so, dass sich nach Aktivierung der Funktion der Inhalt des Arguments gleich zweimal im Arbeitsspeicher ausbreitet. Statt eine Kopie anzulegen speichert APL nur einen Pointer.

Das spart Platz, aber nur solange bis in der aufgerufenen Funktion das Argument selbst modifiziert wird. Selbst die kleinsten Änderung (z.B. (↑Arg)←0 ) bewirkt eine umgehende Erstellung einer Kopie der ursprünglichen Variablen.

Das Gleiche gilt für ganz einfache Zuweisungen der Form C←B, selbst wenn B bereits nur einen Pointer zu A darstellt. Und was passiert nun mit dieser verpointerten Kette, wenn A bzw. B modifiziert wird?

Ich meine den Zeitstempel für die letzte Änderung einer Funktion oder eines Operators, also die "Fix Time". Die Antwort ist doch ganz einfach und auch keine 500€ wert: 2 ⎕AT FOOname liefert als Ergebnis einen 7-stellingen ganzzahligen Vektor mit Datum und Uhrzeit des letzten "Fix".

Nein, das wäre zu einfach. Die Frage geht nach der Stelle, wo diese Angaben in der APL-Datei abgelegt sind, also der Datei, die den gespeicherten Workspace enthält.

Wer suchet, der wird was finden, so auch hier. Nun habe ich das gestern bereits das vierte Mal durchexerziert. Es ist also Zeit, das endlich niederzuschreiben. Hier die Erkenntnisse:

Was war es doch schwierig. Jahrelang, nein sogar jahrzehntelang, haben APLer sich den Kopf darüber zerbrochen, wie sie ihre Funktionen (oder Operatoren) vernünftig drucken bzw. ausserhalb des jeweiligen APL-Systems als Textdokument darstellen oder bearbeiten können. Ich erinnere mich da an Begriffe wie Codepages, APL-fähige Drucker, Druckertreiber, Schriftarten ...

Und tatsächlich, es gibt ihn: den Fortschritt in der Computerei. Heute kann ich einfach per Mausklick eine APL2-Funktion als PDF-Dokument darstellen, und das sogar in Farbe.

Ich benötige dazu nur einen "Drucker", der kein Papier beschmiert, sondern PDF-Dokumente erstellt. Dies kann ich z.B. mit FreePDF erreichen.

Damit brauche ich nur im Editor das geöffnete APL2-Objekt auf diesen "Drucker" auszugeben. Ich erhalte eine PDF-Datei mit den "Ausdruck" des Objektes, sogar mit Zeilennummern und farbig- so wie der Editor APL2-Objekte darstellt.

Einfach und schön, einfach schön!

Da kann man lange suchen - kleiner Unterschied, große Wirkung.

So kennt die externe Funktion COM kennt das Kommando "WAIT", und es gibt COM-Objekte mit einer Methode namens "Wait". Dies sollte man nicht verwechseln, es ist mir trotzdem passiert.

Es ist wohl so, dass COM nur Kommandos in Großbuchstaben akzeptiert. So, wie es im Users Guide niedergeschrieben steht. COM 'WAIT' timeout ist ebenso valide wie COM 'PROPERTY' params, "COM 'Wait' timeout" wirft dagegen einen Domain Error aus.

Ich habe lange nach dem Grund für diese Fehlermeldung gesucht, David hat ihn herausgefunden. Glücklicherweise nicht sofort, ich brauche mich also nicht für vollkommen verblödet zu halten.

Bei Eigenschaften und Methoden von COM-Objekten ist die Situation in der Regel entspannter: Ob ich nun z.B. COM 'METHOD' handle 'Wait' param schreibe oder COM 'METHOD' handle 'WAIT' param ist einerlei, ich erhalte in beiden Fällen das erwartete Verhalten.

... das war vor CSD 10 die Frage.

Die Erkennung und Markierung von URLs in Kommentaren hat wohl vielen APL2-Fans nicht so recht zugesagt. Ich kann das nachvollziehen. Es wurden Dinge als URL erkannt, die nie als solche gemeint waren.

In der Regel hätte mich das auch nicht weiter gestört, denn ich lasse einem Doppelpunkt stets eine Leerstelle folgen. Dies widerspricht der Definition einer URL.

CSD 10 bietet nun eine richtige Lösung: Die Markierung von Zeichenfolgen in Kommentaren als HTTP-Link gibt es nun als Option. Im APL2 Objekt-Editor kann unter "Options/System Options" mit "Underline URL" entschieden werden, ob aus dem Editor heraus direkt auf Web-Seiten zugegriffen werden kann.

Als Voreinstellung ist diese Option nicht aktiviert.

Dies ist für alle die beste Lösung: Ein sinnvolles Feature, das bei Bedarf eingeschaltet werden kann.

Das ist nicht die einzige Neuerung der CSD 10. Doch dazu später mehr ...

Gestern hatte ich den Eindruck, eine magische Hand hat eine APL2-Funktion auf meinem Rechner verändert. Wenn überhaupt habe ich diese Funktion seit fast 2 Jahren nicht mehr angefasst, trotzdem fällt sofort eine Änderung ins Auge:

Diese Zeile (deren Inhalt hier unerheblich ist), ein vorher ganz unschuldiger Kommentar, erscheint urplötzlich unterstrichen

⍝LBAR:→(0∊⍴SP←(E_VKDA[⍙VKDA_INH⍳⊂'TANR';]∊2288 2480)/⍳2⊃⍴E_VKDA)/LTHV

Ich war es nicht, aber wer war es dann?

Viele, viele APL2-Fans tragen dafür die Verantwortung. Allen voran Bernd, daneben auch die Teilnehmer einer GSE-Arbeitsgruppensitzung (wovon ich auch einer war) und schließlich David.

Als ich diese Veränderung an einer anderen Stelle von ca. zwei Jahren das erste Mal sah, erinnerte ich mich an ein damals aktuelles GSE-Requirement. Wir hielten Bernds Vorschlag für sinnvoll, in Kommentaren von APL-Funktionen URLs einbetten und verlinken zu können. Damit erhält der APL2-Nutzer die Möglichkeit, aus einer APL2-Funktion heraus sich eine Web-Seite in seinem Standardbrowser anzeigen zu lassen.

Offensichtlich fand auch David die Idee interessant und die Umsetzung nicht zu aufwändig. Mit der nächsten CSD war dieses Feature verfügbar.

Eine unterstrichene Kommentarzeile ist als kein Bug in der Darstellung einer Funktion, sondern ein Feature.

Abstürzende Software ist ärgerlich. Aber das kommt selbst bei den besten Exemplaren dieser Spezies vor. Keine einigermaßen komplexe Anwendung ist fehlerfrei - solange Menschen ihre Finger im Spiel haben. Irren ist eben menschlich. Ich bin gespannt, wann wir endlich in der Lage sind, die Fehlerfreiheit von Programmen maschinell nachzuweisen.

Solange das nicht möglich ist, müssen wir mit allzu menschlichen Fehlern leben. Selbst APL ist davor nicht gefeit. Gerade beim Test neuer Features bringe ich ab und zu eine APL-Sitzung zum Absturz. Es passiert auch schon mal, dass ich durch wochenlange intensive Entwicklung einer APL2-Anwendung den dazugehörigen Workspace zerraspelt vorfinde. Aber stets hilft hier die )clear- )copy - )save - Sequenz.

Das alles kommt so selten vor, dass man getrost APL-Systeme als äußerst zuverlässig und stabil bezeichnen kann.

Auch gängige Anforderungen an die Kompatibilität innerhalb der APL-Versionen eines Herstellers werden zufriedenstellend erfüllt. Selbst eine Migration von APL-Anwendungen auf Vorversionen ist mit den üblichen Einschränkungen möglich.

Ganz anders bei MS Access. Ich habe selten eine Anwendung so schnell wegen simpelster Probleme komplett abstürzen sehen. Es genügte schon, eine mdb mit einem ins leere gehenden Verweis zu übernehmen. Auch bei der Aufwärtskompatibilität von Version 10 nach 11 liegt offensichtlich einiges im Argen.

Ich will nicht wissen, wie viele Entwickler bei Kleinstweich an Access rumentwickeln, es werden garantiert mehr sein als alle Entwickler von APL-Systemen zusammengenommen. Ich kann mich des Eindrucks nicht erwehren, dass in den vorliegenden Fällen die Softwarequalität umgekehrt proportional zur Größe der Programmierteams ist.

Von "Multi-row Fetch" oder "Multi-row Insert" hatte ich bisher nichts gehört, bis mich David fragte mich heute morgen danach fragte. Ein APL2-Fan wünscht sich wohl, dass der AP127 diese DB2-Features nutzt. Recht hat er.

Seit der Version 8 bietet die Programmierschnittstelle der DB2 für z/OS die Möglichkeit, mit nur einem Fetch auf mehr als nur eine Zeile des Resultsets zuzugreifen. Eine sehr sinnvolle Erweiterung, die mit der Version 8.2 dann auch für andere DB2-Plattformen zur Verfügung gestellt wurde. Es liegt wohl nur an der Beschränkheit der Mainstream-Programmiersprachen, dass obwohl ein SQL-Select eine Menge von Tabellenzeilen als Ergebnis ergibt, aber auf Elemente dieser Menge nur einzeln zugegriffen werden kann - Zeile nach Zeile per Schleife.

Für APL mit seiner hervorragenden Fähigkeit, komplette Datenstrukturen verarbeiten zu können, stellt diese Einschränkung eher einen ärgerlichen Logikbruch dar. Nur gut, dass mit dem AP127 per Parameter für den Fetch mehrere Ergebniszeilen mit einer Anweisung zum APL2 übertragen werden können.

Nach nun mehr als 30 Jahren ergab sich die Gelegenheit, mich wieder intensiver mit den Grundlagen der Mathematik zu beschäftigen. Der Mathe-Kurs für Informatiker im ersten Semester erinnert natürlich sehr an des 1.Semester eines Mathematikers: Mengenlehre, ein wenig Algebra, schon mehr Lineare Algebra und natürlich die Anfänge der Analysis.

Für mich ist das mehr als nur eine Wiederholung. Lineare Algebra macht mir heute wesentlich mehr Spaß als zu Beginn meines Studiums. Das gleiche gilt für die Algebra. Meine Zuneigung zu ihr habe ich ja erst im Hauptstudium entdeckt. Dazu war der richtige "Lehrer" nötig.

Heute ist es für mich wesentlich einfacher, mathematische Probleme zu lösen. Das liegt nicht nur daran, dass ich eine komplette Mathe-Ausbildung genossen habe. Ich habe auch noch APL zur Unterstütztung. Die öde Rechnerei zu Fuß ist passe. So ist das Produkt von Matrizen mit der Eingabe von nur fünf Zeichen zu berechnen, die Inverse benötigt gar nur zwei. Und das ohne jegliche eigene Programmierung.

Ebenso wenig stellt die Berechnung von Eigenwerten und -vektoren eine zeitraubende Aufgabe dar. APL hilft dem Mathematiker sich mit den wesentlichen Dingen zu beschäftigen.

Es war im Frühjahr 2005, vor etwas weniger als zwei Jahren. David arbeitete an der COM-Schnittstelle für APL2 und ich durfte sie hier und da testen. Parallel arbeitete ich an einem Vortrag für die kommende Tagung der GSE APL2-Arbeitsgruppe. Irgendwie schien es nahe liegend, in den Vortrag helfend die MS Agents einzubeziehen.

Die Idee war nicht neu: Im Mai 1999 hatte ich mir von Merlin und Konsorten einige Erklärungen zu dem damals neuen APL2-Runtime Feature (das es inzwischen so auch nicht mehr gibt) abnehmen lassen. Zur Programmierung der Agents bot sich damals VBA unter Powerpoint an, obwohl ich auch APL+Win hätte nehmen können - APL2 dagegen nicht.

Ich versuchte vor zwei Jahren also, die Szenarien, die ich 1999 in VBA entwickelt hatte, mit APL2 und der neuen COM-Funktion nachzubauen. Das klappte erwartungsgemäß auch ohne prinzipielle Probleme. Nur zwei Dinge konnte ich nicht wie gewünscht umsetzten:

"Bookmarks" waren nicht umsetzbar, "Housekeeping" erst nach Ende einer Szene nur händisch oder durch Setzen von ⎕DL. Der Grund für beides war die damals fehlende Unterstützung für COM-Events.

Und die gibt es inzwischen - seit Service Level 7 - und damit konnte ich mir nun beide Wünsche erfüllen.

So überschrieb Alan Zeichick seinen Blog-Eintrag zu 40 Jahre APL. Für mich ist Alan ein APL-Unbekannter. Nach eigener Aussage hat er Ende der 70er Jahre mit APL gearbeitet. Das kann aber nicht sehr ernsthaft gewesen sein: "I have no idea why we had APL on our System/370; it was never used for anything but fooling around."

Ich habe einige Ideen, wozu er und seine Kollegen hätten APL sinnvoll einsetzen können. Viele haben das ja gerade zu der Zeit getan. Dies ist übrigens auch heute noch eine wahre Aussage - nicht dass jemand jetzt auf die Idee kommt zu meinen, APL sei heute tot. Dem ist glücklicherweise nicht so.

Doch weiter zu Alan's Blog-Eintrag "Amazingly, IBM still sells APL tools today, 40 years later ...". Aber das sollte Dich doch nicht wirklich überraschen, Alan, denn Gutes hält sich ewig.

"You can perform complex calculations with only a few characters; designing algorithms to be concise (and often unreadable) is a marvelous talent." Talent hin oder her, die Fähigkeit, Algorithmen prägnant zu formulieren, ist auch eine typisch mathematische Eigenschaft. APL ist hier genauso lesbar oder unlesbar wie Mathematik. Und diese Präzision, die dem mathematischen Denken inne wohnt, ist Basis für die erstaunlichsten Fortschritte in den letzten Jahrhunderten.

"Sadly, I didn't spend enough time with APL to develop much skill. My "real" work involved PL/1, COBOL and FORTRAN, and noodling with APL was essentially a hobby." Dem kann man nur zustimmen. Tatsächlich ein trauriges Leben als ITler.

Tatsächlich startet Alan's Beitrag zur APL-Geburtstagsparty nicht sonderlich stark. Macht nichts, denn das Ende ist herrlich ("that article" meint den Beitrag zu APL in en.wikipedia.org):

"However, that article merely scratches the surface, and doesn't show the beauty and elegance of APL programming."

Dem ist nichts mehr hinzuzufügen.

Wie gesehen kann der AP127 noch nicht mit dem XML-Datentyp umgehen, er kennt ihn schlicht und ergreifend nicht.

Das bedeutet aber nicht, dass jedes SQL-Statement, in dem XML-Daten angefasst werden, zwangsläufig zu einem AP127-Fehler führt. Solange das Ergebnis einer Query keine Daten vom Typ XML (988) enthält, ist alles gut.

Hierzu ein Beispiel mit der Tabelle XMLCUSTOMER:

select c.cid from xmlcustomer c where xmlexists(''$i/customerinfo[name = "Kathy Smith"]' passing c.info as "i")

XMLEXISTS ist ein neues Prädikat. Es prüft, ob ein XQuery-Ausdruck ein nicht-leeres Ergebnis bringt. Im Ergebnis der Query selbst tauchen dagegen nur die Integer-Werte der Spalte CID auf.

Auch diese Query verleitet den AP127 nicht zu einer Fehlermeldung:

select X.* FROM XMLCUSTOMER C, XMLTable(''$cu/customerinfo'' PASSING C.INFO as "cu" COLUMNS "NAME" CHAR(20) PATH ''name'', "STREET" CHAR(20) PATH ''addr/street'', "CITY" CHAR(20) PATH ''addr/city'') AS X

Denn die Tabelle X enthält nur dem AP127 bekannte Datentypen. Dass in der Query irgendwo XML-Dokumente verarbeitet werden, bekommt er nicht mit. Gut so!

Nichtdestotrotz wäre es mehr als sinnvoll, den AP127 mit dem Datentyp 988 vertraut zu machen.

Eines der herausragenden neuen Features der neuen DB2-Version ist der XML-Datentyp und die daraus resultierende Möglichkeit, komfortabel mit XML-Dokumenten in DB2 zu arbeiten.

Nun besitzt APL2 mit dem AP127 eine direkte Schnittstelle zu DB2, ohne Umwege über Interfaces wie ODBC. Nachdem ich auch auf diesem Rechner DB2 9 installiert habe, hat es mich geradezu in den Fingern gejuckt, mal auf XML-Daten von APL2 aus zuzugreifen.

Das Ergebnis zeigt, dass noch Einiges zu tun ist. Dazu ein erstes Beispiel:

Ich nehme die Tabelle XMLCUSTOMER aus der DB2 Sample-Datenbank. Sie hat zwei Spalten, CID und INFO. CID ist vom Typ Integer, INFO vom Typ XML.

Ein einfaches 'Select * from XMLCUSTOMER' mittels AP127 ergibt einen AP2X127105 "SQL DATATYPE 989 (COLUMN INFO) NOT SUPPORTED BY AP 127". Das ist nicht wirklich überraschend.

Der neue Datentyp muss also dem AP127 noch vorgestellt werden.

"Eine, der Erfahrungen, die ich hierbei machen konnte, besteht in der Erkenntnis, daß das Verständnis von APL höhere intellektuelle Anforderungen stellt als das Verständnis anderer Sprachen."

Das mein Wolfgang Janko, ein veritabler Professor und Buchautor (APL 1, APL 2/I, APL 2/II u.a.). Wenn er das so schreibt, dann muss das wohl stimmen. Also dürfen wir uns getrost als Hoch-Intelligenzler bezeichnen, wenn wir es verstehen mit APL Probleme zu lösen? APL als Messlatte für Intelligenz, gar als Komponente eines IQ-Tests?

Nein, darauf möchte ich mich nicht einlassen. Ich bin allerdings überzeugt, es hilft in Strukturen denken zu können. Ansonsten wird man die Stärken von APL nicht vollständig schätzen können und möglicherweise jede Schleife, die in Basic geschrieben werden muss auch in APL schreiben.

Jankos Erkenntnis stammt aus dem Jahre 1981 und war zu lesen in der Computerwoche als Teil einer Kritik an einen CW-Artikel. Passend der Titel: "Intellektuelle lösen Algorithmen mit APL", eine Aussage, die dem Ruf von APL und seinen Protagonisten sicher nicht zuträglich war.

Es ist nun fast 40 Jahre her, dass das erste mal ein "CLEAR WS" auf einem Rechner angelegt wurde. Jedes IBM-APL erinnert mit dem Pseudo-WS CLEANSPACE (was ist bloß falsch an diesem WS-Namen) an den genauen Zeitpunkt dieses Ereignisse:

)LOAD 1 CLEANSPACE
SAVED 1966-11-27 23.53.59 (GMT+1)

Nun treibt es mich schon seit Monaten um, warum jetzt unbedingt die 40. Wiederkehr dieses Tages gefeiert werden muss. Denn ich habe erst meinen 50. Geburtstag mit großem Brimborium begangen. Zugegebenermaßen habe ich den 30. und den 40. mehr beachtet als die Jahrestage dazwischen.

Rein zahlentechnisch ist die 40 nicht sehr imposant. Sie ist im Dezimalsystem so gut wie die 30, 20 oder 60. Wir dezimal denkenden Menschen (es gibt Menschen, die in anderen Stellenwertsystemen denken) legen ganz gesonderten Wert auf die 50 oder 25 und 75: ein halbes Jahrhundert, ein viertel oder dreiviertel Jahrhundert. Die 40 ist mal gerade ein zweikommafünftel Jahrhundert.

Warum also gerade im Falle von APL den 40. Geburtstag groß feiern? Haben wir Angst, dass wir den 50. nicht mehr erleben? Oder weil wir APLer Zahlen aus der Sicht eines Waschbären betrachten - im Oktalsystem, wegen der 8 Finger, vier an jeder Pfote? Hier sind 40 Dezimaljahre 50 Oktaljahre, also tatsächlich ein halbes Jahrhundert.

Nein, wir sind keine Waschbären. Die Antwort ist natürlich im Computer zu finden: Wir stellen für den Rechner Zahlen gerne und oft im Hexadezimalsystem dar, und da ist unsere dezimal 40 hexadezimal eben die 25, ein viertel Jahrhundert, ein Silberjubiläum.

Es gibt Leute, denen wäre das alles so oder so egal: Die würden erst das 42. Jubiläum feiern.