(MEINUNG) Bytecode um jeden Preis! (Thema -» Themenchat?)

[xitnalta]

Hallo Forumers!

(jaja, das Bett steht nebenan *g*)

Also ich hab seit gestern wie wild wieder (hab ich schonmal begonnen, vergammelte aber inzwischen irgendwo) meine ältere Idee, angeregt durch ein Beispiel in 'GoTo C-Programmierung', verwirklicht, nämlich ein Bytecode-Programme-Interpreter.

Die Nachteile (bis jetzt):

• Direktprogrammierung zu umständlich, auch wenn mein txt2bin-Prog davor geschaltet wird. (Aufgabe von txt2bin: Eine Textdatei mit Hexcodes und Kommentaren wird in eine Binärdatei umgewandelt.)

• Höhere Konstrukte wie Objektorientierung und Stringverarbeitung sind nicht möglich. (D.h.: wer es um jeden Preis will, hat am Ende eine lahme Sache und viele vergeudete Zeit hinter sich.)

• Nur ein Datentyp: unsigned short (16-Bit-Ganzzahlen von 0 bis 65536) und Beschränkung auf 256 Variablen(nummern).

• Natürlich nur auf der Kommandozeile lauffähig.

Die Vorteile (bis jetzt):

• Dank kleinem Befehlsumfang und primitiven Konstrukten sehr hohe Geschwindigkeit. (Vielleicht liegts ja auch am Borland-Compiler, den man seit einiger Zeit gratis downloaden kann.)

• Da der Interpreter-Quellcode höchstens wenig Betriebssystemabhängigkeit aufweist, sehr portabel. (Bei Umlauten im Bytecode kann was entsprechendes wie bei HTML implementiert werden.)

• Sehr kleine Bytecode-Dateien. (Wo es jetzt noch zu grosse Konstrukte gibt, gibt es irgendwann die Möglichkeit, es mit einem einzigen Befehl auszuführen.)

• Der Bytepreter (der Name des Programms) liesse sich auch in JavaScript implementieren. Übergeben würden in einem Formular die Hex-Codes des Programms, welche dann von JS umgewandelt und ausgeführt würden.

(Wer dieses Prog testen will, bekommt von mir den Quellcode (sehr unkommentiert!), Binary (Win/Linux), Befehlssatzdefinition, txt2bin und ein paar kommentierte Beispiel-Text-Dateien, welche mit txt2bin umgewandelt werden können: mailto:[e-mail] (Wenn das nicht geht: email-Adresse steht oben schon.))

Wie würde es mit der Zukunft einer solchen Bytecode-Programmiersprache stehen? (Man kann natürlich einen Compiler wie bei Java entwickeln, der zuerst eine höhere Sprache in den wirren Bytesalat übersetzt, aber das wurde (von mir) bis jetzt noch nicht getan.)

Meine eigentliche Frage: Wieso wird heute noch vorwiegend weiter an Klartextformaten getüftelt, wenn man mit Binärformaten (Grafiken sind da ja sehr "fortschrittlich" *g*), deren Definitionen und Bibliotheken (für eigene Programme) ebenfalls frei verfügbar wären und die auch aus bestehenden Klartext-Dokumenten generiert werden könnten, eine höhere "Syntax-Validität", höhere Datendichte, und damit einen höheren Informationsfluss im (üblicherweise schmalspurigen) Internet erreichen könnte? Eine einfache Möglichkeit wäre ja, in allen Browsern und sonstigen Internet-Clients Entpack-Module (z.B. für Zip oder gzip) einzubinden, welche (als Beispiel) gepackte HTML-Dateien empfangen, automatisch entpacken und anzeigen würden.

Ja, ich habe von der Vergangenheit vom möglichst höchstkompatiblen Internet gehört ;). Aber was ist denn Flash? (Versteht es nicht falsch, ich hasse es, es soll nur als aktuelles Beispiel dienen.) Nix Klartext. Flash ist aber dummerweise eine proprietäre Entwicklung einer Unternehmung. Wie würden ich und viele mehr wohl zu diesem Quasi-Standard stehen, wenn die Sache mit dem Unternehmen macromedia wegfallen würde?

Interessiert mich mal zu hören, wie ihr dazu steht (und ob ich in letzter Zeit nur noch Mist programmiert habe *g*)

bis nextens
xitnalta

PS: Wäre das Ganze evtl. ein Thema für den berühmten gleichnamigen Chat?

[Stefan Muenz]

Hallo Xinalta!

Wäre das Ganze evtl. ein Thema für den berühmten gleichnamigen Chat?

Ich denke ja! Wenn man es vielleicht etwas weiter wegholt von den Alternativen zwischen compiliertem und nur interpretiertem prozeduralen Code. Wenn man es generell ausweitet auf das Thema: "Klartext versus Binaerformate - was ist besser fuer das Internet?", dann wuerde darin sicher einiger Sprengstoff liegen, der Besucher in den Themenchat locken wuerde. Da gaebe es einiges zu diskutieren. Falls du daran tatsaechlich Interesse hast, melde dich mal per Mail!

