Diskussion:Skriptsprache

Definition / Abgrenzung zu Programmiersprachen

Flexibilität

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 (undatiert signierter Beitrag von Fgb (Diskussion | Beiträge) 17:03, 23. Aug. 2002 (CEST))

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 (undatiert signierter Beitrag von Flups (Diskussion | Beiträge) 21:19, 23. Aug. 2002 (CEST))

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 (undatiert signierter Beitrag von Fgb (Diskussion | Beiträge) 08:45, 24. Aug. 2002 (CEST))

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 (nicht signierter Beitrag von 195.186.167.159 (Diskussion) 16:06, 26. Jan. 2003 (CET))

Kommentar aus newsgroup de.comp.lang.php.misc

Newsgroups: de.comp.lang.php.misc
Subject: Re: Die leidigen "Skriptsprachen" (was: Warum OOP)

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

(nicht signierter Beitrag von 195.244.233.52 (Diskussion) 13:45, 13. Jan. 2003 (CET))

Weitere Meinung

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:

1. 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
2. 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.
3. 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)

Ich habe versucht, die vorgenannten Punkte teilweise in den Artitel einzuarbeiten, wäre aber dankbar für jedwede (auch negative/vernichtende, natürlich viel lieber positive) Kritik/Diskussion Hubi 19:53, 29. Aug 2003 (CEST)

Definition für "Skriptsprache"

Im einleitenden Satz steht Skriptsprachen sind Programmiersprachen, die die Ausführung des Programmcodes ohne getrennte Übersetzungsphase ermöglichen. Ich würde sagen, das gilt für fast jede Programmiersprache. Bitte, die Definition noch einmal zu überprüfen. --217.82.229.72 22:02, 27. Mär 2005 (CEST)

Der einleitende Satz Skriptsprachen sind Programmiersprachen ist meiner Meinung nach falsch, da Scripte im Gegensatz zu Programmen nicht in Maschinencode übersetzt werden, sondern im Klartext für alle Nutzer lesbar und kopierbar bleibt. Sie werden durch andere Programme interpretiert, z.B. im Browser, was auch nicht für Programme zutrifft. Mit Programmiersprachen erstellt man alleinstehende Anwendungen - Scripte sind abhängig von Programmen, die sie ausführen. Wenn Scriptsprachen Programmiersprachen wären, bräuchte man keine zwei Begriffe. Unterschiedliche Variablendeklaration etc. reichen nicht aus, um einen neuen Begriff zu definieren oder notwendig zu machen - die sind in verschiedenen Programmiersprachen ebenfalls unterschiedlich umgesetzt. --KielerSprotte67 KielerSprotte67 19:30, 18. Jan. 2011 (CET)

Es sind Programmiersprachen. (Ich halte daher sogar fast den Artikel für überflüssig) Es ergibt doch keinen Sinn, danach zu unterscheiden, ob es Compiler gibt, denn das kann sich jederzeit ändern. Und was ist in Fällen, wo es Compiler gibt, aber dennoch aus Tradition o.ä. Programme in Quelltextform verbreitet werden?

Ein Beispiel für ein besseres Unterscheidungsmerkmal ist Turing-Vollständigkeit. Dieses ist hier aber nicht anwendbar, bzw. führt zu keinem Unterschied. --Daniel5Ko 21:11, 18. Jan. 2011 (CET)

Der Einleitungsabsatz von Programmiersprachen ist mMn übrigens auch nicht korrekt, da er nur Maschinensprachen oder kompilierte Sprachen zulässt, und damit interpretierte Sprachen ausschließt. --Joachim Pense (d) 22:43, 18. Jan. 2011 (CET)

Naja, wenn bei jedem Programmstart eine Übersetzung stattfindet (und die meisten Interpreter machen das ja, ggf. auch nur in einen dann interpretierten Syntaxbaum oder Bytecode), passt das ja mit 'nem blauen Auge auch ziemlich gut für "Skriptsprachen". Aber ja, besser wäre wohl eine andere Formulierung. --Daniel5Ko 22:52, 18. Jan. 2011 (CET)

Der einleitende Satz wurde ja inzwischen geändert. Falsch daran war die Ausschließung einer getrennten Übersetzungsphase. Aber natürlich sind Scriptsprachen Programmiersprachen. Man braucht die zwei Begriffe, um eine bestimmte Teilklasse von Programmiersprachen bezeichnen zu können. Analog zu weiteren Teilklassen, wie z.B. objektorientierte Sprachen etc. --Gms 11:08, 14. Feb. 2011 (CET)

Was ist eine Scriptsprache?
Was ist ein Script?
Was ist eine Sprache?

Eine Scriptsprache gehört zur Menge der Sprachen, Untermenge Programmiersprachen.

Zur Menge der Scriptspachen gehören alle die Programmiersprachen, mit denen man scripten kann. Das muß nicht ausschließlich der Zweck dieser Programmiersprache sein.

Man kann also den Quelltext (das Script) verarbeiten, ohne vorher explizit einen Compilierungsvorgang starten zu müssen. Das heißt, das Script selbst ist lauffägig.

Dabei ist es unerheblich, ob implizit ein Compilierungsvorgang vor der Ausführung gestartet wird. Das wäre höchstens erwähnenswert, daß das manchmal so ist und manchmal nicht.

Es ist unerheblich, ob die Programmiersprache zur Menge funktional, objektorientiert oder hybrid gehört.

