sma hat geschrieben: Er erwähnte daher noch Lua als eine fertige und bewährte Alternative (inklusive JIT).
da kennt Lanx sich nicht aus, und muss Larry Wall zu
zitieren:
Sadly, I must confess I never looked closely at Lua or AppleScript, probably because I'm not a game designer with a Mac.
sma hat geschrieben:Python *vollständig* in JavaScript abzubilden - ich habe das mal beispielhaft probiert - funktioniert nicht gut (im Sinne von effizient), weil Python zu dynamisch ist. ...
Klar für eine vollständige Abbildung müsstest du das Objektmodel komplett emulieren! Ich vermute die bereits verlinkten py->js projekte versuchen dass auch, indem das erzeugte JS immer explizit getter und setter aufruft.
Die unterschiedlichen Typkonversionen sind sicher auch eine Bremse, schlimstenfalls müsste man in zeitkritischen Passagen den Weg gehen den Cython bereits vormacht, und statische Typen angeben.
Meine Vorstellung wäre eher erstmal eine Schnittmengensprache des größten gemeinsammen Nenners zu haben, die auf beiden Engines problemlos läuft.
Übrigens, steht in der Wikipedia ernsthaft, JS ist eine "moderne" Sprache?
naja modern und etabliert schließen sich doch wohl aus...
LanX hat geschrieben:Wenn Brendan Eich der Schöpfer von JS ist, dann ist Crockford sein Prophet.
Meines Wissens (jedenfalls vermitteln sie mir diesen Eindruck durch ihre Talks) mögen die beiden sich aber jetzt nicht so.
kenne die Talks nicht kann ich mir gut vorstellen.
während Eich als Mozilla-Mann für HTML 5 und die bunte neue Welt der Webentwicklung ist und ASAP die nächste JS-Version raushauen möchte, die ein paar mehr von den Features enthält, die Rhino und die ganzen Monkeys jetzt schon können: Yield und Generatoren, List-Comprehension, Mehrfachzuweisungen, Let, usw.
hmm ich muss mir endlich mal Rhino antun
Crockford hat bestimmt nichts gegen
let, wenn man bedenkt wie sehr er mit
var hadert und polemisiert.
Mozillas MDC zu JS1.5++ versucht IMHO doch meistens bei neuen Sprachkonstrukten Code anzubieten, der es in anderen Umgebungen Rückwärtskompatibel macht.
(BTW: danke auch für den Hinweis auf
let, das stopft tendenziell mein momentan größtes Problem Perls
my auf JS'
var abbilden zu können. xD
Man sieht auch, JS entwickelt sich weiter, sodass fremde Pattern künftig einfacher integriert werden können. Da ist eine Koevolution im Gange.)
Zum Thema kein Blockscoping mit
var: Es ist schon anstrengend, wenn man ständig eine anonyme Funktion erzeugen muss, die in-place aufgerufen wird, nur um einen geschlossenen Blockcope zu haben.
Code: Alles auswählen
// Make a function that assigns event handler functions to an array of nodes the right way.
// When you click on a node, an alert box will display the ordinal of the node.
var add_the_handlers = function (nodes) {
var i;
for (i = 0; i < nodes.length; i += 1) {
nodes[i].onclick = function (i) {
return function (e) {
alert(i); // jeweils andere Instanz von i
};
}(i); // Workaround für Blockscopes
}
};
(BTW: wie würde man das in Python lösen? Mit nem Lambda, oder?)
(Bei Brendan Eich ...) Ich glaube daher, das meiste war Zufall kombiniert mit Erfahrung (also Intuition) und weniger eine bewusst herbei geführte und getroffene Design-Entscheidung.
yup! Und Crockfords Verdienst ist dass er viele Konstrukte klarer beschreibt. Aber man muss nicht wirklich jeder seiner "Exkommunikationen" folgen, z.B. hat
with durchaus auch Vorteile.
