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-Copyright: (C) Copyright 1987-2003 Kristian Koehntopp -- All rights reserved.
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