Sie befinden sich auf http://www.henning-thielemann.de/ScriptingHater.html.
Forsche Seite Lockere Seite deutsch

Skriptsprachen-Hassen leichtgemacht

"Es reicht nicht, keine Idee zu haben,
wenn man unfähig ist, sie nicht umzusetzen."

Diese Seite ist den Entwicklern von Übersetzern und Interpretern und den Sprachstandardisierern in aller Welt gewidmet, die sich der Flut von Wünschen erwehren müssen, doch bitte diese oder jene schlechte Programmierergewohnheit durch geeignete Spracherweiterungen zu unterstützen.

Skriptsprachen allgemein

Wer von C/C++ genügend abgeschreckt wurde, den treibt es zumeist geradewegs in die Fänge dubioser Skript-Sprachen oder BASIC-Dialekte. Ohne die Macken von C wirklich verstanden zu haben, haben sich etliche Hobbyprogrammierer hingesetzt und ihre eigene Sprache entwickelt. Häufig dienen die Sprachen, die man in der Schule gelernt hat, als Ausgangspunkt: Pascal (speziell Borlands verhundstes Turbo-Pascal) und C . Das Ergebnis sind Sprachen, die Syntax und Konzepte aus anderen Sprachen zusammenpanschen, um einfache Aufgaben noch einfacher und schwierige noch schwieriger zu machen.

Manchmal müssen, wie bei Rebol, auch natürliche Sprachen als Vorbild herhalten. Warum eigentlich? Natürliche Sprachen wurden niemals auf Konsistenz, auf Eindeutigkeit, auf leichte Erlernbarkeit oder auf irgend etwas anderes getrimmt. Ja selbst wenn mal ein paar leichte Änderungen zugunsten von mehr Konsistenz in Form einer Rechtschreibreform eingeführt werden, gehen etliche Leute auf die Barrikaden. Warum also ausgerechnet natürliche Sprachen? Als einziger Grund fällt mir Gewohnheit ein und dieser Grund ist ziemlich schwach. Erlernen muss man Programmiersprachen auch dann, wenn sie sich stark an der natürlichen Sprache orientieren, also kann man sich auch gleich mit gut durchdachten Sprachen beschäftigen. Da lernt man sogar noch was über die Unzulänglichkeiten natürlicher Sprachen.

Das, was man mit Skriptsprachen bevorzugt macht, trägt den klangvollen Namen Rapid Prototyping (nein nicht Rabbit Prototyping!), zu deutsch: schnelles Zusammenpfuschen, damit man Interessenten bald etwas vorführen kann. Nun ist es aber so, dass sich der normale Programmierer von einmal geschriebenem Programmtext nicht wieder trennen kann, also bleibt es für immer bei der Pfuschversion, um die herum ständig neue Flicken gesetzt werden. Um diese Vorgehensweise zu unterstützen, bieten auch Skriptsprachen rudimentäre Mechanismen zum Zusammenstellen von Bibliotheken. Diese Modularisierung ist schon deswegen immer unterentwickelt, weil es keine ausdrücklichen und typsicheren Schnittstellen gibt. (siehe unten) Diese Modularisierung wäre auch völlig unnötig, wenn man Skriptsprachen nur verwenden würde, wozu sie geeignet sind, nämlich um Wegwerfprogramme zu schreiben.

Es ist neben dem "Ich mache mein eigenes Betriebssystem." ein wahrer Sport um die Kreation neuer Skriptsprachen entstanden, der anscheinend zum Ziel hat, das kürzeste "hello world"-Programm zu ermöglichen. Man glaubt es eigentlich fast nicht, dass so viele Dumme immer wieder die gleichen Gedanken haben. Ganz egal ob Perl, Rexx, Tcl, Ruby, Rebol, MatLab, Euphoria, Lua, Python, Groovy - sie sehen alle ein bisschen verschieden aus, teilen aber die gleichen Macken.

Deswegen Obacht: Wann immer jemand seine neue Programmiersprache als besonders einfach für Anfänger zu erlernen oder zu bedienen bewirbt, ist äußerste Vorsicht geboten, denn die Sprache wurde meist auch von einem solchen entwickelt!

Funktionale Sprachen

Es gibt tatsächlich auch sehr hohe Programmiersprachen, die sich bislang den üblichen "Vereinfachungen" widersetzen konnten, sehr mächtige Sprachen, mit denen man schnell Programme schreiben kann, die zwar nicht effizient, aber auf jeden Fall wartbar sind. Funktionale statisch getypte Sprachen fallen in diese Kategorie und ich möchte hier exemplarisch Haskell nennen. Funktionale Sprachen haben wirklich das Zeug, um der Skriptsprachenbewegung den Rang abzulaufen.

