Browser brauchen keine Skriptsprache...

[zilti]

...sondern eine Bytecode-VM entsprechenden APIs.
Wenn schon unbedingt alles in den Browser soll.

[GodsBoss]

> ...sondern eine Bytecode-VM entsprechenden APIs.
> Wenn schon unbedingt alles in den Browser soll.

Genau: HTTP, HTML, CSS, alles Klartext, aber der Code soll dann Bytecode sein. Ich bin dagegen.

Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

[Tapsi]

GodsBoss schrieb:
--------------------------------------------------------------------------------
> > ...sondern eine Bytecode-VM entsprechenden APIs.
> > Wenn schon unbedingt alles in den Browser soll.
>
> Genau: HTTP, HTML, CSS, alles Klartext, aber der Code soll dann Bytecode
> sein. Ich bin dagegen.

Welchen Vorteil hat BYte-Code, der lässt sich genauso durch decompiler zurückführen zu Quelltext ?! Ich habe noch nie verstanden warum alle immer so agro auf open source reagieren. Ich persönlich finde es gut, wenn Nutzer aus meinen Erfahrungen eigene Erfahrungen gewinnen. Deshalb dürfen sie auch in meinen Quelltext schauen, müssen aber eben auch die Lizenz, unter der mein Quelltext liegt, beachten.

Aber ich gehöre scheinbar auch zu der kleinen Minderheit der Open Source Leute ( BTW : <-- Open Source heißt nicht automatisch alles kostenlos )

while not sleep
sheep++

[zilti]

Tapsi schrieb:
--------------------------------------------------------------------------------
> GodsBoss schrieb:
> ---------------------------------------------------------------------------
> -----
> > > ...sondern eine Bytecode-VM entsprechenden APIs.
> > > Wenn schon unbedingt alles in den Browser soll.
> >
> > Genau: HTTP, HTML, CSS, alles Klartext, aber der Code soll dann Bytecode
> > sein. Ich bin dagegen.
>
> Welchen Vorteil hat BYte-Code, der lässt sich genauso durch decompiler
> zurückführen zu Quelltext ?!
Ganz einfach: 1. kann er programmiersprachenunabhängig sein, und 2. ist Bytecode viel performanter als echtzeit-interpretierter JS-Müll.

[zilti]

Darfst uns gerne noch die Gründe dafür nennen. Danke.

[GodsBoss]

> > > > ...sondern eine Bytecode-VM entsprechenden APIs.
> > > > Wenn schon unbedingt alles in den Browser soll.
> > >
> > > Genau: HTTP, HTML, CSS, alles Klartext, aber der Code soll dann
> Bytecode
> > > sein. Ich bin dagegen.
> >
> > Welchen Vorteil hat BYte-Code, der lässt sich genauso durch decompiler
> > zurückführen zu Quelltext ?!
> Ganz einfach: 1. kann er programmiersprachenunabhängig sein,

Oh, du möchtest nicht in JS programmieren? List of languages that compile to JS

> und 2. ist
> Bytecode viel performanter als echtzeit-interpretierter JS-Müll.

Genau, weil JS natürlich von jedem Browser Befehl pro Befehl ausgeführt wird und nicht etwa Optimierungen vorgenommen werden wie z.B. die Kompilierung zu Bytecode oder gar Maschinencode. Es existiert höchstens der Overhead beim erstmaligen Einlesen und Kompilieren.

Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

[GodsBoss]

> Darfst uns gerne noch die Gründe dafür nennen. Danke.

Ich habe die gleiche Anzahl Gründe wie du in deinem Erstbeitrag untergebracht.

Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

[Tapsi]

> > Welchen Vorteil hat BYte-Code, der lässt sich genauso durch decompiler
> > zurückführen zu Quelltext ?!
> Ganz einfach: 1. kann er programmiersprachenunabhängig sein,

Der ByteCode ist genauso unabhängig wie normaler Source-Code. Vielmehr müsste man meinen, dass die JVM/CLR durch ihre vielen Implementierungen auf diversen Systemen die Sprachen, die auf ihr laufen, erst richtig plattformunabhängig machen. Gleiches trifft aber, meiner Meinung nach, auch auf Sprachen wie JavaScript zu, die auch auf nahezu jedem System ein Interpreter vorweisen kann und daher auch sehr platformunabhängig laufen kann.

