Warum so viele Programme mit eigenen Scriptsprachen?

[Karl]

Hi.
Mir fällt immer wieder auf, dass es so viele Programme gibt, die ihre eigene Scriptsprache speziell für das Programm entwickelt haben, wie zum Beispiel mIRC. Warum benutzen die nicht einfach Sprachen wie zum Beispiel Python, die sich (nach dem was ich gehört habe) ja auch relativ problemlos als Scriptsprache einbinden lassen?
Bei mIRC kann ich's ja noch verstehen, das ist auch schon etwas älter.
Aber nehmen wir mal ein Spiel, zum Beispiel Warcraft 3. Das hat einen eigenen Editor mit einer eigenen Scriptsprache (Jass), die absolut scheiße ist.
Was hindert Spieleentwickler daran, Sprachen wie Python als Scriptsprache in ihren Editoren zu benutzen?
Es gibt ja anscheinend einige (OpenSource-)Programme, die Python als Scriptsprache benutzen.
Wäre cool, wenn ihr mich aufklären könntet

[Leonidas]

Mir fällt immer wieder auf, dass es so viele Programme gibt, die ihre eigene Scriptsprache speziell für das Programm entwickelt haben, wie zum Beispiel mIRC. Warum benutzen die nicht einfach Sprachen wie zum Beispiel Python, die sich (nach dem was ich gehört habe) ja auch relativ problemlos als Scriptsprache einbinden lassen?

Bei mIRC schätze ich mal, hat Khaled Mardam-Bey sich nicht sonderlich viele Gedanken gemacht, dementsprechend grausam ist die Sprache dann auch geworden. Außerdem waren damals, wie du sagtest, solche Sprachen nicht so der Hit. Python einzubetten ist außerdem von der größe nicht ganz so simpel: der Interpreter + Stdlib könnte sogar größer als mIRC selbst werden.

Aber nehmen wir mal ein Spiel, zum Beispiel Warcraft 3. Das hat einen eigenen Editor mit einer eigenen Scriptsprache (Jass), die absolut scheiße ist.
Was hindert Spieleentwickler daran, Sprachen wie Python als Scriptsprache in ihren Editoren zu benutzen?
Es gibt ja anscheinend einige (OpenSource-)Programme, die Python als Scriptsprache benutzen.

Wenn man die Sprache selbst schreibt, kann man sie so anpassen, dass sie für den Zweck am besten geeignet ist, also dass sie für häufig nötige Dinge bereits Abstraktionen bereitstellt. Also eine spezielle DSL.

Es gibt durchaus einige Spiele die Lua als Skriptsprache verwenden, weil es extra dafür gedacht wurde. Bei Sachen wie Linden Skript habe ich auch das Gefühl, dass es eher darum ging das Rad neu zu erfinden. Freie Software verwendet öfter etablierte Sprachen, weil es sie gibt und die Programmierer sich nicht die Mühe machen müssen das selbst machen zu müssen. Etwa eben Guile, Lua und Python.

Es gibt aber auch durchaus Sprachen, die extra für freie Software entwickelt worden sind, wie Emacs Lisp (das ist ein Lisp-Dialekt, nicht ganz eine neue Sprache und historisch bedingt) oder Vim-Script (hier geht es wohl darum, dass Vim-Script klein und schnell sein soll). Beide können aber auch mit Python gebediehnt werden, Vim unterstützt darüber hinaus auch Perl und Scheme.

[meneliel]

...
Aber nehmen wir mal ein Spiel, zum Beispiel Warcraft 3. Das hat einen eigenen Editor mit einer eigenen Scriptsprache (Jass), die absolut scheiße ist.
Was hindert Spieleentwickler daran, Sprachen wie Python als Scriptsprache in ihren Editoren zu benutzen?
...

Naja, also zumindest für WoW wird ja Lua als Scritpsprache benutzt ... geht ja auch

[shakebox]

meinem Eindruck nach ändert sich das gerade ja auch ein wenig, zumindest in meinem Tätigkeitsfeld, der Postproduction für Film und Fernsehen. Früher hatte da jedes größere Programm auch ne eigene Scriptsprache bzw. es wurde alles mögliche verwendet. Maya als 3D-Programm verwendete MEL, Nuke als Compositingapp verwendete TCL, usw.

