Michael Schröpl: (MEINUNG) Bytecode um jeden Preis! (Thema -» Themenchat?)

Beitrag lesen

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. ;-)