Diskussion:Skriptsprache

Der Programmierer wird dadurch entlastet, verliert aber gleichzeitig an Flexibilität, da gleichzeitig elementareren Programmiermethoden aus der Skriptsprache herausgelassen werden.

Ich denke, dass eger das Gegenteil der Fall ist: Der Programmierer gewinnt Flexibilität, weil mit wenig Aufwand viel erreichen kann. In Bash kann man große Programme schreiben, aber gerade dadurch, dass jedes Kommando ein installiertes Programm sein kann, ist bash so flexiebel. -- Fgb

Gerade auf PHP trifft das mit dem "Jedes Kommando kann ein installiertes Programm" sein nicht zu. Nach meinem Wissen ist kennzeichnend für eine Skriptsprache, dass der Quelltext direkt interpretiert und ausgeführt wird, ohne dass Comilations-Zwischenschritte (PCode etc.) nötig sind. Skriptsprachen sind damit eine Teilmenge der Interpretersprachen.

Das Problem mit dieser Definition ist, dass sie genauso tauglich oder untauglich ist, wie die Agrenzung zwischen Compiler- und Interpretersprache, denn so wie es Basic-Compiler und C-Interpreter gibt, existieren auch für zahlreiche Skriptsprachen Compiler (DOS-Batch, REXX etc.). -- Flups

Vielleicht könnte man Skriptsprachen eher dadurch abgrenzen, dass dort mit wenig viel erreicht werden kann, größere Projekte aber meist unhandlich sind, also wenn man mehr als viel erreichen will, oder effizienter sein will, dann Skriptsprachen nicht oder nicht mehr effizient zu benutzen sind? -- Fgb

Newsgroups: de.comp.lang.php.misc

Subject: Re: Die leidigen "Skriptsprachen" (was: Warum OOP)

References: <avu452$v67$1@valiant.koehntopp.de> <avu82q$1nl$06$1@news.t-online.com>

From: kris@koehntopp.de (Kristian Koehntopp)

X-No-Archive: yes

X-Alignment: chaotic/good

X-Signature: Knooper Weg 46, 24103 Kiel, +49 170 2231 811

Richard Körber <shred@despammed.com> writes: >Ich habe folgende Definition gefunden und möchte sie mal kommentarlos in >den Raum stellen:

> http://de.wikipedia.org/wiki/Skriptsprache

Dies ist nicht wirklich eine Definition, tatsaechlich ist es noch nicht mal widerspruchsfrei (Der erste Teil hebt auf Domainspezifitaet ab, der zweite auf Interpretation, der dritte auf HLL vs. Effizienz, und dann kommt eine Merkmalsliste, die von den genannten Sprachen jeweils nicht vollstaendig erfuellt wird).

Interpretierend: awk, bash, Javascript. Perl, PHP, Python, Ruby, VBS und Pike (vormals LPC) arbeiten mit compiliertem Bytecode, haben daher auch keine "spaete syntaktische Fehlererkennung". Der Bytecode bei Pike ab Version 7.4 ist auf einigen Plattformen durch die Hardware ausfuehrbar, d.h. mit der lokalen Maschinensprache identisch.

Dynamische, automatische Typkonversion: In Pike nicht gegeben. Bei Py weiss ich das nicht.

Automatisches Speichermanagement: So bei allen diesen Sprachen gegeben, aber auch bei Java, Objective-C, Lisp und vielen anderen Sprachen, also kein Unterscheidungsmerkmal.

"Dynamische Klassenzugehoerigkeit" und "prototypenbasierte Vererbung":

"Prototypenbasierte Vererbung" ist sowieso ein unsinniger Begriff. Gemeint ist die Klassendefinition durch Prototypen in Javascript, und clone als einzige Methode, neue Instanzen zu erzeugen. Das ist so nur in Javascript in Reinform vorhanden. In PHP ist es ab PHP 5 mit dem clone-Konstruktor optional.

"Dynamische Klassenzugehoerigkeit" bedeutet, dass jedes Objekt zugleich seine eigene Klasse ist, und daher das Zufuegen von Instanzvariablen jederzeit moeglich ist.

       // legales PHP
       class x {
         var $y;
       }

       $x = new x;
       $x->y = 1;
       $x->z = 2;

Perl zum Beispiel hat gar kein vordefiniertes Objektsystem, sondern nur bless und einige Konventionen. Das Pantherbuch stellt zwei Klassensysteme fuer Perl vor, von denen das eine dynamisch und das andere statisch ist. Also ist dies auch kein Merkmal.

Implizit deklarierte Variablen: So bei allen diesen Sprachen ausser Pike gegeben, aber auch in Lisp und anderen "Programmiersprachen" der Fall, also kein Merkmal.

"Dynamische Funktionsnamen": Was das sein soll ist mir unklar. Das WikiLink ist noch nicht definiert.

"Spaete syntaktische Fehlererkennung": Bei allen genannten Beispielen, die Bytecode erzeugen so nicht gegeben.

