Scriptsprachen (war: Bloss eine Idee)

[Michael Lackhoff]

Lieber Herr Hoeppner,

> Das ist eine gute Idee, ich habe vor einiger Zeit schon mal so etwas 
> versucht, mußte es wegen meiner anderen Projekte aber 
> fallenlassen. Ist nur am Zeitproblem gescheitert.

Schade, ich denke, das waere ein sehr lohnendes Projekt!
  
> > > Am Rande waere es natuerlich nett, die Exportsprache von allegro
> > > ueber Bord zu werfen ,vorausgesetzt es gibt etwas
> > > allgemeingueltigeres, was dasselbe kann... 
> 
> Tja, was? Eine allegro-Zeile hat in sich schon mal wenigstens eine if-
> Abfrage, ohne das man was tun müsste Und die Bearbeitung wird 
> sofort nach einer Manipulation abgebrochen, wenn der Arbeitstext 
> leer ist. Nur das in einer der anderen Sprachen zu programmieren 
> ist vielmehr Aufwand. Und die bedingten Postfixe sind manchmal 
> sehr praktisch.

Natuerlich kann keine der Scriptsprachen die allegro-Sprachen aus 
dem Stand abloesen. Ich denke mir eher eine Entwicklung wie bei 
avanti/flex. Zuerst gab es reine Steuerfunktionen und nach und 
nach kamen dann Funktionen fuer die Praesentation und 
Datenmanipulation hinzu.
Analog stelle ich mir vor, dass es anfangs sicher eine Funktion 
geben muss, die z.B. die Ausgabe eines Datensatzes/einer 
Ergebnismenge ausloest -- durch eine traditionelle Parameterdatei 
formatiert.
Doch diese Ausgabe staende dann in einer Perl-Variable. Ich 
koennte sie vor- und/oder nachbehandeln.
Nach und nach koennten dann zusaetzliche Funktionen 
dazukommen, die Funktionen der Exportsprache uebernehmen. 
Vorteil hierbei: Wenn es eine Funktion noch nicht gibt kann ich sie 
mir schreiben, wenn ich sie unbedingt brauche, was bei 
Erweiterungen der Export-/Flex-sprache nicht geht, da ich kein C 
kann und auch den Quelltext nicht zur Verfuegung haette, um 
eigene Erweiterungen einzufuegen.

> > Mit avanti hat man im Moment mindestens eine Sprache mehr, 
> > naemlich die einschlaegigen allegro-Sprachen _plus_ eine 
> > Steuersprache (bisher meist Perl, z.B. fuer CGI aber auch Delphi oder
> > Python).
> 
> aber die avanti-Sprache ist doch nun wirklich klein. Die große 

Das ist ein Missverstaendnis. Ich brauche ja normalerweise auch 
noch die Exportsprache, also Exportsprache plus Avanti plus 
Steuersprache, wobei natuerlich die Exportsprache der dickste 
Brocken ist und nicht die Avanti-Sprache. Mit avanti brauche ich 
sie eben alle, bei meiner Idee in einer Uebergangszeit zwar auch 
(s.o.) aber nach und nach koennte die Exportsprache durch 
effektive Perl-Routinen obsolet werden.

> Schweirigkeit von Nicht-Allegrologen ist nicht dort zu sehen sondern 
> im Verständnis der allegro-eigenen Datenbank-Philosophie. Es 
> kommen häufig Anfragen wie "In SQL würde meine Anfrage so 
> aussehen...." Das Verständnis des anderen Paradigmas ist die 
> größere Hürde.

Mein Problem ist ganz konkret, dass ich nicht mehr den ganzen 
Tag fuer allegro parametriere und langsam Schwierigkeiten 
bekomme, Parameterdateien und Flexe zu lesen bzw. alle 
Feinheiten und Nebenwirkungen zu verstehen und ein "use 
english;" gibt es dafuer leider nicht (der Versuch von Herrn 
Veltkamp, wenigstens durchzusetzen, dass Befehlswoerter 
ausgeschrieben werden, hat sich ja leider nicht durchgesetzt 
sondern lediglich zu einer weiteren Inkompatiblilitaet zwischen 
Flexsprache und Avanti gefuehrt).