viele Gruesse
   Stefan Muenz

[Andreas Bierhals]

Moin,

Hallo Forumers!

(jaja, das Bett steht nebenan *g*)

Also ich hab seit gestern wie wild wieder
(hab ich schonmal begonnen, vergammelte aber inzwischen
irgendwo) meine ältere Idee, angeregt durch ein Beispiel
in 'GoTo C-Programmierung', verwirklicht, nämlich ein
Bytecode-Programme-Interpreter.

Klingt interessant - ich kenne das Gefühl, daß man nach durchprogrammierten
Nächten und rauchendem Kopf auch mal mit jemand anders über
die Problematik diskutieren möchte. Dummerweise findet sich
in solchen Momenten meist niemand, den das dann wirklich interessiert ;-)

Die Nachteile (bis jetzt):

• Direktprogrammierung zu umständlich, auch wenn mein txt2bin-Prog davor geschaltet wird. (Aufgabe von txt2bin: Eine Textdatei mit Hexcodes und Kommentaren wird in eine Binärdatei umgewandelt.)

• Höhere Konstrukte wie Objektorientierung und Stringverarbeitung sind nicht möglich. (D.h.: wer es um jeden Preis will, hat am Ende eine lahme Sache und viele vergeudete Zeit hinter sich.)

• Nur ein Datentyp: unsigned short (16-Bit-Ganzzahlen von 0 bis 65536) und Beschränkung auf 256 Variablen(nummern).

Naja, bis ein zweites "Perl" oder so dabei herauskommt, vergeht
normalerweise wohl viel Zeit und Mühe. Interessant wird es aber, wenn
man mit solch einer vereinfachten Sprache eine Schnittstelle
zwischen fest z.B. in C++ compilierten Modulen und der Außenwelt
herstellt. Auf diese Weise lassen sich sehr flexible und
betriebssystem-unabhängige Programme schreiben. Insbesondere
lassen sich auf diese Weise zeitkritische Berechnungsroutinen
von weniger zeitkritischen Bedien- und Layout-Elementen
separieren, wodurch die Projekte deutlich an Übersichtlichkeit
und Wartbarkeit gewinnen.

• Natürlich nur auf der Kommandozeile lauffähig.

Wozu gibt es die CGI-Schnittstelle? ;-)

Meine eigentliche Frage: Wieso wird heute noch vorwiegend weiter an Klartextformaten getüftelt, wenn man mit Binärformaten (Grafiken sind da ja sehr "fortschrittlich" *g*), deren Definitionen und Bibliotheken (für eigene Programme) ebenfalls frei verfügbar wären und die auch aus bestehenden Klartext-Dokumenten generiert werden könnten, eine höhere "Syntax-Validität", höhere Datendichte, und damit einen höheren Informationsfluss im (üblicherweise schmalspurigen) Internet erreichen könnte? Eine einfache Möglichkeit wäre ja, in allen Browsern und sonstigen Internet-Clients Entpack-Module (z.B. für Zip oder gzip) einzubinden, welche (als Beispiel) gepackte HTML-Dateien empfangen, automatisch entpacken und anzeigen würden.

Das Problem an früheren Binärformaten war ja vor allem, daß sie
nicht dokumentiert waren und der Softwarehersteller sich die
Freiheit nahm, die Dateiformate in späteren Versionen in
nicht-abwärtskompatibler Weise abzuändern. Es gibt neuerdings
auch positive Gegenbeispiele, so z.B. das Portable Document Format,
welches von Adobe komplett dokumentiert ist (natürlich in der
Absicht, daß möglichst viele Leute Acrobat benutzen, was aber
nicht bindend ist).

Warum man dennoch Ascii-Formate bevorzugt liegt wohl vor
allem an der Bequemlichkeit, eine Skript-Datei o.Ä. sofort und
ohne vorgeschaltete Konvertierungen mit einem X-beliebigem
Editor einsehen und ändern zu können. Das Binärformat benötigt
dagegen erstmal einen ganz bestimmten Editor oder entsprechende
Konvertierungstools - also einige Schritte mehr. Die Zeit, die ein
Skript-Interpreter benötigt, um das Ascii-Format in sein internes
Binärformat zu 'parsen', fällt dagegen weniger ins Gewicht,
zumal die Rechnerperformance für die meisten solcher Fälle
mehr als ausreichend geworden ist.

Interessiert mich mal zu hören, wie ihr dazu steht (und ob ich in letzter Zeit nur noch Mist programmiert habe *g*)

Klingt doch interessant und hat Dir sicher auch die Augen
geöffnet, was für ein ungeheurer Aufwand z.B. in einem JavaScript- oder
Perl-Interpreter steckt. Warum müssen Programme von vornherein
immer nur nützlich sein? ;-)

