Tut mir leid, ich kanns nicht lassen.
Zitat:
OK, dann versuch mal bitte ein Java Programm mit mehreren Millionen Datensätzen binnen kurzer Zeit zu hantieren, oder aber XML-Dateien so um die 50 Megabyte mit XInclude zu vereinen und dann via XSLT umzuwandeln, da wirst Du sehen, wie Java alle viere von sich streckt.
Ja, Java hat ein Heap-Limit. Es gab schon diskussionen dieses von 64m zu erhöhen, da dieser Wert nicht mehr angemessen erscheint.
Python kann übrigends nicht mit mehr als 2G ram umgehen, nicht mal auf 64-bit maschienen. Naja, was solls.
Zitat:
Python ist nicht wirklich eine interpretierte Sprache, da man mit den pyc/pyo-Dateien genau wie bei Java auch nur den Bytecode zum ausführen braucht.
Im standardbetrieb ist Python total interpetiert. Zuerst wird der Python-Code in Python-Bytecode umgewandelt und danach erst interpretiert. Ob du jetzt die Compilier-Phase weglässt oder nicht, die bytecodes werden interpretiert.
Zitat:
Zum Thema psyco: Das ist ja auch nicht ganz trivial, immerhin muss man da ja ganz nah an den Kernel, um das benutzen zu können. Unter FC1 bspw. funktioniert es mit dem Standardkernel in der Standardkonfiguration gar nicht, weil hier ein exec-Shield drüber liegt, der die Arbeit von psyco verhindert. Wenn man den ausschaltet, geht es aber prima.
Drum wäre es nicht schlecht, wenn es eine distribution mit psycho gleich drinnen gäbe.
Zitat:
Das sind alles Punkte, die IMHO Python besser machen.
Das war ein einziges Argument, nämlich das mit dem Heap-Limit. Gut ist Geschmackssache, 64m sind aber definitif etwas wenig, ich wäre für 128m auf desktop und 256 für server-jvm.
Ich glaube du hast mich falsch verstanden. Die Sprache python finde ich an sich sehr gut und durchdacht, nur die Laufzeitumgebung ist meiner Ansicht nach (und damit meine ich meine Ansicht, deiner Ansicht nach mag sie topaktuell sein) sehr veraltet.
Gerade auf dem gebiet der interpretierten Sprachen hat es in den letzten 10 jahren sehr viel Forschung gegeben, gerade was adaptive Kompilierung und Garbage-Collection angeht.
Python ist noch eine Virtual Machine die gebaut ist, wie man eben VMs vor dieser Zeit ausgelegt hat.
Das sieht man z.B. auch bei Servern: Zope hat bei statischen Inhalten gerade mal 1/4 des Datendurchsatzes von Tomcat, bei dynamischen Inhalten wirds noch schlimmer.