moritz+2007-09-19 16:48:40--

Naja, alle Sprachen, die ein String-Eval anbieten, müssen den kompletten Interpreter/Compiler mit einlinken, wenn sie eine ausführbare Datei erstellen. Was die Hauptvorteile einer executable wieder zunichte macht.

Och nicht unbedingt.
Das der Interpreter lediglich mit gelinkt wird, muss ja nicht bedeuten das der Interpreter letztendlich auch läuft, er muss ja nur aktiv werden wenn ein String eval vorkommt. Von der Geschwindigkeit profitiert man also immer noch.

Und weiterhin kann man das Programm ohne Probleme verteilen. Und das wären für mich die beiden wichtigsten Hauptargumente. Wobei mir letzteres meist schon eher wichtiger ist.

Quote

Und in einem Eval kann wieder ein 'require' vorkommen, d.h. man müsste alle verfügbaren Module mit einkompilieren...

Insgesamt sehe ich zwei Lösungen für das Problem.
1) String eval wird nicht Supported für Binaries.
2) Du gibst wie bei einem C-Kompiler einfach zusätzlich an welche Libraries mitgelinkt werden sollen. Als Programmierer deines eigenen Programmes sollte man schon wissen welche Module Möglicherweise über einen String eval eingebunden werden können. Also musst du wenn man soetwas exotisches nutzt auch die Möglicherweise verwendeten Bibliotheken einfach mitlinken, so müssen jedenfalls nicht "alle" Bibliotheken mitgelinkt werden.

Quote

Das wird die Zeit zeigen. Aber ich glaube im Moment nicht daran, dass man aus Perl6-Programmen Binarys compilieren können wird, die z.B. mit compiliertem C(++)-Code konkurieren können, dafür sind Sprachen wie Perl einfach zu dynamisch. Aber einen Compiler für Parrot wird es auf jeden Fall geben.

Och da bin ich mir ehrlich gesagt nicht so sicher. Bzw. hat das Compilieren erst bei der Ausführung oder die Nutzung einer VM noch Vorteile wodurch man rein theoretisch z.B.: C übertrumpfen kann.

Als erstes wird es ja in Perl6 Möglich sein für alles explizit etwas anzugeben. Sprich Integer, Double oder sonstetwas, so das er hier auch sparsam Speicher reservieren kann und das ganze Optimieren kann.

Und die verwendung einer VM hat neben der Portablität noch den Vorteil das es sein System kennt auf den es läuft. Häutige Programme z.B. werden immer noch für z.B. 386er Prozessoren compiliert. Damit es auch bloß noch auf alle Möglichen alten CPUs läuft. Eine VM hat aber den Vorteil das es das System kennt, es kennt den CPU, weiß wieviel RAM du hast etc. Und speziell daraufhin kann es den Code nochmals optiemieren auf deine CPU. So wird dann die Funktionalität einer 64bit CPU oder von 686er CPUs genutzt wenn diese Verfügbar sind, dadurch kann man letztendlich ein höhere Performance erziehlen als entsprechende C Programme.


Allerdiengs muss man zu allem sagen, wer will schon unbeingt native Binaries? Das einzige Problem was ich an Perl 5 finde ist die verbreitung. Das ist natürlich noch "Unix/Linux" Typisch. Du musst die VM haben und alle Möglichen Bibliotheken musst du auch installiert haben. Wenn diese nicht vorhanden sind muss sich der Anwender diese selbe installieren, was auch schonmal haarig sein kann.

Java hat da ein gutes System. Man benötigt nur die Haupt VM und in den jar stecken dann einfach alle weiteren Module die benötigt werden. So kann man Programme auch einfach weitergeben indem man sagt du musst die VM installiert haben, und anssonsten einfach ein tar.gz entpacken und starten.

par baut das natürlich schon nach für Perl 5 allerdiengs wäre es nett wenn soetwas in Perl 6 fest eingebaut werden würde.


Native Binaries interessieren mich eigentlich nicht so, da sie nicht mehr Portabel sind. Und von der Geschwindigkeit her müssen VMs auch nicht deutlich langsamer sein. Und in vielen Fällen ist die Performance auch nicht der Knackpunkt.