Während imperative Sprachen wie Modula, C oder Skriptsprachen Befehle Schritt für Schritt abarbeiten, berechnen funktionale Sprachen das Ergebnis von Funktionen, welche ihrerseits Funktionen aufrufen usw. usf. Haskell-Funktionen kann man sowohl interaktiv austesten, als auch lauffähige Programme daraus herstellen. Trotzdem ist Haskell statisch typsicher und erlaubt auf einfache Weise die Implementation von Funktionen für beliebige Typen. Es beweist damit, dass Interaktion und statische Sicherheit gleichzeitig möglich sind.

Die funktionale Grundidee vereinfacht einiges. Man braucht keine Unterscheidung zwischen Konstanten und Variablen, kein "Call by reference", keine Zuweisungen, keine vordefinierten Schleifenstrukturen, alles ist überschaubar und die Wirkung der Funktionen kontrollierbar. Es ist klar, das das nicht so bleiben darf. Nach und nach entdecken Perl- und Python-Jünger Haskell und erwarten, dass man Haskell so weit mit syntaktischem Zucker verkleistert, dass die Schlichtheit des funktionalen Ansatzes nicht mehr erkennbar ist. Leider scheinen sie damit Erfolg zu haben, wie Syntaxerweiterungen wie die parallele Listenkomprehension beweisen. Viele Haskell-Anfänger scheinen sich nicht die Mühe zu machen, sich mit dem Konzept von Funktionen und den vielfältigen Einsatzmöglichkeiten von Funktionen höherer Ordnung zu befassen. Stattdessen meiden sie alles systematische und errichten ihre Programme hauptsächlich aus syntaktischem Zucker wie Listenkomprehension, Guards, Pattern-Guards, Infix-Operatoren und do-Notation, wahlweise auch mit kleinkarierten Rekursionen. Da sie nichts anderes kennen, werden sie auch nicht müde zu betonen, wie wichtig solcher syntaktischer Zucker ist. Zum anderen gibt es immer wieder Angriffe auf die durch die Funktionen streng geordneten Datenflüsse in Haskell-Programmen. Ja, die globalen Variablen sind einfach nicht totzukriegen!

MatLab

"Wenn man ganz sicher gehen will, eine schlechte Lösung für sein Problem zu finden,
dann sollte man auf das zurückgreifen, was alle benutzen."

Wie wir im ersten Abschnitt gesehen haben, sind Allzweck-Skriptsprachen für alles mögliche ungeeignet. Aber es gibt auch Skriptsprachen, die für manche Anwendungen besonders ungeeignet sind. Eine davon ist MatLab von MathWorks, welche

  1. alle oben genannten Nachteile gängiger Skriptsprachen in sich vereint,
  2. kreativ eigene logische Aussetzer in Typsystem und Standardbibliotheken einbringt.

Um alle Kritiker unweigerlich zum Schweigen zu bringen, wird MatLab von ungezählten Wissenschaftlern weltweit mit Funktionsbibliotheken versorgt, die zwar die Sprache kein bisschen aufwerten können, aber anscheinend Grund genug sind, nicht zu wechseln. Wohin sollte man auch wechseln. Es gibt zahlreiche MatLab-Nachbauten wie RLab, SciLab, Octave und andere. Die damit verbundenen Skriptsprachen sind so angelegt, dass sie möglichst keine Macken von MatLab ausräumen, dafür aber ausreichend inkompatibel zu MatLab-Programmen sind.

Organisation

Integrierte Datentypen

Funktionen

Standardbibliotheken

Nach dieser langen Auflistung von Problemen muss man als Leser den Eindruck haben, dass MatLab rundherum schlecht und sein Geld nicht wert sei. (... und MatLab kostet viel Geld! Mit Toolboxen und allem drum und dran erleichtert MathWorks den Käufer gerne um mehrere tausend Euro.) Dieser Eindruck stimmt nicht, denn ich habe natürlich vor allem die Sachen zusammengetragen, die mich immer wieder genervt haben. Zum Schluss will ich daher wenigstens eine gute Eigenschaft von MatLab hervorheben: Wenn man an einer Einrichtung arbeitet, die über MatLab-Lizenzen verfügt, so kann es leicht passieren, dass alle vorhandenen Lizenzen für MatLab oder eine seiner Toolboxen leider schon von den Kollegen blockiert sind. Die Chancen stehen also gut, dass man sich aufgrund von Mangel an Lizenzen gar nicht mit MatLab herumzuärgern braucht!
Erstellt:2002.05 Henning Thielemann
Mit HSC verarbeitet seit:2002-05-29
Zuletzt geändert:2013-12-15, 19:34
Meinung des HTML-Prüfers: Valid HTML 4.0!
Seitenstatistiken: eXTReMe web tracking Test for JavaScript disabled
VG-Wort-Vorpixel
Überwachungszustand:Aktion UBERWACH!
Hier noch ein paar schwachsinnige E-Mail-Adressen zur Fütterung von SPAM-Adresssammlern. Die Adressen sind mit Hilfe von Markov-Ketten zufällig aus realen Namen zusammengewürfelt und existieren mit sehr großer Wahrscheinlichkeit nicht.