Inzwischen gibt es in dem ganzen Bereich Highend-VFX einen deutlichen Trend in Richtung Python. Maya kann schon Python, Nuke kann es, usw.

Nach meinem langen Hin und Her, welche der vielen Sprachen ich mir denn aneignen soll, um aufwändigere Sachen zu machen als mit reinen Shell-Skripten möglich, war das natürlich mit ein ausschlaggebender Grund für Python. Wäre im VFX-Bereich eher Perl am Start, dann wäre ich jetzt wohl in nem anderen Forum

Insgesamt denke ich gibt es beide Tendenzen: viele verschiedene Skriptsprachen, manchmal aus "Faulheit" oder wenig Planung, manchmal auch einfach wie Leonidas ja sagt aus sinnvollen Überlegungen, weil man die Sprache ans Problem anpassen kann, nicht umgekehrt. Und andererseits auch die Erkenntnis in manchen Bereichen daß es niemandem hilft wenn jedes Programm was eigenes macht, vor allem in Bereichen wo Programme eben in nem Workflow zusammenarbeiten müssen.

[Karl]

Okay ...
Also dass Python mit den 10MB für kleinere Programme wie zB mIRC zu groß ist, stimmt schon.
Bei Programmen, die aber eh schon 5GB groß sind, macht's aber wohl auch nix mehr
Zu dem Punkt, dass eine eigene Scriptsprache optimierter und besser angepasst an das jeweilige Programm ist: Kann man denn Python nicht auch an das Programm anpassen? Die Arbeit dürfte ja auch nicht viel größer sein, als eine komplette Scriptsprache zu entwickeln.

Lua & Co hab ich noch nie gehört oO
Naja ich glaube aber auch, dass sich in Zukunft eher Sprachen rauskristallisieren werden, die sich für den Zweck als Scriptsprache besonders gut eignen und nicht mehr jeder seine eigene Sprache entwickelt.

Wobei, was mir grad einfällt, Python müsste gar nicht auf die eigene Standardbibliothek zurückgreifen können, sondern lediglich auf die Spielfunktionen, oder? Okay, ein paar Funktionen, sollte Python schon noch haben, aber dann ließen sich die 10MB doch auch nochmal deutlich verringern, oder?

[Sr4l]

Ich hatte mal ein Python welches in eine C Gameengine eingebettet war.
Das war Python 2.3 und relativ genau 1,5MB groß.


Um zu sehen was das kleinst mögliche ist, müsste man einfach mal ein minimales Beispiel von http://docs.python.org/ext/embedding.html machen und kompilieren.

[Leonidas]

Zu dem Punkt, dass eine eigene Scriptsprache optimierter und besser angepasst an das jeweilige Programm ist: Kann man denn Python nicht auch an das Programm anpassen? Die Arbeit dürfte ja auch nicht viel größer sein, als eine komplette Scriptsprache zu entwickeln.

Es geht ja auch nicht um Bibliotheken, sondern um die Syntax der Sprache. Wenn du die änderst, ist es auch nicht mehr Python, sondern irgend etwas anderes.

Lua & Co hab ich noch nie gehört oO

Lua ist eine (nicht so besonders großartige, im vergleich mit anderen weniger bekannten Sprachen) Sprache die extra für embedding gedacht wurde.

Wobei, was mir grad einfällt, Python müsste gar nicht auf die eigene Standardbibliothek zurückgreifen können, sondern lediglich auf die Spielfunktionen, oder? Okay, ein paar Funktionen, sollte Python schon noch haben, aber dann ließen sich die 10MB doch auch nochmal deutlich verringern, oder?

Sicher, aber je mehr du entfernst, desto weniger bestehende Python-Programme und Libs laufen dann auf diesem Python und damit nimmt der Nutzen immer mehr ab.

[Rebecca]

Blender geht da einen Mittelweg: Es liefert ein minimales Python mit, und fuer Bibliotheken, die nicht zum Blender-Umfang gehoeren, kann dann auf eine vorhandene Python-Installation zurueckgegriffen werden. Wobei man in den meisten Faellen mit den Blender-spezifischen Bibliotheken aber ganz gut auskommt.

[Karl]