Im Artikel wurde viel zu viel in den Begriff hineininterpretiert.
Die einzelnen Programmiersprachen sind selbst ausreichend in Wikipedia definiert.
Das muß man hier nicht noch einmal machen.
-- STEFFENW (14:12, 6. Apr. 2011 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Mit heutigem Stand (18.09.2015) ist keine Begriffsdefinition mehr erkennbar. Ich lese da …vor allem…meist…oft…meist…meistens…fast ausschließlich…Häufig… – ohne Begründung und Quellenangaben. Das ist nicht enzyklopädisch und trägt zur Verwirrung mehr bei als zur Klärung. Hier besteht Handlungsbedarf. Jemand müsste entweder enzyklopädisch exakt erklären, was genau eine Skriptsprache ist, oder man geht den leidigen Weg der Alibi-Wischi-Waschi-Beschreibung à la Der Begriff Skriptsprache wird im allgemeinen Sprachgebrauch nicht einheitlich verwendet… etc. pp. – auch hier wären Quellenangaben angebracht. --77.3.202.39 22:44, 18. Sep. 2015 (CEST)

Definition

Es fehlt hier leider die eigentliche Definition. Skriptsprachen sind interpretierte Sprachen (im Gegensatz zu zu kompilierenden Sprachen). --Outliver 18:01, 11. Jan. 2012 (CET)

Das ist nicht die eigentliche Definition. Es gibt interpretierte "normale" Sprachen, und auch kompilierte Skriptsprachen. --Joachim Pense (d) 18:41, 11. Jan. 2012 (CET)

Okay, worin liegt dann die Definition? Es gibt dank WebGL mittlerweile 3D-Rendereing-Engines in JavaScript, was, denke ich, nicht mehr unter "kleine, überschaubare Programmieraufgaben" fallen dürfte. Und Variablen deklarieren geht auch. -- Outliver 00:55, 12. Jan. 2012 (CET)

„Skriptsprache“ ist einfach kein eindetig definierter Begriff. Das sollte klargestellt werden. Manchmal wird „ursprünglich für kleine Skripte gedacht“, manchmal dynamische Typisierung u. ä., manchmal die Form der Ausführung als Kriterium herangezogen. Auch, dass traditionell als solche bezeichnete Sprachen, mittlerweile oder gar schon immer auch Features speziell zur Anwendung in umfangreicheren Programmen enthalten. --Chricho ¹ 14:23, 12. Jan. 2012 (CET)

„Programme, die in Skriptsprachen geschrieben sind, werden auch Skripte oder Scripts genannt.“ Das ist allerdings eindeutig falsch. Typo3 etwa ist kein Skript. Bei Skripten kommt es maßgeblich auf den Umfang und die Verwendung an, nur sekundär auf die Sprache. --Chricho ¹ 14:26, 12. Jan. 2012 (CET)

Letzte Änderungen (August 2014)

Ich bin mit den letzten Änderungen nicht einverstanden, mag sie aber nicht ohne Diskussion revertieren.

1. Was macht eine Skriptsprache „anwendungsspezifisch“? Die mir bekannten Skriptsprachen sind universelle, anwendungsunabhängige Werkzeuge.
2. Zitat: „... die meist über einen Interpreter zur Ausführung kommen.“ Für welche Skriptsprache gölte das nicht?
3. Zitat: „... während für Unterprogramme meistens die Bezeichnung Makro verwendet wird.“ Das bezweifle ich. In keiner mir bekannten Skriptsprache ist Makro ein Synonym für Unterprogramm.

--Mosmas (Diskussion) 12:51, 15. Aug. 2014 (CEST)

1. Der Unterschied zwischen Skriptsprachen und allgemeinen Programmiersprachen ist genau der, dass Skriptsprachen anwendungsspezifisch sind. Sonst bräuchte man den Begriff "Skriptsprache" gar nicht. (Z.B. wäre Java-Script kein Gegenbeispiel, auch wenn es sehr allgemein ist, ist es doch anwendungsspezifisch.)
2. Weil die Thematik einer Skriptsprache in sich abgeschlossen ist, kann man für Skriptsprachen immer einen Interpreter erstellen. Gelegentlich aber wird auch ein Compiler erstellt mit dem bewährte Skripten vorkompiliert werden, damit sie schneller ausgeführt werden können.
3. Der Begriff "Unterprogramm" stammt aus den Anfängen der Informatik, wie die Skriptsprachen eben auch. Heutzutage würde man dafür den Begriff Funktion, Methode oder Prozedur verwenden.

(nicht signierter Beitrag von JHuebl (Diskussion | Beiträge) 14:06, 15. Aug. 2014 (CEST))

Das überzeugt mich nicht.

1. Was an Perl, Python oder Bash ist anwendungsspezifisch? Spezifisch für welche Anwendung?
2. Dass gelegentlich Compiler existieren, ist richtig - insofern stimmt das „meist“. Deine Begründung für die Existenz von Interpretern („weil die Thematik einer Skriptsprache in sich abgeschlossen ist“) ist mir allerdings schleierhaft.
3. Wenn der Begriff Unterprogramm aus den Anfängen der Informatik stammt, warum verwendest du ihn dann? Und Makro ist ebensowenig ein Synonym für Funktion, Methode oder Prozedur.

Bitte signiere deine Beiträge künftig. Grüße, --Mosmas (Diskussion) 14:33, 15. Aug. 2014 (CEST)

1. Siehe Wikipedia "Perl": " Ursprünglich als Werkzeug zur Verarbeitung und Manipulation von Textdateien insbesondere bei System- und Netzwerkadministration vorgesehen (zum Beispiel Auswertung von Logdateien), hat Perl auch bei der Entwicklung von Webanwendungen und in der Bioinformatik weite Verbreitung gefunden." Bash ist eine Skriptsprache für eine UNIX-Shell.
2. Allgemeine Programmiersprachen erlauben immer auch direkt oder indirekt die Erweiterung über in Assembler geschriebene Code-Teile oder Bibliotheken. Nur so ist sichergestellt, dass man alles programmieren kann, was der Prozessor kann. Ein Interpreter ist ein fertiges Programm und deshalb im Bezug auf seine Möglichkeiten immer abgeschlossen. (Bei Verwendung von DLL's müßte man ins Detail gehen.) Weil Skriptsprachen bzgl. der Anwendung abgeschlossen sind, kann man einen Interpreter schreiben.
3. Ich wollte mich nicht für einen der Begriffe Funktion, Methode oder Prozedur entscheiden.

Danke für den Hinweis zu Signatur.

--JHuebl (Diskussion) 15:09, 15. Aug. 2014 (CEST)

Dass Skriptsprachen anwendungsspezifisch sind, sehe ich ebenfalls so nicht. Gibt es dafür einen konkreten Beleg?

Und Makros als "Unterprogramme" zu bezeichnen ist mE. auch nicht ganz so glücklich.--Plankton314 (Diskussion) 13:23, 16. Aug. 2014 (CEST)

Es war umgekehrt: Unterprogramme wurden als Makros bezeichnet (es werde „für Unterprogramme meistens die Bezeichnung Makro verwendet“), und das ist nicht unglücklich, sondern schlicht falsch. Mit den Änderungen von Plankton314 ist es für mein Empfinden jetzt ok. --Mosmas (Diskussion) 12:05, 17. Aug. 2014 (CEST)

In https://en.wikipedia.org/wiki/Scripting_language steht: "A scripting language can be viewed as a domain-specific language for a particular environment". "domain-specific" kann man nicht direkt mit "anwendungsspezifisch" übersetzen, weil es noch strenger abgrenzt als "anwendungsspezifisch".

In https://de.wikipedia.org/wiki/Unterprogramm steht: "Ein Unterprogramm ist ein Teil eines Computerprogramms, das eine bestimmte Funktionalität bereitstellt." Ich denke doch, dass ein Makro eine bestimmte Funktionalität bereitstellt und somit ein Unterprogramm ist. Da wir hier von Skriptsprachen reden, gibt es auch keine weitere Form von Unterprogrammen. Somit ist jedes Unterprogramm einer Skriptsprache ein Makro.

--JHuebl (Diskussion) 20:04, 17. Aug. 2014 (CEST)

Die kurze Antwort lautet: Wir schreiben nicht aus dem englischen Wiki ab.

Die lange: Anwendungsspezifisch grenzt Skriptsprachen heute zu sehr ein. Mag sein, dass einige Sprachen ihren Ursprung in einer speziellen Anwendung hatten, aber seit dem es Interpreter und Standardbibliotheken dazu gibt, ist diese Einschränkung mE. nicht mehr zutreffend. Eine besser Übersetzung für "domain-specific" als "domänenspezifisch" kann ich gerade auch nicht anbieten, aber eine Domäne ist ein weiter gefasster Begriff als eine Anwendung.

Dass ein Makro ein Unterprogramm sei, ist nicht zutreffend, denn es wird nicht zu einem Teil des Programms.--Plankton314 (Diskussion) 14:51, 20. Aug. 2014 (CEST)

Definitionen in der Literatur

gudn tach!
da wir bisher fast keine belege fuer den artikel (insb. keine belege fuer die definition) haben, koennen wir ja hier mal sammeln, was es so gibt. bitte einfach die liste ergaenzen. diskutieren, dann bitte unter der liste und nicht mittendrin. -- seth 23:42, 20. Sep. 2015 (CEST)

• "Skriptsprachen (englisch: scripting language) sind urspünglich Programmiersprachen, die Software-Systeme kontrollieren oder steuern sollen. Typischerweise benutzen Skriptsprachen einen Zwei-Sprachen-Ansatz: das Kernsystem wird in einer anderen Programmiersprache als der Skriptsprache implementiert und die Skriptsprache übernimmt nur das Zusammenfügen der Systembausteine in ein lauffähiges System." (quelle: Oliver Vogel et al.: Software-Architektur: Grundlagen - Konzepte - Praxis, Springer-Verlag, 2009, S. 185) -- seth 23:42, 20. Sep. 2015 (CEST)
• zur frage "Ist Python eine Skriptsprache?": "Tatsächlich spricht man oft von einem 'Skript' statt von einem 'Programm', wenn es um eine Datei mit Python-Code geht. In diesem Buch werden die Begriffe [...] synonym zueinander benutzt. Dabei wird 'Skript' leicht bevorzugt, wenn es um eine einzelne einfache Datei geht, und 'Programm', wenn eine höher entwickelte Anwendung aus mehreren Dateien gemeint ist. [...]" (quelle: Mark Lutz, David Ascher, Dinu C. Gherman: Einführung in Python, O'Reilly, 2007, S. 6) -- seth 23:42, 20. Sep. 2015 (CEST)
• "Eine allgemeine Unterscheidung zwischen einer Skriptsprache und einer Sprache, die zum Schreiben ganzer Anwendungen verwendet wird, besteht darin, dass eine Programmiersprache in der Regel zuerst kompiliert wird, bevor sie ausgeführt werden darf. In Skriptsprachen hingegen, werden jedoch die einzelnen Befehle nacheinander interpretiert und dabei direkt ausgeführt." (quelle: Was sind Skriptsprachen? - Definition, Beispiele und Analysen) auf datensprache.de --Anton Sachs (Diskussion) 12:12, 19. Aug. 2018 (CEST)

Implikationen

• "Ähnlich wie in der realen Welt gibt es im Web sehr viele unterschiedliche Skript- und Programmiersprachen." (quelle: Skriptsprachen für das Web auf pc-magazin.de) --Anton Sachs (Diskussion) 12:12, 19. Aug. 2018 (CEST)
• Trennung zwischen Prozedurale und Objektorientierte Programmiersprachen und Skriptsprachen auf gleicher Ebene (kein Unterkapitel) mit der Nennung von OO Skriptsprachen nur unter Zweiteres. (quelle: Zusammenstellung verschiedener Informationen von der Fachhochschule Augsburg) --Anton Sachs (Diskussion) 12:12, 19. Aug. 2018 (CEST)

Ich hab jetzt diese (wohl unbenutzte) Liste genommen, um ein paar Beispiele zu nennen und aufzuzeigen, dass es unterschiedliche Ansichten gibt. Sicherlich sagt keines explizit "SSe ist keine PSe", da es bei Definitionen darum geht zu sagen was etwas ist und nicht was es nicht ist. Wenn man Giraffe nachschlägt, findet man auch nicht den Satz Giraffen seien keine Elefanten. Daher ist es nicht verwunderlich, dass Inkludierer es dann auch so explizit hinschreiben, Excludierer nicht. Jedoch erkennt man an der Verwendung der beiden Begriffe, ob für jemand es zwei unterschiedliche Dinge sind. Wenn SSe PSe sind, dann macht Skript- und Programmiersprachen soviel Sinn wie Männer und Menschen. Ich hoffe man kann folgen. Nochmal zur Erwähnung: Ich bin nicht an eine Diskussion interessiert, welches der beiden Perspektive nun die richtige ist. Ich möchte nur, dass der Artikel unparteiisch beides reflektiert. --Anton Sachs (Diskussion) 12:12, 19. Aug. 2018 (CEST)

Berücksichtigung der Umstrittigkeit

Ich bin der gleichen Meinung wie Kielersprotte67 und könnte diverse Unterschiede auflisten, die mMn gravierend sind und einer Trennung der beiden Begriffe bedürfen. Jedoch beim googlen sehe ich, dass die Lager gespalten sind. Da ich auch mir von einer erneuten Diskussion hier nicht viel erhoffe (weil dann einfach cherrygepickt wird), plädiere ich, dass der Artikel zumindest nicht für eine Seite Partei ergreift, sondern explizit genannt wird, dass es unterschiedlich aufgefasst wird. Eventuell könnte man unterschiedliche Ansichten auflisten wie in etwa hier. --Anton Sachs (Diskussion) 23:33, 15. Aug. 2018 (CEST)

Da eine IP grade diese Änderung gemacht hat, würde ich mir wünschen, wenn wir einen Konsens in dieser Angelegenheit finden würden. --Anton Sachs (Diskussion) 05:57, 21. Aug. 2019 (CEST)

Programmcode & Daten

Bei einigen Skriptsprachen gibt es keine Unterscheidung zwischen Programmcode und Daten.

Ich sehe keinen Unterschied dazwischen wie z.B. Java und Python Daten un d Programmcode verwenden. Kann mir jemand erklären wie das genau gemeint ist? Inwiefern es zwischen diesen keinen Unterschied gibt? --Blauebirke 02:23, 23. Okt 2005 (CEST)

Naja, wenn man nur C/Pascal Nachfolger nimmt, gibt's natürlich einen Unterschied. Siehe z. B. TCL, Guile, Lisp, Forth (Programmcode sind im wesentlichen Listen, die in der Skriptsprache erzeugt und mit normalen Listenkommandos manipuliert werden und anschliessend ausgeführt werden. Das ist in C/Pascal/Java/Python nicht (ohne weiteres) möglich. --Hubi 09:54, 23. Okt 2005 (CEST)

Danke für die Erklärung. Habe den Satz nun so geändert, dass ich es auch Verstanden hätte ;-). --Blauebirke 00:19, 25. Okt 2005 (CEST)

Dieser Abschnitt kann archiviert werden. --Anton Sachs (Diskussion) 15:15, 27. Jan. 2020 (CET)

Unvorhersagbarkeit/Sicherheit

Ein weiteres der Hauptprobleme ist die Unvorhersagbarkeit des Verhaltens eines existierenden Skriptes auf Grund des dynamischen Charakters von Skriptsprachen generell.

Leider kann ich das nicht nachvollziehen. Könnte mir das jemand näher erklären? --Blauebirke 03:40, 28. Okt 2005 (CEST)

Ich auch nicht. Es ist unklar, was der Schreiber da gemeint haben könnte. Der ganze Sicherheitsabschnitt müsste neu geschrieben werden (Stichwort: Geschwurbel). Auch davor: Kontrollstrukturen wirkungslos!? Wie soll denn das gehen? Im übrigen: Gerade C, keine Skriptsprache, beschert uns die berühmten Bufferoverflows und wilden Zeiger, die für viele Sicherheitsprobleme Hauptschuldigen. C++ räumt mit dieser Unsitte nicht auf. Tendenziell Skriptsprachen gekoppelt mit schlechtem Programmierstil für Sicherheitsprobleme verantwortlich zu machen, ist hier mE grottenfalsch. Kurz: raus damit. --Hubi 07:10, 28. Okt 2005 (CEST)

Ich vermute, das schlechte Bild bezogen auf Sicherheitsaspekte rührt daher, dass die Skriptsprache "JavaScript" in der Vergangenheit viele Sicherheitsprobleme aufgeworfen hat. Grund dafür ist aber das fehlende Sicherheitsmodell, und nicht die Tatsache, dass es sich um eine Skriptsprache handelt. --Kadeck 11:03, 31. Okt 2005 (CET)

Ich finde schon, dass es einen Abschnitt über die Sicherheit von Skriptsprachen geben sollte (auch wenn, neu geschrieben oder zumindest komplett überarbeitet werden muss). Zum einen, weil die Sicherheitsprobleme in Skriptsprachen sehr charakteristisch für diese sind. Weil gerade keine Bufferüberläufe oder wilde Zeiger gilbt. Zum anderen, weil Skriptsprachen mehr und mehr gerade in sicherheitskritische Bereiche (Webserver, Webbrowser, Dokumenten...) eingesetzt werden.

In der Secure Programming for Linux and Unix unter PHP (engl) steht z.B., dass vor Version 4.1.0. es sehr schwer sichere Programme zu schreiben war, selbst wenn man wollte. In dem Text werden zwar die Sprachen einzeln angesprochen, es gibt aber auch Gemeinsamkeiten in den Problemen --Blauebirke 00:11, 1. Nov 2005 (CET)

Sicher, Skriptsprachen leiden unter Sicherheitsproblemen. Allerdings bin ich der Meinung, dass lediglich andere Probleme auftreten. C/C++ machen die Programmierung von Pufferüberläufen sehr leicht, führen zu relativ langem, teilweise unübersichtlichen Programmtext. Wesentlich für Sicherheitsprobleme. Kann ich dasselbe in 1/5tel des Codes in einer verständlichen Skriptsprache erledigen, ist das sicherheitstechnisch unbedingt ein Argument für die Verwendung einer Skriptsprache. Skriptsprachen leiden an oft an zuviel "Intelligenz". PHP setzt(e) Variablen automatisch aus der URL. Perl etwa ermöglicht in der open-Funktion auch die Ausführung von Prozessen, die Datei ist dann eine anonyme Pipe. Dies ist ein oft verwendeter Angriffspunkt, wenn Perl für Webservices verwendet wird. --Hubi 08:50, 1. Nov 2005 (CET)

Umsetzung von Skriptsprachen als Interpreter

Im Artikel steht: Skriptsprachen werden in der Regel ohne getrennte Übersetzungsphase ausgeführt. Ist das wirklich die Regel? Die verbreitetste Skriptsprache, ist doch wohl Basic, und die wird meines Wissens in der Regel kompiliert. --Kadeck 11:03, 31. Okt 2005 (CET)

BASIC ist keine Skriptsprache (im eigentlichen Sinne), sondern eine (recht alte) Programmiersprache, ursprünglich sogar mit getrennter Übersetzungsphase. In den 70er/80er Jahren waren Heimcomputer mit reinen BASIC-Interpretern ausgestattet (wenn man von der teilweisen Tokenisierung absieht), es wurde also in der Regel interpretiert. BASIC-Compiler waren damals nicht sehr verbreitet. Heute ist VBScript zwar eine verbreitete Skriptsprache, dies ist jedoch lediglich ein proprietärer BASIC-Dialekt. BASIC selbst würde ich nicht als Skriptsprache ansehen, schon gar nicht als die verbreitetste. --Hubi 17:09, 31. Okt 2005 (CET)

Schaun wir mal. Gemäß der Kriterienliste aus dem Artikel haben wir:

• implizit deklarierte Variablen: ja
• dynamische, automatische Typumwandlung, bzw. ganz fehlende Typunterscheidung: ja
• automatische Speicherverwaltung: ja

Demnach ist BASIC eine Skriptsprache. --Herzl 18:10, 1. Nov 2005 (CET)

Konzipiert als Skriptsprache: nein --Hubi 19:01, 1. Nov 2005 (CET)

Irrelevant. BASIC ist eine der verbreitetsten Skriptsprachen. Siehe auch VBA. --Herzl 00:15, 5. Nov 2005 (CET)

"VBA" <> "BASIC". mE relevant. --Hubi 18:43, 6. Nov 2005 (CET)

• implizit definierte Variablen: meistens. Es gab auch BASIC-Dialekte, wo Variablen mittels LET explizit definiert werden mussten (z.B. ZX Basic). BTW, zu BASIC gibt es ja auch einen ISO-Standard (wenngleich sich niemand darum kümmert), wie sieht's dort mit implizit definierten Variablen aus?
• Dynamische, automatische Typumwandlung: nein. Ich kann mich jedenfalls nicht erinnern, dass es möglich gewesen wäre, eine Zahl an einen String zuzuweisen oder umgekehrt (für die Umwandlung gab es explizite Funktionen: STR$ für Zahl->String, VAL für String->Zahl. Da die einzigen Datentypen in BASIC Zahlen, Strings und Arrays derselben waren (und zwischen Arrays und Nicht-Arrays gab es erst recht keine implizite Umwandlung), wüßte ich nicht, wo eine implizite Umwandlung passieren sollte. Ok, möglicherweise haben einige Dialekte zwischen Ganzzahlen und Fließkommazahlen unterschieden, in diesem Fall hatten sie wohl auch eine implizite Umwandlung; aber wenn die ein Kriterium sein soll, dann muss wohl auch C eine Skriptsprache sein ...
• Automatische Speicherverwaltung: nein.Dynamischen Speicher gab't bei BASIC nie, und die einzige Möglichkeit, Variablen loszuwerden, war ein Löschen aller Variablen (üblicherweise passierte das beim Ausführen von RUN, manche BASIC-Varianten hatten auch einen eigenen Befehl, um nur Variablen zu löschen).

Was die modernen Sprachen mit "Basic" im Namen so machen, ist hier irrelevant, denn die haben mit BASIC weniger gemein als C++ mit C. --132.199.100.181 --(undatiert signierter Beitrag von 132.199.100.181 (Diskussion) 13:03, 16. Mär. 2006 (CET))

Etymologie/Schreibweise

Das Wort Skriptsprache ist eingedeutscht, was im Technikbereich/ Programmierbereich weitestgehend unüblich ist. Ich bin kein Fachmann in diesem Bereich, mich würde aber die Sachlage (der Ursprung) dazu genauer interessieren. Andere Länder haben das Wort Script auch nicht übersetzt. Scriptsprache ist in Google übrigens mit doppelter Trefferzahl vertreten. --Ολλίμίνατορέ ^Ω 14:12, 2. Mär 2006 (CET)

+ 1 für Script, das tut mir in den Augen weh, ich bin in diesem Kontext auch eher die englische Schreibweise gewohnt. - RealLink 00:46, 16. Mär 2006 (CET)

Da in der Mehrheit der Fachlexika Scriptsprache steht, der Google-Test mit dem Ausschluss von -Wikipedia noch deutlicher (43.000 Treffer weniger für Skript) ist, somit eine eindeutige Mehrheit (ohne bisherigen Einwand besteht) beantrage ich eine Abstimmung zur Änderung und Verschiebung des Lemmas. (Betr. Fachmann: Ich bin schon seid einigen Jahren in dem Bereich kundig, ich meinte nur nicht als Profi oder Linguist). -- Ολλίμίνατορέ ^Ω 02:33, 16. Mär 2006 (CET)

Neuester Google-Test Sc=1.460.000 Sk=508.000 mit dem Plural des Lemmas ist soger eine dreifache Mehrheit vorhanden. Da wie eben jemand meine Ergebnisse (sogar umgedreht) nicht bestätigen konnte, bitte ich um selbige. Des Weiteren spricht der Umstand des völligen fehlens des „eigentlichen Lemmas“, dem Artikel Unsachlichkeit (o.s. Dilettantismus) zu. -- Ολλίμίνατορέ ^Ω 03:41, 16. Mär 2006 (CET)

Zuerst möchte mich dafür entschuldigen. Es war keine böse Absicht dahinter. Wie ich da gesucht habe ist mir jetzt auch ein Rätsel, habe wohl sehr schlampig gearbeitet (Tippfehler in c oder so? ich weiß es nicht). Ich ziehe hiermit diese Statistik zurück.

Andererseits finde ich schon, das der Titel den ersten Begriff reflektieren sollte (also verschieben und ändern gleichzeitig). Bei einer heise-Suche in der c't-Zeitschrift nach S[kc]riptsprache steht es 21 zu 1 für das k. Interessanter weise sieht es bei iX etwas anders aus (k: 1 zu c: 2). http://www.python.de/ schreibt (zumindest auf der Startseite) ebenfalls mit k. Nicht anders bei http://www.php.de/ wobei der link auf wikipedia nicht auf Neutralität weißt. Die Aussage die Schreibweise mit k sei "total unüblich" halte ich deshalb für stark übertrieben.

Ebenfalls zu bedenken ist, dass die Kategorie Skriptsprache heißt, so dass ein einheitliches Ändern auf die c Schreibweise viele Änderungen mit sich ziehen würde. --Blauebirke 19:43, 16. Mär 2006 (CET)

Google findet unter Ausschluss von "Wikipedia" 227.000 deutschsprachige Seiten für "Shellscript" mit c [1], 261.000 deutschsprachige Seiten für "Shellskript" mit k [2] (auch wenn ich die Google-Suche für kein wirklich seriöses Instrument halte). Tatsächlich wird in Wörtern lateinischen Ursprungs im Deutschen das "c" als "z" bzw. "k" geschrieben, z.B. "Zirkus" von circus, sodass die Dominanz von k nicht wirklich wundert. Im Englischen und in anderen lebenden Sprachen wird das anders gehandhabt, deshalb kann ich mangels Quellenangabe nur annehmen, dass ihr die hohen Zahlen ohne Spracheingrenzung erzielt und englische Seiten mitgezählt habt. Subjektive Gewöhnung kann ich gut nachvollziehen, weil in diesem Fach englischsprachige Literatur dominiert und weil Eigennamen (z.B. "JavaScript", "Windows Scripting Host" udgl.) natürlich nicht übersetzt werden; einen Grund, die deutsche Schreibweise auf die englische zu ändern, leite ich daraus aber nicht ab, zumal sogar die Google-Zahlen anders aussehen. Übrigens schreibt ihr "englisch" mit sch, obwohl es dafür nur 192.000.000 Google-Treffer [3] gibt, während es für "english" mit sh 4.160.000.000 Google-Treffer [4] gibt. Viele Grüße, --GottschallCh 12:00, 16. Mär 2006 (CET)

Selbstverständlich weisen meine Links (wie man sehen kann) auf den deutschen Sprachraum. Dein Vergleich englisch umd english auf eine internationale Suche zu erweitern, halte ich fast für eine Beleidigung (offensichtlich völlig sinnfrei). Wenn gleich meine Zahlen völlig anders sind (weniger). Deine Vergleichszahlen mit Shell konnte ich nur für k bestätigen. Wenn wir diesen Vergleich auf Deustchland setzen, steht eine überdeutliche Mehrheit für Shell c=504.000, k= 218.000 Dieser krasse Unterschied (von Sprachraum vs. Deustchland) lässt nur denn Schluß zu das hier der Versuch einer unsachkundigen „Verdeutschung“ vorliegt!? Nichts desto trotz finde ich, es könnte eine Zeile über die Herkunft des Wortes in den Artikel. Danke für dein Statement. MfGruß -- Ολλίμίνατορέ ^Ω 12:41, 16. Mär 2006 (CET)

Hi! Stimmt, ich habe nach Sprache Deutsch gesucht, nicht nach Land Deutschland, und dabei die 231.000 ShellsCripts und die 244.000 ShellsKripts gefunden. Stimmt auch, im Land Deutschland werden 504.000 ShellsCripts gefunden - das sind aber fast doppelt so viele, wie bei der weltweiten deutschsprachigen Suche: In Deutschland werden eben auch englische Texte publiziert. Vielen Dank für den Hinweis auf den beleidigenden Charakter der sh/sch-Analogie, aber wenn du nur in Deutschland suchst (ich hatte den falschen Link kopiert), wirst du 51.900.000 Mal engliSCH [5], aber 203.000.000 Mal - fast viermal so oft! - engliSH [6] finden. ;-) (Diesmal vergesse ich den Smiley nicht, aber soo schlecht ist die Analogie nicht, denn auch das ist nur eine Google-Suche in Deutschland.)

Der Sache nach ist es mir völlig egal, ob Skript mit c oder mit k geschrieben wird. Ich wollte nur darauf hinweisen, dass ich keinen Grund sehe, einen Artikel umzubenennen oder gar umzuschreiben: Rein deskriptiv sind beide Varianten in reichlicher Zahl vorhanden; bei Shellskript dominiert laut Google (nicht ich habe auf Google hingewiesen) in deutschsprachigen Dokumenten das K, bei Skriptsprache das C. Normativ - wenn man normative Grammatik betreiben will - scheint mir eher das K korrekt zu sein: Das englische Wort script wird im Deutschen als Skript ausgesprochen, und die deutsche Rechtschreibung bevorzugt bei eingedeutschten Fremdwörtern das Lautprinzip.

Viele Grüße, --GottschallCh 21:32, 16. Mär 2006 (CET)

@GottschallCh: Der english vs englsich Vergleich ergibt nun in der Tat eine ganz andere interessante Sicht – sehr merkwürdig.

Ich danke euch für eure Meinungs-Beteiligung, nach Anhörung mehrerer überzeugender Argumente (auch außerhalb der Wikipedia), ziehe ich ebenso als Folge dieser mein Änderungsvorhaben mit der nun geklärten Absicht zurück. @Blauebirke: Vielleicht war meine übertriebene Aussage eine Resonanz-Hascherei.

Fazit: Obwohl beide Schreibweisen sehr geläufig sind, ist das Ergebnis eine klare Aussprechung/ Entscheidung für die rein deutsche (vermeintlich „eingedeutschte“) Schreibweise und nicht der denglischen. In diesem Zusammenhang möchte ich noch dem sehr hilfreichen Meinungsbild der de.comp.lang.python News-group danken. MfG -- Ολλίμίνατορέ ^Ω 21:49, 17. Mär 2006 (CET)

Mann, warum macht ihr's nicht gleich richtig?? Scheißegal ob Google dort oder da mehr oder weniger Treffer für "Script" bzw. "Skript" ausspuckt! Fakt ist, "Script" ist korrekt, da es ein englischer Begriff ist. Das Wort "Skript" bedeutet vielmehr 'zusammengetackerte Papierbögen, die man in Vorlesungen von seinen Profs ausgeteilt bekommt'. FAZIT: Es heißt "Scriptsprache" oder - ganz genau - "Script-Sprache. --(nicht signierter Beitrag von 84.158.127.72 (Diskussion) 14:23, 17. Mai 2006 (CEST))

Bin fuer Umbenennung. Also Scriptsprache statt Skriptsprache. Oder eben Script-Sprache. Script ist ein Fachbegriff. Beim Lesen ist bei Verwendung von 'Script' direkt klar, dass es sich um ein Programm-Script handelt und nicht um einem Skript zur Vorlesung. Skript ist moeglicherweise inzwischen auch etwas verbreitet in gewissen Kreisen. Aber Standart statt Standard ist auch weit verbreitet. Vielleicht schauen ja auch einige Leute in der Wikipedia nach und orientieren sich an der dortigen Schreibweise des Lemmas ... --Gms 11:31, 14. Nov. 2009 (CET)

Dieser Abschnitt kann archiviert werden. Grund: Am 17. März 2006 vom Fragensteller als erledigt deklariert. --Anton Sachs (Diskussion) 15:15, 27. Jan. 2020 (CET)

Templates

Nach meiner Auffassung werden Templetes schon deklariert. So z. .B. der Code aus dem Artikel(Template):

template <typename T>
T max(T x, T y)

Hier werden x und y als Templetes deklariert. Wenn ich also z=0 schreibe führt dies immernoch zum Fehler (wenn nicht vorher T z, int z oder ähnliches steht). Dies ist nicht anders als bei OO-Sprachen Variablen vom Typl Object zu deklarieren. Bei Skriptsprachen ist dies jedoch anders. Da kann ohne Probleme eine Variable einen Wert zugeordnet werden. Mich verwundert hier auch, dass VisualBasic hier als nicht Skriptsprache angesprochen wird. In früheren Diskusionen (#Umsetzung von Skriptsprachen als Interpreter) wurde VisualBasic als solche eingestuft. --Blauebirke 17:51, 20. Mär 2006 (CET)

Da es keinen Widerspruch gab, habe ich den Abschnitt gelöscht. --Blauebirke 05:32, 27. Mär 2006 (CEST)

Dieser Abschnitt kann archiviert werden. --Anton Sachs (Diskussion) 15:15, 27. Jan. 2020 (CET)

Scripting auf Betriebssystem-Ebene

Habe einen neuen Abschnitt Skriptsprache#Scripting_auf_Betriebssystem-Ebene eingefügt, mit Apples OSA und MS WSH. KDE und Gnome haben m. W. ähnliche Funktionalitäten, kann da jemand was zu beitragen? -- Stefan Bethke 00:07, 18. Jul 2006 (CEST)

Ich werde den Abschnitt wieder entfernen. Es ist zumindest etwas schwammig. Was ist genau die Betriebssystem-Ebene? Sind da nicht auch Shellscripte angesiedelt? "um beliebige Anwendungsprogramme durch Scripte zu steuern." -- habe ich meine Zweifel. Müssen da die Programmierer nicht die Bindungen dafür schreiben? Dachte ich zumindest. Übrigens KDE und GNOME sind keine Betriebssysteme und die beiden skripten sehr gerne mit Python (z. B. bei den Widgets). Könnte man den Abschnitt vielleicht etwas präzesieren? Und Entschuldigung, dass ich etwas ungläubig bin. --Blauebirke ☕✍  01:36, 18. Jul 2006 (CEST)

Dann drücke ich mich wirklich zu unklar aus. OSA und WSH sind jeweils ein Framework, daß die Steuerung beliebiger (konformer) Anwendungsprogramme unter Mac OS bzw. Windows erlaubt. Der Anwendungs-Entwickler muß für die Steuerbarkeit i. d. R. nichts oder nur sehr wenig tun, was über die normale Definition von Befehlen (Menüeinträgen, etc.) und die Event-Abarbeitung hinausgeht. Die typischen Frameworks/Klassenbibliotheken) (MFC, ...) unterstützen dabei selbstverständlich. Damit sind unter Windows und unter Mac OS praktisch alle Programme steuerbar. Skriptsprachen brauchen natürlich entsprechende Bindings an OSA/WSH, damit sie da mitspielen können, die gibt's aber für alles gängige (Perl, Python, …).

Ich meine mich zu erinnern, daß in Gnome und KDE ähnliche Mechanismen zur Verfügung stehen, habe aber keine Quellen dazu.

Betriebssystem ist vielleicht der falsche Begriff, eher schon die graphischen Oberfläche. -- Stefan Bethke 15:46, 18. Jul 2006 (CEST)

Danke. So macht es auch für mich Sinn (und es sollte auch unbedingt in den Artiekl). Leider habe ich auch nichts zu GNOME und KDE gefunden. Die Frage ist noch, ob dies nicht besser als Abschnitt in Skriptsprachen verschiedener Programme untergebracht werden sollte (da u.a. keine Skriptsprachen unter Beispiele stehen). Z. B. "Darüberhinaus können Skriptsprachen über ein Framework (z. B. WSH unter Windows und OSA unter Mac) ..." Wahrscheinlich kannst du das besser formulieren als ich. Ist nur so eine Idee. --Blauebirke ☕✍  21:52, 19. Jul 2006 (CEST)

Ich habe den Absatz

Darüberhinaus können Skriptsprachen über ein Framework (z. B. WSH unter Windows oder OSA unter Mac) die Programme steuern, indem die selben Funktionen aufgerufen werden, wie bei der Interaktion mit einem Widget (z. B. der Klick auf einem Button).

wieder entfernt weil er technisch falsch ist.

Unter Windows funktioniert diese Art von Skripting über COM und ist vom WSH unabhängig. Es ist der gleiche Mechanismus, der im Internet Explorer (Active Scripting), in diversen Applikationen (u.a. Microsoft Office) als Makrointerpreter (Windows Script Componentens), im IIS (ASP), im WSH, etc. zum Einsatz kommt. Und in allen diesen Anwendungsfällen kann man theoretisch das gleiche machen (z.B. kann man vom IE aus oder über ASP Microsoft Word skripten). Das ganze ist skriptsprachen-unabhängig - für die eigentliche Skriptausführung werden Script Engines verwendet. Script Engines für VBScript und JScript werden mit Windows mitgeliefert, es gibt aber u.a. auch PerlScript und RexxScript. Wenn man eine zusätzliche Script Engine installiert, dann können alle oben genannten Applikationen Skripte in der neuen Sprache ausführen (z.B. ermöglicht PerlScript die Ausführung von Perl-Skripten u.a. im IE).

Damit das ganze funktioniert (d.h. damit man Applikationen von außen skripten kann) müssen die Applikationen passende COM-Komponenten implementieren, sonst geht gar nichts.

Unter Mac OS ist die Sachlage ähnlich. Es gibt einen systemweite Skriptinterpreter für AppleScript, es können theoretisch auch andere Skriptinterpreter in OSA eingebunden werden (ich kenne nur einen Interpreter für JavaScript, evt. gibt es noch andere). Applikationen können analog Windows die Skriptinterpreter einbinden.

Damit sich Applikationen skripten lassen, müssen sie spezielle Apple Events verarbeiten. Diese Apple Events werden von OSA an die Anwendungen gesendet und können ident zu den Befehlen des GUIs sein oder auch nicht.

Jedenfalls sollte das mit dem WSH und "wie bei der Interaktion mit einem Widget" umgeändert werden.

GNOME kann man auch skripten, allerdings ist das Verfahren nicht so ausgefeilt wie unter Windows bzw. Mac OS. Unter GNOME funktioniert das ganze über Bonobo und entsprechende Skriptsprachen-Bindings (Perl, Python, ...). Bonobo ist COM unter Windows recht ähnlich.

Unter KDE geht's mittels KParts und entsprechenden Skriptsprachen-Bindings. Das ganze ist ähnlich GNOME

In allen vier Fällen ist das Verfahren letzlich GUI unabhängig, d.h. man kann das auch in Textmodus-/Kommandozeilenprogrammen oder (unsichtbaren) Services/Daemons einsetzen.

Falls jemand mein Geschreibe in allgemein verständliche Worte übersetzen kann => bitte einbauen

-- 62.178.136.129 03:28, 30. Aug 2006 (CEST)

Merkmale

implizit deklarierte Variablen; dazu gehören auch dynamische Funktionsnamen (Funktionsnamen müssen nicht einem Compiler vorab bekannt sein)

das mag vielleicht für php oder tcl stimmen (tcl ist im punkt der speicher-/resourcenverwaltung nur ne halbe skriptsprache).... ansonsten ists für sachen die über ein "hello world" hinausgehen hinderlich und alles andere als hilfreich Ich wäre dafür den Punkt rauszulöschen, weil er eine Schwäche div. Sprachen ist und keine Stärke -- Monoxyde 20:51, 20. Jul 2006 (CEST)

Ein Merkmal bleibt ein Merkmal, egal ob es eine Stärke oder Schwäche ist. Es ist einfacher für eine Sprache zu fordern, dass vorab bekannt sein soll von welchem Typ eine Variable ist. Daher kann man davon ausgehen, dass die sich schon was dabei gedacht haben und es nicht eine Schwäche (zu mindest nicht in allen Situationen) ist. --Blauebirke ☕✍  01:29, 21. Jul 2006 (CEST)

Fehler

"Funktionsnamen müssen nicht einem Compiler vorab bekannt sein"

Das ist falsch, Skriptsprachen werden interpretiert! Niemals compiliert... wenn ich compileren würde, dann kommt am ende Binärcode raus...
Daher gelöscht! (nicht signierter Beitrag von 77.25.38.6 (Diskussion) 22:52, 29. Aug. 2008 (CEST))

Häufige Merkmale

Ich halte die Liste auch für höchst fragwürdig... automatisches Speichermanagement sollte in keiner modernen Sprache fehlen (c#, java), genau so ist es fragwürdig ob eine dynamische typisierung wirklich etwas damit zu tun hat (smalltalk, objective c) (nicht signierter Beitrag von 85.180.8.170 (Diskussion) 21:47, 21. Okt. 2008 (CEST))

Ausgeliefert?

Im Artikeltext steht: Skripte werden fast ausschließlich in Form von Quelltextdateien ausgeliefert. Könnte vielleicht jemand das Wort ausgeliefert so umformulieren, dass man eine Vorstellung davon bekommt, was damit gemient ist? Vielen Dank. -- 84.132.119.103 23:01, 4. Nov. 2008 (CET)

Ferner steht im Text: So wird etwa in Skriptsprachen auf den Deklarationszwang von Variablen verzichtet. Wäre demnach Basic ein Script? -- 84.132.119.103 23:05, 4. Nov. 2008 (CET)

Relevanz einzelner Beispiele

Ein leidiges Thema...
Jedenfalls habe ich Euphoria, Squirrel und Croc zu den Beispielen hinzugefügt und Chricho hat sie wieder gelöscht, mit der Begründung "bitte nur die gängigsten beispiele".
Allerdings sind zumindest die ersten beiden Beispiele viel bekannter, als irgendwelche Batchsprachen aus den 80 wie REXX, propritäre Skriptsprachen wie AutoIT, Sleep oder irgendwelche Lisp-Dialekte.
Daher mein Vorschlag: Lasst sie alle drin oder dünnt diese SINNVOLL aus, aber nicht sowas.
--146.60.186.36 18:37, 24. Feb. 2012 (CET)

Ein Problem gibt es hier m. E. weniger in Fragen der Relevanz, als viel mehr solcher der Redundanz. Denn für meinen Geschmack ist jedes Beispiel relevant genug, für das sich seriöse Quellen finden lassen. Alles weitere ist bloß Eigenperspektive, Geschmack und schlechterenfalls schlichtes Vorurteil. Die Aufführung "allgemein verwendbarer Sprachen" am Ende des Artikels allerdings verwehrt sich meinem Verständnis total. Nahezu jede der hier genannten Sprachen ist "allgemein" verwendbar und nahezu jedes der dort angeführten Beispiele wird im Artikel an anderer Stelle doch schon genannt, teilweise sogar häufiger als ein Mal. Was soll das bitte bringen, manche Sprachen hier drei od. vier Mal zu erwähnen? Tcl findet sich gleich fünf Mal als Beispielpunkt! *g* Und was ausgerechnet Lisp (v. a. welches denn?) da unten jetzt verloren haben soll - naja. Problem ist, dass der ganze Artikel viel zu verbeispielt ist. Wirkt ganz so, als hätte jeder mal kurz rangedurft, brav seinen persönlichen Liebling einzutragen. Das ist schon ganz nett, aber dieses reine Name-dropping ist denke ich nicht sehr hilfreich, wenn es darum geht, sich nur mal darüber zu informieren, was eine Skriptsprache eigentlich ist, oder was sie ausmacht. Blöderweise nur ist der Artikel auch dann (und dann erst recht) nicht interessanter, wenn man das bereits weiß. Von mir aus eine Tabelle/Liste mit (allgemeinen) Beispielen, von mir aus 30.. und dann stichpunktartig die besonderen Arten v. Skriptsprachen abarbeiten; zur Veranschaulichung könnte man sich da dann jeweils ein, zwei (entspr.) Beispiel/e aus besagter Tabelle oder Liste herausgreifen. Das wäre ökonomisch, v. a. wäre es übersichtlicher. Ist aber nur meine Meinung. -- Zero Thrust (Diskussion) 01:34, 29. Mai 2012 (CEST)

gudn tach!

meiner meinung nach hoert sich das nach einer guten idee an, wie man den artikel verbessern koennte. sei mutig. -- seth 12:25, 7. Jun. 2012 (CEST)

BASIC

Ist BASIC nicht auch eine Skriptsprache? Jedenfalls lese ich im dortigen Artikel mehrmals von einem BASIC-Interpreter. --Dsdvado (Diskussion) 14:03, 20. Jul. 2019 (CEST)

Ein BASIC kann eine Skriptsprache sein, muss es aber nicht. Seit QuickBASIC kann man ja auch Basic-Quelltext kompilieren, und dann ist es natürlich kein Skript mehr. Allerdings kann man Basic-Skripte an den Interpreter übergeben, dann hat man etwas sogut wie einen Skript, denn die "Magie" hängt vom Betriebssystem ab. Siehe etwa Shebang unter Unix...

Nichtsdestotrotz war GW-BASIC eine astreine Skriptsprache, QuickBASIC war jedoch bereits eine IDE, die aus Kompatibilitätsgründen noch wie eine Skriptsprache genutzt werden konnte. Es gibt jedoch weit mehr BASIC-Implementierungen, nicht nur jene von Microsoft...

Siehe auch Liste von BASIC-Dialekten: Zu den Einsatzfeldern von BASIC zählen die frühen Heimcomputer, bei denen BASIC auch zugleich als Systemoberfläche diente, die Verwendung als allgemeine Programmiersprache, teilweise auch mit Unterstützung objektorientierter Techniken, die Nutzung als Skriptsprache alleinstehend oder im Rahmen einer Anwendung und eingebetteter Systeme.

‣Andreas•⚖ 18:38, 20. Jul. 2019 (CEST)