BTW: Im moment erreiche ich mit JS durch Rhino,V8,Nitro etc. mehr Platformen als zum Beispiel mit Java.


> und 2. ist Bytecode viel performanter als echtzeit-interpretierter JS-Müll.

Das ist nicht korrekt! Gerade die V8/Nitro Interpreter sind die schnellsten JS Interpreter die es gibt, die zu dem wie Java neuerdings auch eine JIT besitzen, um zur Laufzeit Maschinen-Code zu erzeugen. Dieser ist dann vom Level her ähnlich wie JVM Byte-Code, der ebenso zu Maschninen-Code zur Laufzeit umgewandelt wird.
Der von dir genannte Performance-Unterschied ( wenn man das so nennen darf ), ist ein Produkt der Sprachdefinition an sich. Das liegt daran, wie JS entworfen wurde. Daraus resultiert auch die Tatsache das JS zwingend langsamer ist, als zBsp die Konsorten Java/C#.

=================================================================

Bei OS geht es mir aber in vielerlei Hinsicht um Lernkomponenten. Ich finde OS daher gut, da ich von anderen lernen kann, wie man bestimmte Probleme löst. Des Weiteren kann man wirklich sehen wie gut jemand ist, oder ob er einfach nur rumfrickelt. Nicht zuletzt finde ich, dass Bugs oft schneller gelöst werden, wenn mehrere Augen auf den Source-Code schauen ( man selber wird ja schnell betriebsblind :P ).

while not sleep
sheep++



1 mal bearbeitet, zuletzt am 16.09.11 13:54 durch Tapsi.

[zilti]

Tapsi schrieb:
--------------------------------------------------------------------------------
> > > Welchen Vorteil hat BYte-Code, der lässt sich genauso durch decompiler
> > > zurückführen zu Quelltext ?!
> > Ganz einfach: 1. kann er programmiersprachenunabhängig sein,
>
> Der ByteCode ist genauso unabhängig wie normaler Source-Code.
Nein. Eine andere Programmiersprache nach JS zu kompilieren resultiert oft in sehr umständlichem, langsamem Code. JS hat gegenüber ByteCode einen entscheidenden Nachteil: Man muss direkt damit programmieren können.

> Vielmehr
> müsste man meinen, dass die JVM/CLR durch ihre vielen Implementierungen auf
> diversen Systemen die Sprachen, die auf ihr laufen, erst richtig
> plattformunabhängig machen. Gleiches trifft aber, meiner Meinung nach, auch
> auf Sprachen wie JavaScript zu, die auch auf nahezu jedem System ein
> Interpreter vorweisen kann und daher auch sehr platformunabhängig laufen
> kann.
>
> BTW: Im moment erreiche ich mit JS durch Rhino,V8,Nitro etc. mehr
> Platformen als zum Beispiel mit Java.
>
> > und 2. ist Bytecode viel performanter als echtzeit-interpretierter
> JS-Müll.
>
> Das ist nicht korrekt! Gerade die V8/Nitro Interpreter sind die schnellsten
> JS Interpreter die es gibt, die zu dem wie Java neuerdings auch eine JIT
> besitzen, um zur Laufzeit Maschinen-Code zu erzeugen. Dieser ist dann vom
> Level her ähnlich wie JVM Byte-Code, der ebenso zu Maschninen-Code zur
> Laufzeit umgewandelt wird.
Ja, aber der ganze Optimierungsvorgang geschieht bei JS zur Laufzeit, also auf dem Client, und die ganze Sache an sich ist daher zwingend langsamer als bereits hochoptimierter Bytecode.

> Der von dir genannte Performance-Unterschied ( wenn man das so nennen darf
> ), ist ein Produkt der Sprachdefinition an sich. Das liegt daran, wie JS
> entworfen wurde. Daraus resultiert auch die Tatsache das JS zwingend
> langsamer ist, als zBsp die Konsorten Java/C#.
JS ist nur deshalb zwingend langsamer als Java/C#, weil es nicht vorkompiliert wird und dynamisch typisiert ist. Kompilieren ist nicht zu unterschätzen. Ob allerdings die Art der Typisierung bei interpretierten Sprachen im Gegensatz zu kompilierten einen Unterschied macht, weiss ich gerade nicht.