Insofern finde ich den Artikel sehr, sehr fragwuerdig. Sieht man in die Diskussion zu diesem Artikel (http://de.wikipedia.org/wiki/Diskussion:Skriptsprache) wird deutlich, dass die Autoren das auch so sehen.

Ich persoenlich finde den Begriff "Scriptsprache" selbst schon fragwuerdig. Er ist ziemlich Seventies, damals bezeichnete er die Batchsprache eines Betriebssystems, die als Glue-Language zur Verknuepfung von in Maschinensprache geschriebenen Kommandos diente. Heute haben wir eine viel reichere und feiner abgestufte Welt, in der dieser Begriff zunehmend bedeutungslos wird.

Man kann bestenfalls die in der Definition gegebenen Kriterien (mit Ausnahme von "Dymanische Funktionsnamen", was immer das ist) nehmen und so eine Art "Scheinselbststaendigkeitsregelung" finden. "Eine Scriptsprache liegt vor, wenn mindestens 4 der 6 Kriterien bei einer Sprache erfuellt sind" oder so.

Kristian

Der Programmierer wird dadurch entlastet, verliert aber gleichzeitig an Flexibilität, da gleichzeitig elementareren Programmiermethoden aus der Skriptsprache herausgelassen werden. Das kann man so nicht sagen, wenn man z.B. bash und Perl dann unten in der Liste aufführt. Dies muss ausdifferenziert werden. Tatsache ist wohl, dass es vermutlich gar keine Definition für Skriptsprache gibt. --Tiago

Jetzt will ich auch mal meinen Senf zugeben. Also, Skriptsprachen wie im Artikel aus Programmiersprachen zu definieren ist schon etwas fragwüdig. Man will hier ja gerade eine Abgrenzung. Der Begriff ist an sich zu diskutieren, jedoch könnte schon jemand in Wikipedia danach suchen und sollte eine kompetente Antwort bekommen.

Man könnte den Artikel einfach danach aufziehen, dass man die Skriptsprachen, wie schon oben teilw. erwähnt, in drei Klassen einteilt:

Sprachen, die eigentlich aus der Kommandointerpreterecke kommen. Diese setzen einen Schwerpunkt auf interaktive Benutzung und erweitern diese im Variablen, Ausdrücke, Kontrollstrukturen und Systemzugriffe. Wenn man dann das was man eintippen würde in ne Datei schreibt, kann man diese ausführen, ein Skript zur Automatisierung von Aufgaben ist entstanden (schon bin ich beim Begriff Skriptsprache!). Zu diesen Sprachen gehören unter anderem die Unix-Shells z.B. bash, DOS-COMMAND.COM mit seinen Batch-Dateien. Meist sind diese interpretierend, Syntaxfehler werden nicht sofort erkannt, oft für größere Projekte nicht sehr gut geeignet
Sprachen, die dazu gedacht sind, als Library in Programmen diese Skripting-Fähigkeiten zu verleihen. Dazu gehört z. B. TCL, das Emacs-Lisp, GUILE, Visual Basic for Applications. Die Sprachen stellen Variablen und Kontrollstrukturen, manchmal auch Objekte etc, Stringarithmetik usw. zur Verfügung und können recht komplex werden. Oft entwickeln die Sprachen ein Eigenleben (tcl->tclsh/wish) in dem ein Wrapper die Library zum Programm erhebt und werden für große Projekte mißbraucht, ohne daß man sonst die Library zu einem richtigen Programm linkt. Die Performance ist oft schlecht, da das ursprüngliche Designziel nicht die Abarbeitung riesiger Dateien war. Dabei gibt es Ausnahmen, die das Problem von Anfang an erkennen (GUILE) und andere wie TCL, die schon in vielen Versionen versuchen, die Designfehler früherer Tage auszubügeln.
Sprachen, die für eigentliches Skripting vorgesehen sind. Dies ist das z. B. das klassische awk. Diese ähneln Programmiersprachen, sie sind entweder interpretieren (Syntaxfehler erst beim Ausführen) oder vorkompilierend. Der Übersetzungsprozess ist recht schnell und bleibt dem Anwender verborgen, da er einfach beim Start vorangestellt wird. Die Performance dieser Sprache ist recht gut und meist ein Designziel. Zu diesen Sprachen gehören awk, perl, php, ruby. Sie erlauben einfachste Programme wie auch komplexe Projekte (siehe z. B. CPAN-Library für Perl). Der Entwicklungsprozess gegenüber klassischen Sprachen ist etwa um eine Größenordnung schneller (würd ich schätzen). Als Kommandoeingabe lassen sich diese Sprachen meist nicht gut gebrauchen (versuch mal: perl -de 42).

Der Artikel selbst ist in vielen Stellen fragwürdig, insbes. auch wenn man obige Definitionen sieht. Erwähnen sollte man auch, daß es z. B. auch Skriptprogramme gibt, die klassische Programmiersprachen wie C- oder Pascal mit Skriptingfähigkeiten ausstatten (z. B. C-Skripting Language CSL, Sourceforge Projekt). Das bedeutet auch, dass jeder Versuch einer Abgrenzung zum Scheitern verurteilt ist!

Das ganze mit dynamischen Typkonversion, Objekten usw. würd ich eigentlich weglassen. Erwähnenswert wäre vielleicht Rapid Prototyping (wie im Artikel) und die gegenüber C/C++/Pascal komfortable Speicherverwaltung mit Hilfe von Garbage Collection (Klasse 3), die jetzt dann in Programmiersprachen (Java, VB.NET) Einzug fand und findet.

Auch so Sachen wie Flexibität usw. sind doch eher subjektiv und als Wertung aus dem Artikel IMHO zu entfernen. Hubi 08:10, 29. Aug 2003 (CEST)