nicht angemeldet
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