Bloss eine Idee

[Dierk Hoeppner]

Hallo Herr Lackhoff,


> Ich erwische mich vielmehr immer wieder bei Traeumen ueber 
eine 
> Alternative zu dem ganzen Zoo an Sprachen, die sich mittlerweile rund
> um allegro tummeln und damit verbunden der Traum, die
> Klassenbibliothek direkt scripten zu koennen, also mit perl und oder
> python direkt auf einer lebenden Datenbank arbeiten zu koennen. 

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.
 
> ausserhalb von allegro) verwenden lassen. XML ist eben ein Standard,
> fuer den es immer mehr Unterstuetzung aus allen moeglichen Ecken gibt
> und wenn ich sowieso lernen muss, wie man eine DTD schreibt, warum
> dann nicht auch gleich eine allegro-cfg damit bauen? Bei mir analog:

So etwas versuche ich gerade, sozusagen ein PRONTO-XML. Ich 
bin schon soweit, dass die XML-Datei(en) schon recht kompliziert 
aussehen. Das mit einem normalen Editor zu bearbeiten, wird schon 
etwas mühsam. Aber ich sehe es als Machbarkeitsstudie.

> Perl (und z.T. auch Python) brauche ich sowieso jeden Tag. Warum nicht
> gleich meine Datenaufbereitung mit Perl machen, statt mich mit den
> diversen Export- Import- Avanti-Job- und A99-Flex mit all ihren
> Feinheiten und Ausnahmen fuer besondere Faelle. Nicht dass diese
> Sprachen nicht leistungsfaehig waeren, im Gegenteil sie sind extrem
> effektiv aber leider schwer zu lernen, schwer zu lesen und schwer zu
> pflegen. 
> > 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.

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

 
> 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 
Technik, wenn man sie selbst einsetzen will. Nun gibt es ja den 
WSH, der scheinbar alles löst. Es kostet nichts, aber die 
Verwendung in den eigenen Programmen ist extrem langsam und 
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.

Viele Grüße
Dierk Hoeppner
Universitaetsbibliothek
Pockelsstr. 13
D-38106 Braunschweig
Germany
Tel: +49-531-391-5066 Fax: -5836
E-Mail: d.hoeppner at tu-bs.de