Bei allen Qualitaeten der allegro-Sprachen -- sie haben nichts mit 
irgendetwas zu tun, was der durchschnittliche Computermensch 
(oder auch Bibliothekar) sonst so an Sprachen sieht und kennt, 
waehrend viele der Probleme (I/O, Datenmanipulation, 
Plausibilitaetspruefungen, komplizierte Datenstrukturen usw.) 
durchaus auch in anderem Zusammenhang vorkommen.
Die weiterhin noetigen und sinnvollen Besonderheiten von allegro 
waeren ueberschaubar und laegen zudem in vertrautem Gewand 
vor -- insbesondere (hoffentlich) mit sprechenden Namen statt mit 
ein/zwei-buchstabigen Variablen, Sprungmarken und 
Befehlswoertern.

> > Datenbankprogramm integriert wurde. Jedenfalls scheint mir die Tendenz
> > ganz klar von programmspezifischen Sprachen weg und hin zu allgemein
> > brauchbaren Sprachen mit per Modul zugeladenen Sonderfunktionen zu
> > gehen.
> 
> Das ist richtig und ich hätte gerne VBA für allegro. Aber zum einen 
> hebelt das nicht meinen Einwand bezüglich des Verständnisses aus, 
> und zum anderen hat das banale monetäre Gründe, diese Sprachen 
> nicht einzubinden: M$ verlangt gehörige Lizenzgebühren für die 

Mir ging es nicht um ein VBA fuer allegro sondern nur um das 
Beispiel: Als Ersatz fuer die eigene Access-Macrosprache wurde 
von MS das allgemeinere VBA eingefuehrt -- natuerlich erweitert 
um die von Access benoetigten Funktionen. Ein Grossteil der 
Sprache ist aber gleich fuer Word, Excel und Access und auch 
das normale VB ist sprachlich sehr nahe.
Was fuer MS VBA ist, koennte fuer allegro eine der P-Sprachen 
sein.

> wäre vielleicht nicht tolerabel. Man kann natürlich Python oder Perl 
> einbinden, aber Perl halte ich für einen Anfänger und Nicht-
> Programmierer, wie es die meisten Bibliothekare sind, nicht für 
> leicht zu lernen. Python wäre schon etwas besser, aber dann 
> kommen die Leute, die 'nur' Delphi, VBA oder so können und 
> sagen: "Was??? Noch eine Sprache lernen?" Und Sie haben 
> dasselbe Problem, wie vorher.

Es sollte natuerlich keinen Zwang geben, eine neue Sprache zu 
lernen, ich denke mir aber dass es fuer einen Anfaenger bedeutend 
attraktiver (und auch vom Kurs-/Literaturangebot her einfacher) ist, 
eine der genannten Sprachen zu lernen als z.B. die Exportsprache.
Vielleicht ist auch nicht so ganz deutlich geworden, dass ich 
nichts abschaffen moechte, sondern mir vorstelle, bestimmte 
Sprachen nach und nach obsolet zu machen, einfach dadurch, 
dass ich Sprachelemente und Funktionen "on board" habe, an 
denen Hunderte von Entwicklern ueber Jahre gefeilt haben, wie es 
fuer die "grossen" Scriptsprachen zutrifft (namespaces, echte 
Kontrollstrukturen, regular expressions um nur ein paar zu nennen).
Auch fuer die Entwicklungsabteilung sehe ich hier uebrigens auf 
Dauer bedeutende Erleichterungen: Die Pflege der 
Standardfunktionalitaet faellt ihr praktisch in den Schoss, dafuer 
gibt es die perl porters oder Guido mit seinem Team bei 
pythonlabs. Die Entwicklungsabteilung koennte sich ganz auf die 
Entwicklung spezieller Funktionen konzentrieren.

Don't-let-us-horrify-BE-too-much-ly y'rs. ;-)
Michael Lackhoff

-- 
FH Muenster Bibliothek / EDV
Tel.: 0251/83-64871
FAX: 0251/83-64853