Sicher, aber je mehr du entfernst, desto weniger bestehende Python-Programme und Libs laufen dann auf diesem Python und damit nimmt der Nutzen immer mehr ab.

Ja, aber wenn man nur das drinnen lässt, was man wirklich braucht (Die ganzen Module um auf Netzwerke zuzugreifen etc braucht man dann wohl auch eher nicht mehr), kann man die größe aber sicher noch einiges runterdrücken ... Und die 1.5mb wie Sr4l sagt, kann man dann in der heutigen Zeit auch gut verkraften
Aber okay, das ist schon fast Offtopic, da die Größe sicherlich nicht das Hauptargument ist, wo wir doch eigentlich von eher größeren Programmen sprechen, weil die meisten kleineren Programme auch keine Scriptsprache benötigen.

[Leonidas]

(Die ganzen Module um auf Netzwerke zuzugreifen etc braucht man dann wohl auch eher nicht mehr)

Warum nicht? Stell dir vor, ich habe ein Programm welches Termine verwaltet. Dann könnte ich mittels XML-RPC, FTP oder ähnlichem meine Termine durch ein Skript online stellen. Und an dieser Stelle brauche ich die Netzwerkmodule.

[jens]

meinem Eindruck nach ändert sich das gerade ja auch ein wenig, zumindest in meinem Tätigkeitsfeld, der Postproduction für Film und Fernsehen.

Ja das stimmt, es gibt einen Trend zu Python. Neben Maya gibt es auch in Houdini und SOFTIMAGE|XSI Python... Leider hat 3dsmax noch immer seine eigene Skriptsprache, die sehr inkonsistent ist. Ich hoffe ja mal, das dort auch irgendwann mal Python unterstützt wird. Ich selber hab zwar auch ein paar maxscripts gebaut, aber wirklich nur kleine Sachen. Es ist ein krampf!

[Karl]

(Die ganzen Module um auf Netzwerke zuzugreifen etc braucht man dann wohl auch eher nicht mehr)

Warum nicht? Stell dir vor, ich habe ein Programm welches Termine verwaltet. Dann könnte ich mittels XML-RPC, FTP oder ähnlichem meine Termine durch ein Skript online stellen. Und an dieser Stelle brauche ich die Netzwerkmodule.

Deshalb sagte ich "wohl eher" Es mag Programme geben, die diese Module benötigen, die lassen sie dann auch einfach drinnen :p
Aber gehen wir jetzt mal wieder von einem Spiel aus, das einen Editor mit einer Scriptsprache hat. Wofür sollte man dort die Netzwerkmodule brauchen? Gut, man kann es sicher _irgendwo_ mal brauchen aber die meisten Spiele bieten sowas ja auch nicht in ihren Scriptsprachen an (glaub ich). Und das war ja auch nur ein Beispiel, es gibt bestimmt noch genug andere Module, auf die ein Programm verzichten kann, welche das dann sind, hängt natürlich vom Programm ab.

[Leonidas]

Und das war ja auch nur ein Beispiel, es gibt bestimmt noch genug andere Module, auf die ein Programm verzichten kann, welche das dann sind, hängt natürlich vom Programm ab.

Eben. Je mehr Module du entfernst, desto unflexibler wird das. Da war erst letztens die Diskussion, dass Google in seiner App Engine Module weggelassen hat mit dem Effekt das etwa einige Templatesprachen nicht mehr darauf funktionieren.

Es ist eben so: das Python so angenehm zu nutzen ist, liegt eben nicht nur an der Sprache selbst, sondern auch am "batteries included". Der Ansatz von Blender ist da vielleicht ein guter Kompromiss.

[Karl]

Es ist eben so: das Python so angenehm zu nutzen ist, liegt eben nicht nur an der Sprache selbst, sondern auch am "batteries included". Der Ansatz von Blender ist da vielleicht ein guter Kompromiss.

Nur wird der auch nicht immer funtkionieren. Aber wie gesagt, das ist eigentlich nicht das, worauf ich eigentlich hinaus wollte. Sicherlich ist das ein Grund für einige Programme, eine eigene, kleine Scriptsprache zu entwickeln, aber wenn ein Programm schon 100mb oder mehr umfasst, kann man die paar mb auch wirklich noch verkraften, außer es muss unbedingt auf ein weit verbreitetes Medium passen (zB die 700er Grenze bei CDs) und die würde dadurch überschritten werden. Aber dann kann man eventuell auch an anderen Dingen sparen. Wie auch immer ...