> =================================================================
>
> Bei OS geht es mir aber in vielerlei Hinsicht um Lernkomponenten. Ich finde
> OS daher gut, da ich von anderen lernen kann, wie man bestimmte Probleme
> löst. Des Weiteren kann man wirklich sehen wie gut jemand ist, oder ob er
> einfach nur rumfrickelt. Nicht zuletzt finde ich, dass Bugs oft schneller
> gelöst werden, wenn mehrere Augen auf den Source-Code schauen ( man selber
> wird ja schnell betriebsblind :P ).

[Tapsi]

> Nein. Eine andere Programmiersprache nach JS zu kompilieren resultiert oft
> in sehr umständlichem, langsamem Code. JS hat gegenüber ByteCode einen
> entscheidenden Nachteil: Man muss direkt damit programmieren können.

Hä? Was hat das eine jetzt mit dem anderen zu tun? Hier gings um die Unabhängigkeit von Sprache zu Platform... und Byte-Code ist nicht platformunabhängig! Sondern eher die VM auf der der ByteCode läuft. Das hat mit programmieren eigentlich nichts zu tun, weil wir hier über was technisches reden. Wenn wir aber im Wald stehen, kannst du uns ja aufklären.


> JS ist nur deshalb zwingend langsamer als Java/C#, weil es nicht
> vorkompiliert wird und dynamisch typisiert ist.

Nein ist es nicht. Es mag sein das zum ersten Start ein vorkompilierter Vor(!!!!!!!!!!!!!)-Code durchaus Vorteile in der Geschwindigkeit hat, aber diese sind eben nur am Anfang zutreffend. Entscheident für die Geschwindigkeit ist das, was der End-Compiler/Interpreter daraus macht. BTW. eigentlich könnte man JVM ByteCode auch als InterpreterSprache bezeichnen, da diese ja von der JVM interpretiert wird :P


> Kompilieren ist nicht zu unterschätzen.

Das hat auch niemand behauptet!


> Ob allerdings die Art der Typisierung bei interpretierten
> Sprachen im Gegensatz zu kompilierten einen Unterschied macht, weiss ich
> gerade nicht.

Gerade das ist ja der Knackpunkt, der JS langsamer als statische Sprachen wie Java macht. Zum Beispiel können Positionen einzelner Variables und Werte von Objekten in statischen Sprachen viel einfacher lokalisiert werden als in dynamischen. Ich weiß eben das in Klasse X die Variable Y an Stelle XYZ kommt. Das können dann Compiler effizient umsetzen. Bei dynamischen Sprachen geht das aber eher nicht... wenn du dir in JS ein Objekt bastelst und dem ein Wert hinzufügst, weiß der Compiler trotzdem nicht wo sich die Var befindet. Deshalb resultiert ein object.varX immer in einem Suchprozess, wo erst einmal geschaut werden muss ob object.varX überhaupt existiert. In Java gibt es Klassen die sowas sicherstellen , in JS nicht. ( Aber das ist jetzt auch sehr oberflächlich von mir beschrieben. Soll nur einen Einblick geben worauf ich hinaus will, warum JS langsamer ist )

UPDATE:
========

> Ja, aber der ganze Optimierungsvorgang geschieht bei JS zur Laufzeit, also auf dem > Client, und die ganze Sache an sich ist daher zwingend langsamer als bereits
> hochoptimierter Bytecode.

Ich bin aber der Meinung, dass JVM ByteCode auch erst zu Laufzeit hochoptimiert wird. Der ByteCode an sich kann wenn nur leicht optimiert sein, da man die aggressiven Optimierungen erst auf dem Client, wo Architektur etc. der VM bekannt sind, machen kann.

while not sleep
sheep++



1 mal bearbeitet, zuletzt am 16.09.11 14:47 durch Tapsi.