Bis dannundwann...

Andreas

[Michael Schröpl]

Meine eigentliche Frage: Wieso wird heute noch

Wieso "noch"? "Endlich" triff die Sache viel eher.
Ganz am Anfang gab es nur Binärformate ...

vorwiegend weiter an Klartextformaten getüftelt,
wenn man mit Binärformaten (Grafiken sind da ja
sehr "fortschrittlich" *g*),

Ganz im Gegenteil. Viele Graphikformate sind m. E.
sehr rückschrittlich, weil sie eben *nicht* abstrakt,
sondern relativ "plattformnah" ihre Information
beschreiben. (Pixel statt Vektoren, weil die Graphik-
karten nun mal nichts anderes können.)

deren Definitionen und Bibliotheken (für eigene
Programme) ebenfalls frei verfügbar wären und die
auch aus bestehenden Klartext-Dokumenten generiert
werden könnten,

Eben: Wenn Du selbst Dir der Vorteile von Klartext-
Source bewußt bist, wieso willst Du dann etwas
"Schlechteres" einführen?

eine höhere "Syntax-Validität",

Mitnichten. In binärem Gruselwusel kann man genauso
viel Unfug codieren - bloß merkt man es nicht so leicht.

höhere Datendichte, und damit einen höheren
Informationsfluss im (üblicherweise schmalspurigen)
Internet

Jetzt unterliegst Du einem konzeptionellen Denkfehler.

Das Internet enthält viele verschiedene Datenformate.
Eines davon ist Deines. Was ist effizienter: Für jedes
dieser Datenformate ein eigenes Komprimierungsverfahren
zu implementieren oder für alle ein gemeinsames?

Klartext läßt sich aufgrund seiner hohen Redundanz
(informationstheoretisch betrachtet, nicht semantisch ;-)
grußartig komprimieren, egal ob das HTML, JavaScript,
Perl oder whatever ist. Also: Ein guter Komprimierer
an der Stelle, wo alle Daten durch müssen, macht mehr
Sinn als tausend proprietäre Verfahren.

Beides läßt sich natürlich additiv verwenden, und das
wird auch immer geschehen (ein GIF auf einer komprimiert
betriebenen Leitung).
Aber je klarer Dir das wird, desto weniger wirst Du
durch Dein proprietäres Verfahren noch herausholen
können.

erreichen könnte?
Eine einfache Möglichkeit wäre ja, in allen Browsern
und sonstigen Internet-Clients Entpack-Module (z.B.
für Zip oder gzip) einzubinden, welche (als Beispiel)
gepackte HTML-Dateien empfangen, automatisch entpacken
und anzeigen würden.

Genau. Und gepackte Applets, und gepackte Shockwave-
Daten, und überhaupt alles Gepackte. Wenn schon, dann
gleich richtig, nicht wahr?

Ja, ich habe von der Vergangenheit vom möglichst
höchstkompatiblen Internet gehört ;). Aber was ist
denn Flash? (Versteht es nicht falsch, ich hasse es,
es soll nur als aktuelles Beispiel dienen.)
Nix Klartext. Flash ist aber dummerweise eine
proprietäre Entwicklung einer Unternehmung.

"Nicht-Klartext" und "proprietär" haben nicht zwingend
(inhaltlich betrachtet) etwas miteinander zu tun.

Leider aber technisch, denn kommerzielle Anbieter
tendieren dazu, ihren proprietären Gruselwusel auch
noch binär zu verschlimmern, damit ihn die Konkurrenz
nicht so leicht decodieren kann (denn die Anwender
sollen ja die teure Software des Herstellers kaufen
und keine kostenlose GNU-Konkurrenuprodukte verwenden).

Wie würden ich und viele mehr wohl zu diesem
Quasi-Standard stehen, wenn die Sache mit dem
Unternehmen macromedia wegfallen würde?

Wenn keine kommerziellen Interessen zu schützen wären,
dann wäre auch das vorgeschaltete Klartextformat public
domain und die Codierung nicht mehr die Hauptsache,
sondern nur noch ein "nice to have". (Wenn überhaupt.)

Interessiert mich mal zu hören, wie ihr dazu steht
(und ob ich in letzter Zeit nur noch Mist
programmiert habe *g*)

Einen Interpreter als Übung zu schreiben ist kein
"Mist", sondern bringt Dir einige Erfahrungen.

Du selbst hast ja gemerkt, welche Limitierungen
(bezüglich Datentypen etc.) Du implementiert hast -
und Du kannst jetzt abschätzen, wieviel mehr ein
mächtigerer Interpreter bei Objekten, Hashes, regular
expression machines, sql statement evaluation bzw.
tuning etc. leisten können muß (und wie viele
Mannjahre Arbeitsleistung da drin stecken).

Eine Vorlesung in Compilerbau hätte einen ähnlichen
Effekt gehabt. ;-)