[sma]

Andere Gründe für Eigenentwicklungen können Unkenntnis vorhandener Alternativen sein, oder der Spass daran, es selbst zu machen, oder sich nicht an Releasezyklen, Bugfixingzeiten, usw einer existierenden Sprache zu binden, oder die gefühlte Akzeptanz einer Sprache in der eigenen Community oder einfach die Einschätzung, dass man's schneller selbst hinbekommt, als wenn man jetzt einen doch recht komplexen und großen Quelltext wie ihn etwa CPython hat, Zeile für Zeile durchschauen muss, ob der auch den eigenen Sicherheitsanforderungen genügt.

Ich habe hier den Quelltext von Python 2.5.1 auf der Platte und das Verzeichnis hat eine Größe von 50 MB. Das ist schon mal beeindruckend. Das Ding so zu patchen, dass nur der Teil gebaut wird, den man haben will, das irgendwie in den eigenen Build-Prozess zu integrieren (ich hatte mal naiv probiert, Python mit Eclipse ohne Makefile zu bauen, das geht aber gar nicht) kann abschreckend wirken. Die 1 MB von Lua sind da z.B. schon handhabbarer.

So wirklich kann ich's aber nicht beurteilen, da ich (freiwillig) kein C programmieren würde, das letzte Mal viele Jahre her ist und mich daher wohl nicht in die Denkweise eines C-Entwicklers hineinversetzen kann. In Java hätte man eher das Problem, dass die ausgesuchte Scriptsprache nicht oder nicht in der gewünschten Qualität zur Verfügung stände und man somit entweder JavaScript benutzen kann oder etwas selbst bauen kann. Ein eigenes Lua zu bauen, wäre dort nicht so schwer, ich hatte das mal in 2 Tagen gemacht. Eine weitere interessante Sprache wäre Io, dafür kann man sich auch einen Interpreter in Python bauen ;)

Stefan

[BlackJack]

Für Java bzw. die JVM gibt's gar nicht mal so wenige Sprachen: http://www.robert-tolksdorf.de/vmlanguages.html

C-Programmierer machen ja gerne alles selbst, wenn sie dadurch externe Abhängigkeiten einsparen.

Auch ein Grund für eine eigene DSL ist sicher oft auch, dass sich das im Laufe der Zeit so entwickelt. Man hat eine Konfigurations"sprache". Dann möchte man dort Verzweigungen unterbringen. Und irgendwer hätte gerne ein Schleifenkonstrukt. Und schon hat man wieder mal eine Sprache erfunden. Am Anfang argumentiert man noch, dass eine "externe" Skriptingsprache mit Kanonen auf Spatzen geschossen ist. Bis es dann zu spät ist, und man eine turingvollständige Konfigurationssprache selbst gebaut hat.

[Leonidas]

In Java hätte man eher das Problem, dass die ausgesuchte Scriptsprache nicht oder nicht in der gewünschten Qualität zur Verfügung stände und man somit entweder JavaScript benutzen kann oder etwas selbst bauen kann.

In Java würden mir spontan Jython, JRuby, Groovy, Nice, Scala und Scheme (Bigloo) einfallen. Ich weiß nicht in wie weit die in Java-Programme embeddbar sind und nicht nur Bytecode generieren, aber ich denke dass es da sicher schon Leute gab, die das probiert haben.

[sma]

Theoretisch kannst du alles Einbinden, was JSR 223 erfüllt - das machen heutzutage die meisten Scriptsprachen. Dennoch sind Jython, JRuby und Groovy groß und heavy und ich würde keine Hand dafür ins Feuer halten, dass die sicher sind. Nice und Scala lassen sich nicht einbetten, Bigloo ebenfalls nicht, es gibt jedoch andere Scheme-Varianten, bei denen das besser geht. Am einfachsten ist aber IMHO das bereits erwähnte JavaScript (Rhino), da es explizit zum Einbetten entwickelt wurde und auch in der Größe noch überschaubar ist.

Stefan