Scriptsprachen (war: Bloss eine Idee)

Dierk Hoeppner d.hoeppner at tu-bs.de
Fr Sep 29 09:58:20 CEST 2000


Lieber Herr Lackhoff,

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

Die Exportsprache brauche ich eigentlich nicht, sondern nur den 
Export per e-w. Den Rest kann ich selbst machen. Da braucht 
niemand zu parametrieren. Anders sieht es natürlich aus, wenn 
jemand man Index etwas ändern muss. Da kommt man z.Zt. um 
allegro-Esportsprache nicht rum.

> 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 avanti bleibt es mit dem Ausschreiben, weil ich der Meinung bin, 
dass es für die Lesbarkeit besser ist. Die 
Verarbeitungsgeschwindigkeit sinkt dadurch nicht so drastisch, dass 
man das noch verkürzen müßte.

> 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.
Tja, aber ich denke, dass die meisten Windows-EDVler VB besser 
kennen als P... Und die sagen dann: Warum muss ich jetzt P... 
lernen?

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

Da mögen Sie durchaus recht haben. Im letzten Jahr hatten wir mal 
einen Anfängerkursus für Parametrierung gemacht. Da war aber 
festzustellen, dass die weitaus überwiegende Zahl der Teilnehmer 
noch keinerlei Programmiererfahrung hatte. Die Schwierigkeit da 
bestand nicht unbedingt darin, denen die Exportsprache 
beizubringen, sondern Programmieren ansich. Es war vielen nicht 
so ohne weiteres einleuchtend, dass sie es bei der Parametrierung 
mit Zeichenketten zu tun haben und der Rechner nichts über z.B. 
Namen weiss. Diese Hürde überwinden muss jeder 
Programieranfänger egal mit welcher Sprache. Wäre die 
Exporsprache so etwas wie z.B. ein BASIC-Dialekt, wären dieselben 
Schwierigkeiten aufgetreten. Die allermeisten allegro-Anwender 
können nicht programmieren, weil es eben nicht zur Ausbildung 
eines Bibliothekars gehört. Die könnten die Probleme mit VB z.B. 
auch nicht lösen. Der größte Teil der Wordbenutzer kann ja noch 
nicht einmal die Serienbrieffunktion einsetzen. Und mit 
selbstgeschriebenen Word-Makros wird auch nichts gemacht, weil 
das Programmierverständnis fehlt. Das soll jetzt bitte nicht als Klage 
oder Anklage verstanden werden, es ist aber so. Und wer ein 
flexibles System wie allegro anpassen will, steht als unerfahrener 
Programmierer vor einem großen Problem - mit welcher Sprache 
auch immer.

ich glaube, dass ich doch verstanden habe, was sie mit den 
Gedanken bezwecken und muss auch zugeben, dass z.B. regular 
expressions dringend nötig sind.

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

Solche Diskussionen nimmt er bestimmt nicht krumm :-)

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     




Mehr Informationen über die Mailingliste Allegro