Scriptsprachen (war: Bloss eine Idee)

[Thomas Berger]

Lieber Herr Hoeppner,

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

Diesen armen Kerlen kann man dann antworten, dass ActiveState
im Auftrag von Microsoft an PerlScript als Sprache unter dem
WSH gearbeitet hat und derzeit dasselbe auch fuer Python
versucht (glaube ich, oder sie arbeiten an VisualPython,
muesste mal jemand nachschauen: http://www.activestate.com/)

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

Sie koennen nach meinen Erfahrungen auch das Wort
"Bibliothekar" durch "Systemadministrator" ersetzen,
ohne besonders daneben zu liegen. Ich denke aber,
in beiden Berufsgruppen gibt es ein ueberdurchschnittliches
Potential dafuer, Progammieren zu lernen (bei den
einen wegen einer unterstellten Technikaffinitaet,
bei den anderen wegen eines durch die Regelwerksausbildung
trainierten Ansatzes zu algorithmischem Denken).
Warum also nicht mittelfristig darauf bauen, dass
Teilnehmer an Parametrierkursen bereits ein Volskhochschul-
Niveau in Scriptsprachen haben? DOS-Kenntnisse setzen
Sie ja angeblich auch voraus.

Aus Ihrem Absatz lese ich auch nur das Argument, realitaetsnaehere
Voraussetzungen einzufordern: Personen mit bibliothekarischen
*und* Programmierkenntnissen sind selten genug, um diese
Personen nicht zu ueberlasten, sollten die Anwendungs-
Kontrollsprachen moeglichst aehnliche Dialekte sein
und aehnlich strukturiert sein (VBA und JavaScript sind
ziemlich aehnlich, die P-Sprachen in einem gewissen Sinne
auch: Kenne ich die eine, macht mir das Erlernen der
anderen keine Muehe, wenn ich denn einsehe, dass ich
sie lernen sollte. Perl-Programme von C-Programmieren
sehen natuerlich entsetzlich aus und sind nach der
Meinung vieler Leute garkein Perl, aber sie laufen :-)
Eine assemblerartige Sprache wie die Exportsprache
ist aber (selbst abgesehen von ihren Inkonsistenzen und 
ihrer "Gewachsenheit") eine ganz andere Welt.
Vor einigen Jahren hatte ich mal ventiliert was wuerde,
wenn man eine Art Compiler hat: Eine geeignet designte 
Sprache mit Kontrollstrukturen etc. wuerde dadurch in 
die Exportsprache compiliert (Sprungmarken, Vergleiche
etc.). Ich habe das aber nie weiterverfolgt, weil mir
die umgekehrte Perspektive tragender erschien: Alte
Parameterdateien irgendwann (evtl. eingebaut in a3000)
in diese "geeignet designte" neue Exportsprache zu
ueberfuehren. 

viele Gruesse
Thomas Berger