Welcher XML-Parser für Linux-Programm
Marcus Woletz
ich entwickle gerade ein Programm, für welches
ich gerne XML als Dateiformat verwenden würde.
Deshalb benötige ich einen (validierenden)
XML-Parser, wenn möglich mit C++-Schnittstelle.
Xerces ist mir definitiv zu groß, ich suche eher
einen einfachen kleinen Parser.
ciao
Marcus
Bernd Petrovitsch
>Xerces ist mir definitiv zu groß, ich suche eher
>einen einfachen kleinen Parser.
Ist expat besser?
Bernd
--
Bernd Petrovitsch Email : be...@petrovitsch.at
LUGA : http://www.luga.at
Christian Parpart
> Marcus Woletz <mar...@woletz.de> wrote:
>>Xerces ist mir definitiv zu groß, ich suche eher
>>einen einfachen kleinen Parser.
>
> Ist expat besser?
>
> Bernd
Expat ist in C.
Christian Parpart
Also, wenn du was in C++ moechtest, und Xerces zu
gross findest (kann ich versteh'n), ich bin gerade
dabei eine C++ Imlementation von einigen W3C
Spezifikationen zu implementieren. Er ist zwar noch
nicht validierend, aber das ist auch geplant,
derzeit sind drin
* DOM 3 Core
* DOM 3 XPath
* DOM 3 Load & Save
XSLT steckt in den Kinderschuhen.
wenn du nicht nur Bibliothek nutzen moechtest,
sondern auch dran interessiert bist, mit zu entwickeln,
dann schau mal auf:
http://www.surakware.net/projects/xena/index.xml
(LGPL)
MfG,
Christian Parpart.
King Leo - Martin Oberzalek
> Bernd Petrovitsch inspired the electrons to say:
>> Ist expat besser?
> Expat ist in C.
Es gibt C++ Wrapper:
http://www.codeproject.com/soap/expatimpl.asp
Hab aber kaum Ahnung von expat, und noch weniger von diesem Wrapper.
Gruß, Martin!
--
"Da Gandalfs Kopf jetzt heilig ist, lasst uns einen anderen finden,
den zu spalten richtig ist!"
(Gimli in LOTR)
Christian Parpart
> Christian Parpart wrote:
>
>> Bernd Petrovitsch inspired the electrons to say:
>
>>> Ist expat besser?
>
>> Expat ist in C.
>
> Es gibt C++ Wrapper:
>
> http://www.codeproject.com/soap/expatimpl.asp
>
> Hab aber kaum Ahnung von expat, und noch weniger von diesem Wrapper.
>
> Gruß, Martin!
Also, hier die Aufloesung (oder fast *g*).
Expat ist ein Stream orientierter XML Parser, ExpatImpl,
der C++ Expat Wrapper. Ich frage mich nur warum sie die
Bibliothek nicht gleich SAX2 genannt haben, denn das ist,
was es tut.
Nun, auch DOM Level 3 Load & Save unterstuetzt sogenanntes
Streaming, ahlt nur mit dem kleinen Nebeneffekt auch gleich
einen XML Baum mit aufzubauen. Da heisst das Feature Interface
DOMBuilderFilter. und dem DOMBuilder kann man diesen Filter
zuweisen und es passiert das gleiche. SAX bietet eine feinere
Art von Events. Aber naja.
Also, ich habe mal die beiden expat Beispiele zu meiner
Bibliothek portiert, soewie das von libxml2, alle drei
funktionieren wie erwartet.
Ich habe mir mal ExpatImpl runtergeladen, dabei handelt es
sich um eine einfache CExpat Klasse die komplett geinlined
wurde. Das Quellpaket enthaellt leider keine Beispiele, noch
Dokumentationen. (also bleibt es bie der Online Referenz)
Also, Expat bzw ExpatImpl ist kein validierender parser im Sinne
der W3 Spezifikation.
libXee ist es uebrigens auch nicht, hat aber dafuer kompletten
DOM Zugriff und Erlaupt XPath Selektierungen sowie das laden,
speichern und das erstellen von Hand von DOM (XML) Dokuemnten.
Validierend wird er davon zwar immernoch nicht, aber geplant
ist es.
MfG,
Christian Parpart.
Christian Parpart
> http://www.surakware.net/projects/xena/index.xml
> (LGPL)
Oh! Auwaia! Da muss ich wohl geschlafen haben, das ist die falsche URL!
und ausserdem ist die o.g. nicht in LGPL, sondern GPL, sorry.
http://www.surakware.net/projects/libXee/index.xml (LGPL)
Quelltext unter WebCVS hier: http://cvs.surakware.net/viewcvs.cgi/libXee/
So, jetzt aber ab ins Bett und ausschlafen *g*
ciao,
Christian Parpart.
Felix von Leitner
> > Ist expat besser?
> Expat ist in C.
Welchen Teil von "validierend" habt ihr nicht verstanden?
Felix von Leitner
XML, einfach&klein, validierend. Höchstens zwei davon.
Und da sieht man mal, wie scheiße XML ist. Ein großer Hype, und
dahinter sieht man einen technisch schlechten Standard für ein seit
Jahrzehnten deutlich besser gelöstes Problem. Schlipskompatibles
Marketinggeblubber halt.
Es gibt kein Problem, das XML lösen würde. Und minimal ist es halt mit
überhaupt rein gar nicht.
Wenn du an XML festhalten willst (die meisten Leute in deinem Stadium
sind schon so über den Jordan, daß sie sich nicht von XML abbringen
lassen), kannst du die Validierung von Hand in deinem Programm machen,
womit du dann aber natürlich die DTD in Zement gießt.
Felix
Felix von Leitner
ROTFL, was ist das denn für eine Lachnummer? Sollen wir uns die Files
jetzt einzeln aus deinem widerlichen Web-Frontend rauspopeln oder wie?
Laß mich raten, aus Sicherheitsgründen kannst du keinen anonymen
CVS-Zugriff anbieten, wie?
Oh Mann.
Christoph Kliemt
> Thus spake Marcus Woletz (mar...@woletz.de):
> > ich entwickle gerade ein Programm, für welches ich gerne XML als
> >Dateiformat verwenden würde. Deshalb benötige ich einen (validierenden)
> >XML-Parser, wenn möglich mit C++-Schnittstelle.
>
> > Xerces ist mir definitiv zu groß, ich suche eher einen einfachen kleinen
> >Parser.
>
> XML, einfach&klein, validierend. Höchstens zwei davon.
>
> Und da sieht man mal, wie scheiße XML ist.
XML ist scheisse weil...?
\\// christoph
Christian Parpart
*heh* guck mal auf die download.xml da habe ich kuerzlich (und nicht erst
eben) den anonymous cvs access beschreibung hinzugefuegt:
$ export CVSROOT=:pserver:ano...@cvs.surakware.net:/home/cvsroot
$ cvs login
<<hier einfach anoncvs eingeben und enter druecken>>
$ cvs -z4 co libXee
Mehr nicht. Und, es ist keine Lachnummer, natuerlich waere es echt krankhaft
die files nur einzeln zum download anzubieten, die WebCVS Variante ist fuer
diejenigen, die sich den Fortlauf und den aktuellen stand mal online
ansehen wollen, ohne gleich ein ganzes paket zu saugen :-)
Ciao,
Christian Parpart.
Christian Parpart
> *heh* guck mal auf die download.xml da habe ich kuerzlich (und nicht erst
> eben) den anonymous cvs access beschreibung hinzugefuegt:
Okay, ich bin mir ja einer, die WebSite wird auch via CVS gehandhabt, ich
hab die aenderungen zwar committed, aber fuer den web server nicht
geupdated ;) oh mann!
Christian Parpart
Nun, gestern bin ich - ich sollte besser tagsueber arbeitetn - wohl ein
wenig unkonzentriert gewesen. Naja! Also ich habe mir die XML
Recommendation nocheinmal angesehen, und festgestellt, mein Framework ist
_nicht_ XML Validierend, denn das LS Modul ist noch nicht _so_ weit. Aber
die DOM Level 3 Core Implementation validiert bereits gemaess seiner
Spezifikation. Diese Validierung prueft aber nur ob der
Anwendungsprogrammierer z.B. einem Text Knoten kein Attribut hinzufuegt.
Unlogisch, klar! aber dazu ist die Validation ja da, um es zu verhindern!
Felix, am LS Modul arbeite ich gerade, doch um das auf den neuesten Stand zu
bringen, muss ich erstmal Traversal und Events implementieren.
Denn seit neuestem ist LS davon abhaengig(!).
Und, wenn du dir schon den Quelltext auscheckest, ich bin echt gern fuer
Kommentare offen :) einfach e-mailen.
Ciao,
Christian.
Christian Parpart
>> ich entwickle gerade ein Programm, für welches
>> ich gerne XML als Dateiformat verwenden würde.
>> Deshalb benötige ich einen (validierenden)
>> XML-Parser, wenn möglich mit C++-Schnittstelle.
>
>> Xerces ist mir definitiv zu groß, ich suche eher
>> einen einfachen kleinen Parser.
>
> XML, einfach&klein, validierend. Höchstens zwei davon.
>
> Und da sieht man mal, wie scheiße XML ist. Ein großer Hype, und
> dahinter sieht man einen technisch schlechten Standard für ein seit
> Jahrzehnten deutlich besser gelöstes Problem. Schlipskompatibles
> Marketinggeblubber halt.
> Es gibt kein Problem, das XML lösen würde. Und minimal ist es halt mit
> überhaupt rein gar nicht.
Da hat sich mal jemand wirklich mit der Spec befasst *g* dann bin ich ja zum
Glueck nicht allein :-P
Zum Thema Minimal: das DTD Parsing und vorallem Validating ist nun echt
nicht minimal. Jetzt weiss ich warum Xerces so ein grosser brocken ist.
(Xerces --> oder steckt da noch sein Design dahinter?)
> Wenn du an XML festhalten willst (die meisten Leute in deinem Stadium
> sind schon so über den Jordan, daß sie sich nicht von XML abbringen
> lassen), kannst du die Validierung von Hand in deinem Programm machen,
> womit du dann aber natürlich die DTD in Zement gießt.
Also DTD war bisher echt alles, nur nichts fuer mich, ich hab mir letzte
nacht meinen Ausdruck sogar noch mit ins Bett schleppen muessen, jetzt
versteh ichs, versteh aber nicht warum die das als Ideal bezeichnen. Und es
sieht ja nichtmal gut aus. Na Prost Malzeit!
Cheers,
Christian.
Felix von Leitner
> > Und da sieht man mal, wie scheiße XML ist.
> XML ist scheisse weil...?
Stand da doch.
Aber nochmal ganz langsam zum mitschreiben:
a) XML provoziert Buffer Overflows und ist unnötig umständiglich zu
parsen. Wieso gibt es keine Längenkodierung?
b) XML ist nicht hinreichend. Die zusätzlichen Standards sind mehrere
hundert Seiten Bloat, den sich kein Mensch durchlesen kann, ohne
sich dabei schwerste Hirntraumata zuzuziehen.
c) XML ist nur eine Syntax. Semantische Validierung ist untrivial und
sehr fummelig.
d) XSLT ist ein Albtraum. Die Größe und Performance der bestehenden
Implementierungen sprechen für (oder besser: gegen) sich.
e) XML ist eine unglaubliche Platzverschwendung. Und was entblöden
sich die XML-Leute jetzt ernsthaft als Lösung vorzuschlagen: man
kann ja ein Kompressions-Layer darüber packen! Holy CPU Burnout,
Batman!
f) Das gibt es alles schon mal in besser. Z.B. ist SOIF des
Harvest-Projektes einfacher zu parsen. Syntax ist:
Feldname{6}: Inhalt
Die maximale Länge des Feldnamens ist der Applikation bekannt.
Oder man kann auch das cdbmake-Eingabeformat nehmen, um Key-Value
Paare simpel parsebar zu kodieren. Syntax:
+3,5:one->Hello
Letztlich ist XML ein kleiner ad-hoc Kludge, den sich irgendwann mal
irgendein Hacker für irgendein ad-hoc Problem ausgedacht hat, und der
dann zur Perfektion geführt wurde, in dem man so lange darauf aufbauende
Bloat-Standards gefummelt hat, bis niemand mehr XML für überflüssig
hält, weil doch sooo viele wichtige Standards darauf aufbauen.
Ich warte schon gespannt auf eine Welle von Exploits für
XML-Parser-Probleme, mit der sich dann die ganzen tollen
standardisierten Web-Portale fernsteuern lassen. Was man bei einer
naiven Implementation falsch machen kann, wird garantiert irgendwo auch
falsch gemacht werden.
Felix
Stefan Nobis
> Letztlich ist XML ein kleiner ad-hoc Kludge, den sich irgendwann mal
> irgendein Hacker für irgendein ad-hoc Problem ausgedacht hat, und der
Nein, das würde ich nicht so sehen. Wenn man mal die Herkunft bedenkt,
nämlich SGML und dessen ursprüngliches Einsatzgebiet, nämlich
Textmarkup, dann ist XML als vereinfachtes SGML gar nicht mal eine so
schlechte Idee (und z.B. als Markup für Bücher so a la Docbook-XML
würde ich auch nicht mehr unbedingt von Bloat reden).
Das Problem entsteht erst, wenn man XML unabhängig vom ursprünglichen
Kontext für alles Mögliche und Unmögliche einsetzen will, z.B. für
Konfigurationsdateien (oh graus) oder als universelles Dateiformat für
alles (was soll das schon bringen... hilfreich wäre da nur, wenn so
indirekt bisher nicht-öffentliche Details über Dateiformate öffentlich
gemacht werden -- aber dazu ist XML nicht notwendig und auch nicht
hinreichend).
--
Stefan.
Felix von Leitner
> > Letztlich ist XML ein kleiner ad-hoc Kludge, den sich irgendwann mal
> > irgendein Hacker für irgendein ad-hoc Problem ausgedacht hat, und der
> Nein, das würde ich nicht so sehen. Wenn man mal die Herkunft bedenkt,
> nämlich SGML und dessen ursprüngliches Einsatzgebiet, nämlich
> Textmarkup, dann ist XML als vereinfachtes SGML gar nicht mal eine so
> schlechte Idee (und z.B. als Markup für Bücher so a la Docbook-XML
> würde ich auch nicht mehr unbedingt von Bloat reden).
Wie kommst du denn darauf, daß SGML nicht auch ein kleiner ad-hoc Kludge
von irgendjemandem ist? Nur weil das einen zwanzigjährigen Advocacy und
Standardisierungs-Marathon durchlaufen hat, ist es nicht plötzlich ein
sauberes, klares und vorbildliches Design.
Aber XML und SGML muß man deutlich trennen. XML ist zum Abbilden von
strukturierten Daten da, nicht für Text-Markup.
Christoph Kliemt
> Thus spake Christoph Kliemt (christop...@achilles.entici.de):
> > > Und da sieht man mal, wie scheiße XML ist. XML ist scheisse weil...?
>
> Stand da doch.
Nicht wirklich.
> Aber nochmal ganz langsam zum mitschreiben:
>
> a) XML provoziert Buffer Overflows und ist unnötig umständiglich zu
> parsen. Wieso gibt es keine Längenkodierung?
Eine Syntax provoziert Buffer Overflows. Ah, ja.
Eine Längencodierung macht keinen Sinn. Was soll denn die Länge
sein? zB Mit whitespaces oder ohne? Die Interpretation der Daten geht
xml nicht an. Und ob es eine clevere Idee ist sich auf Längenangaben
in einer Datei die sonstwoher kommen kann zu verlassen ? Nicht
wirklich.
> b) XML ist nicht hinreichend.
...für was?
> Die zusätzlichen Standards sind mehrere
> hundert Seiten Bloat, den sich kein Mensch durchlesen kann, ohne
> sich dabei schwerste Hirntraumata zuzuziehen.
Tja, für jede Aufgabenstellung das geeignete Werkzeug. Man wird
seltenst alle auf einmal brauchen.
> c) XML ist nur eine Syntax. Semantische Validierung ist untrivial und
> sehr fummelig.
Was willst Du uns mit diesen Allgemeinplätzen sagen?
> d) XSLT ist ein Albtraum. Die Größe und Performance der bestehenden
> Implementierungen sprechen für (oder besser: gegen) sich.
Niemand zwingt dich XSLT zu nutzen. Es hat seine Anwendungsbereiche,
und wenn es nicht passt gibt es reichlich Alternativen.
> e) XML ist eine unglaubliche Platzverschwendung. Und was entblöden
> sich die XML-Leute jetzt ernsthaft als Lösung vorzuschlagen: man
> kann ja ein Kompressions-Layer darüber packen! Holy CPU Burnout,
> Batman!
Das meinst Du jetzt bitte nicht ernst.
> f) Das gibt es alles schon mal in besser.
Mag sein. Besser für was? Welche Verbreitung? Mir ist xml mit seiner
Verbreitung und der Menge an Werkzeugen lieber als irgendeine tolle
Spielerei mit dem Verbreitungsgrad 0.
[...]
> Ich warte schon gespannt auf eine Welle von Exploits für
> XML-Parser-Probleme, mit der sich dann die ganzen tollen standardisierten
> Web-Portale fernsteuern lassen. Was man bei einer naiven Implementation
> falsch machen kann, wird garantiert irgendwo auch falsch gemacht werden.
Und das hat jetzt mit xml was zu tun... ?
XP & Fup2 dcoud
christoph
René Möhring
Felix von Leitner <usenet-...@fefe.de> wrote:
> e) XML ist eine unglaubliche Platzverschwendung. Und was entblöden
> sich die XML-Leute jetzt ernsthaft als Lösung vorzuschlagen: man
> kann ja ein Kompressions-Layer darüber packen! Holy CPU Burnout,
> Batman!
Gibts tatsächlich, siehe StarOffice.
Stefan Reuther
Stefan Nobis <ste...@snobis.de> wrote:
> Felix von Leitner <usenet-...@fefe.de> writes:
>> Letztlich ist XML ein kleiner ad-hoc Kludge, den sich irgendwann mal
>> irgendein Hacker für irgendein ad-hoc Problem ausgedacht hat, und der
> Nein, das würde ich nicht so sehen. Wenn man mal die Herkunft bedenkt,
> nämlich SGML und dessen ursprüngliches Einsatzgebiet, nämlich
> Textmarkup, dann ist XML als vereinfachtes SGML gar nicht mal eine so
> schlechte Idee (und z.B. als Markup für Bücher so a la Docbook-XML
> würde ich auch nicht mehr unbedingt von Bloat reden).
Hab ich hier etwa "vereinfacht" gelesen?
Ich kenne nicht wirklich die Specs auswendig, aber XML hat
uns doch z.B. den ganzen Namespace-Mist beschert, der das
ganze erst kompliziert macht.
Ich verwende hier einen XML-und-SGML-Subset, der von meiner
eigenwilligen Toolchain (psgml-mode, sgmls, LotusXSL) akzeptiert
wird, und bin relativ zufrieden damit (okay, außer mit der
Performance von LotusXSL). Zum Schreiben von irgendwelchen
Texten, aus denen dann mal HTML wird, ist es ganz brauchbar.
Sonst hätte ich mir halt mein eigenes Markup-Format und eigene
Tools bauen müssen. Das ist aber auch der einzige Grund.
Eine tolle neue Universallösung ist es bei weitem nicht.
Ich bin bei XSLT jedesmal wieder am Fluchen. Warum gibt es
kein "strupr"/"strlwr" o.ä.? Warum gibt es keinen ternären
Operator? Wie zum Teufel baut man einen Index mit Trennern,
z.B. Buchstaben ("A: Apfel, B: Birne Banane") (ich hab eine
Variante die das ganze in O(n^2) bzw. ähnlich schlimm
hinbekommt...)
Stefan
Felix von Leitner
> > parsen. Wieso gibt es keine Längenkodierung?
> Eine Syntax provoziert Buffer Overflows. Ah, ja.
Wenn du es nicht verstehst, wieso kommentierst du es dann?
> Eine Längencodierung macht keinen Sinn.
Wenn du es nicht verstehst, wieso kommentierst du es dann?
BTW: Was soll diese beschämend dämliche Einrückung in deinen Postings?
Wohl mit auch mit dem Newsreader deutlich überfordert, wie?
> Was soll denn die Länge sein?
Platzbedarf.
> zB Mit whitespaces oder ohne?
Das ist jetzt eine Trickfrage, oder? So dämlich kann ja wohl niemand sein.
> Die Interpretation der Daten geht xml nicht an. Und ob es eine
> clevere Idee ist sich auf Längenangaben in einer Datei die
> sonstwoher kommen kann zu verlassen ? Nicht wirklich.
Wenn du es nicht verstehst, wieso kommentierst du es dann?
> > b) XML ist nicht hinreichend.
> ...für was?
Für die in der Rationale dargelegten Anwendungsgebiete.
> Tja, für jede Aufgabenstellung das geeignete Werkzeug. Man wird
> seltenst alle auf einmal brauchen.
Genau genommen braucht überhaupt keines davon.
> > c) XML ist nur eine Syntax. Semantische Validierung ist untrivial und
> > sehr fummelig.
> Was willst Du uns mit diesen Allgemeinplätzen sagen?
Sag bloß, ASN.1 kennst du also auch nicht?
Deine Inkompetenz ist in der Tat beeindruckend, nur wieso lebst du sie
nicht woanders aus? dag° bietet sich geradezu an für Experten deines
Kalibers.
> > d) XSLT ist ein Albtraum. Die Größe und Performance der bestehenden
> > Implementierungen sprechen für (oder besser: gegen) sich.
> Niemand zwingt dich XSLT zu nutzen. Es hat seine Anwendungsbereiche,
> und wenn es nicht passt gibt es reichlich Alternativen.
Mir ist noch kein keiner begegnet.
> > e) XML ist eine unglaubliche Platzverschwendung. Und was entblöden
> > sich die XML-Leute jetzt ernsthaft als Lösung vorzuschlagen: man
> > kann ja ein Kompressions-Layer darüber packen! Holy CPU Burnout,
> > Batman!
> Das meinst Du jetzt bitte nicht ernst.
Na _ich_ hab mir das nicht ausgedacht!
> > f) Das gibt es alles schon mal in besser.
> Mag sein. Besser für was? Welche Verbreitung? Mir ist xml mit seiner
> Verbreitung und der Menge an Werkzeugen lieber als irgendeine tolle
> Spielerei mit dem Verbreitungsgrad 0.
Die Verbreitung resultiert direkt aus der Anzahl der Vollidioten in der
IT-Branche. Ich habe genau keinerlei Interesse daran, mit Idioten oder
von Idioten geschriebener Software zu interagieren.
Im Übrigen, warum setzt du nicht Windoze ein, das ist noch viel
verbreiteter als Unix!
> > Ich warte schon gespannt auf eine Welle von Exploits für
> > XML-Parser-Probleme, mit der sich dann die ganzen tollen standardisierten
> > Web-Portale fernsteuern lassen. Was man bei einer naiven Implementation
> > falsch machen kann, wird garantiert irgendwo auch falsch gemacht werden.
> Und das hat jetzt mit xml was zu tun... ?
Wenn du es nicht verstehst, wieso kommentierst du es dann?
> XP & Fup2 dcoud
Das war wohl nichts.
Holger Marzen
> Thus spake Christoph Kliemt (christop...@achilles.entici.de):
>
>> > b) XML ist nicht hinreichend.
>> ...für was?
>
> Für die in der Rationale dargelegten Anwendungsgebiete.
>
>> Tja, für jede Aufgabenstellung das geeignete Werkzeug. Man wird
>> seltenst alle auf einmal brauchen.
>
> Genau genommen braucht überhaupt keines davon.
Würden wir uns bitte drauf einigen, dass XML eine große Zukunft hat,
weil es ein riesiger Bloat ist und man tolle Tools drumrumschreiben
muss, so dass die Betroffenen entweder mit oder ohne Tools wahnsinnig
werden?
XML wird es schaffen, dass auch der einfachste Datenaustausch
aufgeblasen und kompliziert wird. Wo früher eine Satzbeschreibung
(Stelle 1-10 numerisch: Artikelnummer) oder eine CSV-Datei mit Header
war, wird morgen mit XML rumgehampelt, und auf jeder Seite der
Datenaustauschenden werden teure Bloattools gekauft und Manntage
verprogrammiert werden müssen.
Hat man früher noch eine SAP-Einführung oder eine Umstellung auf
Windows-NT gebraucht, um ein Unternehmen an den Rand des Ruins zu
bringen, so wird morgen das Geld bereits verbraten werden, wenn auf
einmal alles "in XML" gespeichert werden muss, weil man ist ja dann
ganz doll kompatibel. Wie wäre es mit einem Archiv, in dem
Base64-codierte Word-Dokumente in einer XML-Datei gespeichert werden?
Mussu krass Largefile-Support aktivieren, Alder, ey.
Wenn dann auch noch der Handwerker sein Angebot für die Reparatur des
Geländers am Eingang des Sozialamts "in XML" abgeben muss, dann haben
die Unnötigen dieser Welt wieder einmal gewonnen.
Marcus Hampel
Felix von Leitner wrote:
> Thus spake Christoph Kliemt (christop...@achilles.entici.de):
>
>>> a) XML provoziert Buffer Overflows und ist unnötig umständiglich zu
>>> parsen. Wieso gibt es keine Längenkodierung?
>>
>> Eine Syntax provoziert Buffer Overflows. Ah, ja.
>
>
> Wenn du es nicht verstehst, wieso kommentierst du es dann?
Buffer Overflows sind Probleme von veralteten Programmiersprachen und
kein Problem des XML-Syntax.
Und wenn deine Argumente ausgehen, warum schreibst du dann nur Bullshit?
>> Eine Längencodierung macht keinen Sinn.
>
>
> Wenn du es nicht verstehst, wieso kommentierst du es dann
Und warum schreibst du nur unsinnige Behauptungen?
> BTW: Was soll diese beschämend dämliche Einrückung in deinen Postings?
> Wohl mit auch mit dem Newsreader deutlich überfordert, wie?
>
>
>> Was soll denn die Länge sein?
>
>
> Platzbedarf.
Das braucht man nur bei untauglichen Programmiersprachen. Der
Platzbedarf ist redundant. Ein Text brauch genau so viel Platz, wie er
lang ist.
[...]
>> Die Interpretation der Daten geht xml nicht an. Und ob es eine
>> clevere Idee ist sich auf Längenangaben in einer Datei die
>> sonstwoher kommen kann zu verlassen ? Nicht wirklich.
>
>
> Wenn du es nicht verstehst, wieso kommentierst du es dann?
Bullshit. Die Frage wurde nicht beantwortet. Sich auf die Längenangeben
von externen Daten zu verlassen ist unsinnig. Damit ist die Längenangabe
unsinnig.
>>> b) XML ist nicht hinreichend.
>>
>> ...für was?
>
>
> Für die in der Rationale dargelegten Anwendungsgebiete.
Bullshit. Das wird man ja wohl begründen müssen.
>> Tja, für jede Aufgabenstellung das geeignete Werkzeug. Man wird
>> seltenst alle auf einmal brauchen.
>
>
> Genau genommen braucht überhaupt keines davon.
Bullshit. Das wird man ja wohl begrunden müssen.
>>> c) XML ist nur eine Syntax. Semantische Validierung ist untrivial und
>>> sehr fummelig.
>>
>> Was willst Du uns mit diesen Allgemeinplätzen sagen?
>
>
> Sag bloß, ASN.1 kennst du also auch nicht?
> Deine Inkompetenz ist in der Tat beeindruckend, nur wieso lebst du sie
> nicht woanders aus? dag° bietet sich geradezu an für Experten deines
> Kalibers.
Sorry, du erzählst hier nur Unsinn und versuchst andere Leute persönlich
zu beleidigen.
Es ist egal, ob das interpretieren der Semantik aufwendig ist, oder
nicht. Die Syntaxanalyse fällt weg und es ist somit einfacher die Daten
zu analysieren. Weniger Arbeit ist weniger Arbeit.
Wie aufwendig eine Semantik ist, kann man außerdem eh nicht allgemein
beantworten.
>>> d) XSLT ist ein Albtraum. Die Größe und Performance der bestehenden
>>> Implementierungen sprechen für (oder besser: gegen) sich.
>>
>> Niemand zwingt dich XSLT zu nutzen. Es hat seine Anwendungsbereiche,
>> und wenn es nicht passt gibt es reichlich Alternativen.
>
>
> Mir ist noch kein keiner begegnet.
XSLT funktioniert nach meinen Erfahrungen ganz hervorragend. Sowohl für
die Konvertierung von Daten, als auch für das Erstellen von Layouts.
>>> e) XML ist eine unglaubliche Platzverschwendung. Und was entblöden
>>> sich die XML-Leute jetzt ernsthaft als Lösung vorzuschlagen: man
>>> kann ja ein Kompressions-Layer darüber packen! Holy CPU Burnout,
>>> Batman!
>>
>> Das meinst Du jetzt bitte nicht ernst.
>
>
> Na _ich_ hab mir das nicht ausgedacht!
Nun ja, wenn man jemanden mutwillig fehlinterpretierten will. Platz ist
heute genug vorhanden. Man kann nicht um jedes Byte jammern, was man
weniger produzieren könnte.
Die ganzen Internet-Protokolle auf der Anwendungsebene (ftp, smtp) und
Dateiformate (Mail, News, HTML) sind alle keine Meister des
Platzsparens. Das hat auch seinen Grund. Es geht darum die Daten
möglichst lesbar zu gestalten um sie einfacher handhaben zu können.
Einen gesonderten Layer für die Komprimierung von Daten halte ich auch
für unsinnig. Komprimierung ist mittlerweile ein so weitreichendes
Thema, dass sie direkt in die Betriebssysteme als zentraler Service
eingebaut werden müsste. Ansonsten werden die Platten halt grösser.
>>> f) Das gibt es alles schon mal in besser.
>>
>> Mag sein. Besser für was? Welche Verbreitung? Mir ist xml mit seiner
>> Verbreitung und der Menge an Werkzeugen lieber als irgendeine tolle
>> Spielerei mit dem Verbreitungsgrad 0.
>
> Die Verbreitung resultiert direkt aus der Anzahl der Vollidioten in der
> IT-Branche. Ich habe genau keinerlei Interesse daran, mit Idioten oder
> von Idioten geschriebener Software zu interagieren.
Verkürzen wir den Satz auf "Ich habe genau keinerlei Interesse daran
[...] zu interagieren.".
Genau.
Dann kann ich auch verstehen, warum XML nix für dich ist. XML braucht
man, damit alle sich untereinander verstehen. Ungeachtet davon, ob es
sich um "Idioten", "Ex-Amigabenutzer", "Neger", "Weisse", "Juden",
"Christen" oder "Moslems" handelt.
> Im Übrigen, warum setzt du nicht Windoze ein, das ist noch viel
> verbreiteter als Unix!
Im Übrigen, warum setzt du nicht 'nen Amiga ein, da waren damals auch
immer genug Leute, die sich gegen alles eingesetzt haben, nur weil es
auch unter Windows funktionierte.
Aber anscheinend müssen die heute unbedingt Unix benutzen.
>>>Ich warte schon gespannt auf eine Welle von Exploits für
>>>XML-Parser-Probleme, mit der sich dann die ganzen tollen standardisierten
>>>Web-Portale fernsteuern lassen. Was man bei einer naiven Implementation
>>>falsch machen kann, wird garantiert irgendwo auch falsch gemacht werden.
>>
>> Und das hat jetzt mit xml was zu tun... ?
>
>
> Wenn du es nicht verstehst, wieso kommentierst du es dann?
Und warum schreibst du andauernd Bullshit, wenn jemand deine
unbegründeten Behauptungen hinterfragt?
>> XP & Fup2 dcoud
>
>
> Das war wohl nichts.
Nee ... tatsächlich nicht.
Bis denne ...
Marcus
Stefan Nobis
> Buffer Overflows sind Probleme von veralteten Programmiersprachen und kein
> Problem des XML-Syntax.
Das ist ja nun schon eine gewagte These. Ich würde da schon fast eher
zu "Buffer Overflows sind Probleme von unfähigen Programmierern"
tendieren.
Aber gleich kommst du bestimmt mit so genialen Sprache wie Java oder
C#, die voll ultra cool sind -- und die dafür sorgen, dass auch ein
2GHz Pentium mit 4GB RAM irgendwann selbst für Textverarbeitung viel
zu klein dimensioniert ist.
> Bullshit. Die Frage wurde nicht beantwortet. Sich auf die
> Längenangeben von externen Daten zu verlassen ist unsinnig. Damit
> ist die Längenangabe unsinnig.
Schon aus Redundanzgründen ist dein Bullshit ziemlich dämlich. Je mehr
Redundanz, desto leichter fallen i.d.R. z.B. auch
Plausibilitätsprüfungen. Von Fehlererkennung/-korrektur mal zu
schweigen.
> >>> c) XML ist nur eine Syntax. Semantische Validierung ist untrivial und
> >>> sehr fummelig.
> >>
> >> Was willst Du uns mit diesen Allgemeinplätzen sagen?
> > Sag bloß, ASN.1 kennst du also auch nicht?
> Es ist egal, ob das interpretieren der Semantik aufwendig ist, oder
> nicht. Die Syntaxanalyse fällt weg und es ist somit einfacher die
> Daten zu analysieren. Weniger Arbeit ist weniger Arbeit.
OK. Du packst in dein Programm eine Megalibrary, die ohne Ende RAM und
Rechenpower frisst, um ein extrem aufgeblähtes Dateiformat zu
parsen. Und dann findest du das auch noch obercool.
Was ist denn so ein großes Problem, stattdessen eine simple, kleine
Library zu nehmen (oder eben schnell selbst zusammenzustricken), die
einfache, klare, kompakte Dateiformate parst. Dein Aufwand ist genauso
gering, dein Programm frisst bedeutend weniger Resourcen.
Ach ja, ich vergaß. Es muss ja unbedingt ein Grund geschaffen werden,
um 2GH Rechner mit einigen GB RAM irgendwie zu beschäftigen. Sorry,
wie konnte ich nur.
Nicht zu vergessen, dass du das eigentlich Kernargument (Problem
Validierung) offensichtlich gar nicht verstanden hast. Ein
validierender XML-Parser ist nicht nur riesengroß, der ist auch noch
so komplex, dass der extrem Fehleranfällig ist. Und schon ist der
große Vorteil (tolle Lib, leicht zu benutzen) gleich wieder im Arsch.
> Wie aufwendig eine Semantik ist, kann man außerdem eh nicht
> allgemein beantworten.
Die Semantik von XML-Dateien, die der Parser validieren soll, ist aber
beurteilbar: Die ist recht komplex. Das führt überproportional schnell
zu Fehlern.
> Nun ja, wenn man jemanden mutwillig fehlinterpretierten will. Platz
> ist heute genug vorhanden. Man kann nicht um jedes Byte jammern, was
> man weniger produzieren könnte.
Ja, diese saublöden Sprüche kenne ich. Hast du schon mal an die Firma
gedacht, die ihre Hardware nur alle 5-10 Jahre *teilweise*
erneuert. Da steht dann plötzlich kein 2GH Pentium, 4GB RAM mit 2 TB
RAID-Array, da gibt's dann plötzlich nur ein Pentium-100, 64MB RAM und
die Platte hat auch nur noch 20MB frei. Und mit diesen Eckwerten kann
ein guter Programmierer wirklich sehr, sehr viel machen.
Hey, i.d.R. soll deine Software nicht auf einem eigenen,
hochgerüsteten Rechner laufen -- da soll auch andere Software
laufen. Wenn jeder so denken würde wie du, gäbe es heute ganz sicher
kein Internet.
> Die ganzen Internet-Protokolle auf der Anwendungsebene (ftp, smtp)
> und Dateiformate (Mail, News, HTML) sind alle keine Meister des
> Platzsparens. Das hat auch seinen Grund. Es geht darum die Daten
> möglichst lesbar zu gestalten um sie einfacher handhaben zu können.
Oh, nicht einmal das hast du verstanden. Ein gutes Protokoll zu
designen ist wirklich nicht gerade leicht, aber ich dachte nicht, dass
es so schwer ist, die Ideen anderer, ausführlich kommentiert, zu
verstehen. Hast du auch schon mal in einen RFC geschaut? Auch schon
mal versucht zu verstehen, was da so geschrieben steht?
> Einen gesonderten Layer für die Komprimierung von Daten halte ich
> auch für unsinnig. Komprimierung ist mittlerweile ein so
> weitreichendes Thema, dass sie direkt in die Betriebssysteme als
> zentraler Service eingebaut werden müsste. Ansonsten werden die
> Platten halt grösser.
Was bitte stammelst du da? "Komprimierung... ein so weitreichendes
Thema"? Sag mal, bist du irgendwie auf Drogen oder sowas? Was ist da
weitreichend? Wieso gehört das ins Betriebssystem (OK, Kompression
on-the-fly auf Dateisystemebne ist ganz nett, aber das können doch eh
schon so ziemlich alle Systeme)?
> Dann kann ich auch verstehen, warum XML nix für dich ist. XML
> braucht man, damit alle sich untereinander verstehen. Ungeachtet
Prust! Du meinst auch, problemlosen Datenaustausch zwischen den
unterschiedlichsten Systemen gibt es erst seit XML, wie?
Ich habe schon problemlos Daten vom Amiga meines Cousins auf meinem
C64 verarbeitet, da war der 386er noch nicht mal aus seiner
Silizium-Scheibe gestanzt worden.
XML ist im Großen und Ganzen so ziemlich das dämlichste, was gerade so
an Hype durch die IT-Landschaft tigert. Es gibt ein paar wenige,
begrenzte Bereiche, in denen es Sinn macht. Aber der Hype und dieses
"XML für alles" ist einfach nur schwachsinnig.
Konfigurationsdateien in XML -- das ist grober Unfug, das gehört
eigentlich schon mit Berufsverbot bestraft. Von dem ganzen anderen
Müll, der da so getrieben wird, mal zu schweigen.
--
Stefan.
Felix von Leitner
> Moin ...
Was soll dieser wiederholte peinliche Versuch, die Newsgroup zu
wechseln? Reicht es dir nicht, dich in dcoup zum Deppen zu machen, oder
kennt man deine Fähigkeiten in dcoud schon und nimmt dich da eh nicht so
ernst?
Wenn ich das in dcoud hätte besprechen wollen, hätte ich es dort
gepostet. Troll, elender!
> >> Eine Syntax provoziert Buffer Overflows. Ah, ja.
> >Wenn du es nicht verstehst, wieso kommentierst du es dann?
> Buffer Overflows sind Probleme von veralteten Programmiersprachen und
> kein Problem des XML-Syntax.
ROTFL
Dein Image vervollkommnet sich gerade. Du bist frisch immatrikuliert,
jobst bei myview als Hiwi-Kaffeekocher, hast noch nie eine Zeile Code
produziert, hälst HTML für eine Programmiersprache.
Dein weltfremdes Gefasel könnte man unter Umständen gelten lassen, wenn
du in Forth auf Embedded-Geräten programmieren würdest. Du bist aber
hier in einer UNIX-Newsgroup und Unix ist zufällig in C implementiert,
genau wie der Perl Interpreter, die libc, die JVM und die diversen
anderen Building Blocks.
Schade, daß du schon vorher keinen nennenswerten Ruf hattest, den du dir
mit dieser Lachnummer gerade hättest ruinieren können.
> >Wenn du es nicht verstehst, wieso kommentierst du es dann
> Und warum schreibst du nur unsinnige Behauptungen?
Harhar, das mag jeder für sich selber entscheiden, wer hier ein
inkompetenter Schwätzer ist. Wo ist noch gleich deine Homepage mit
deinen Credentials?
> >BTW: Was soll diese beschämend dämliche Einrückung in deinen Postings?
> >Wohl mit auch mit dem Newsreader deutlich überfordert, wie?
> >
> >
Und das mit dem Quoten üben wir auch noch mal, gell?
> >> Was soll denn die Länge sein?
> >Platzbedarf.
> Das braucht man nur bei untauglichen Programmiersprachen.
Ah, Platz brauchen nur untaugliche Programmiersprachen.
Deine Programmiersprache muß ihre Eingaben nicht speichern, sie benutzt
dafür einen perfekten Zufallszahlengenerator oder PI und speichert nur
die Position oder wie? Oder machst du das lieber direkt mit dem
Kristallkugelinterface?
Mann, du bist ja so eine Lachnummer, da gibt es echt keine Worte mehr für.
> Der Platzbedarf ist redundant.
EBEN. Das ist genau die Beschwerde. XML ist in unglaublichem Maße
redundant, aber nicht so, daß man damit Fehlerkorrektur oder auch nur
-Erkennung betreiben könnte.
> Ein Text brauch genau so viel Platz, wie er lang ist.
Plus Markup, ja.
Oder willst du sagen, daß du einen strukturierten Datenstrom mit 10k
Nutzdaten verteilt auf 100 Records mit je 7 Feldern mit (oder ohne) XML
und ohne Kompression der Nutzdaten in 10k abbilden kannst? Das will ich
sehen. Das ist geradezu nobelpreisverdächtig! Das schafft nicht mal
ASN.1 oder CSV!
> >> Die Interpretation der Daten geht xml nicht an. Und ob es eine
> >> clevere Idee ist sich auf Längenangaben in einer Datei die
> >> sonstwoher kommen kann zu verlassen ? Nicht wirklich.
> >Wenn du es nicht verstehst, wieso kommentierst du es dann?
> Bullshit. Die Frage wurde nicht beantwortet. Sich auf die Längenangeben
> von externen Daten zu verlassen ist unsinnig.
Man sieht, daß du noch nie einen Parser geschrieben hast.
Du betreibst hier gerade das Usenet-Äquivalent vom sich öffentlich in
die Hose pinkeln.
Man liest die Länge, alloziert so viel Speicher, und wenn dann mehr
kommt, bricht man komplett ab. Das ist schon mal einfach so eine
Größenordnung effizienter als typische realloc-Implementationen.
> Damit ist die Längenangabe unsinnig.
Du bist ein Knallkopf sondergleichen.
> >>> b) XML ist nicht hinreichend.
> >> ...für was?
> >Für die in der Rationale dargelegten Anwendungsgebiete.
> Bullshit. Das wird man ja wohl begründen müssen.
Die Rationale IST die Begründung! Gibt es eigentlich _irgendein_
Detail dieser Diskussion, mit dem du dich auch nur in Ansätzen
vertraut bist? Das ist ja wirklich grotesk, was du hier bietest.
> >> Tja, für jede Aufgabenstellung das geeignete Werkzeug. Man wird
> >> seltenst alle auf einmal brauchen.
> >Genau genommen braucht überhaupt keines davon.
> Bullshit. Das wird man ja wohl begrunden müssen.
Zeige ein einziges Problem, das man nur mit XML oder nur mit XSLT lösen
kann, und das nicht "Kompatibilität mit XML" oder "Kompatibilität mit
XSTL" heißt oder beinhaltet.
Gibt es nicht? Genau meine Rede.
> >>> c) XML ist nur eine Syntax. Semantische Validierung ist untrivial und
> >>> sehr fummelig.
> >> Was willst Du uns mit diesen Allgemeinplätzen sagen?
> >Sag bloß, ASN.1 kennst du also auch nicht?
> >Deine Inkompetenz ist in der Tat beeindruckend, nur wieso lebst du sie
> >nicht woanders aus? dag° bietet sich geradezu an für Experten deines
> >Kalibers.
> Sorry, du erzählst hier nur Unsinn und versuchst andere Leute persönlich
> zu beleidigen.
Soso, ich erzähle also Unsinn. Gut, daß du dem ASN.1-Dingens komplett
ausgewichen bist, sonst wäre das Ausmaß deiner Pfuscherei offenbar
geworden.
Vielleicht willst du jetzt kurz dazu Stellung nehmen?
Tu es für die zukünftigen Generationen, denn die aktuellen haben dich
schon alle im Killfile.
> Es ist egal, ob das interpretieren der Semantik aufwendig ist, oder
> nicht.
Ein Satz, zwei Grammatikfehler. Beeindruckend. Und du willst uns hier
was von Semantik erzählen?
> Die Syntaxanalyse fällt weg und es ist somit einfacher die Daten
> zu analysieren.
Aha. Soso, die Syntaxanalyse fällt also weg.
Brilliant! Du hast einen XML-Parser ohne Parser (Parsen ist ein Synonym
für Syntaxanalyse) geschrieben! Das ist eine bahnbrechende
Errungenschaft! Hast du das irgendwo publiziert, damit wir das
entsprechend würdigen können?
Hast du dich mal in einer ruhigen Minute gefragt, wieso man von
XML-Parsern spricht, wenn XML deiner Meinung nach das Parsen eliminiert?
> Weniger Arbeit ist weniger Arbeit.
Diese profunden Weisheiten aus dem Fundus deiner Lebensweisheit sind es,
die deine Postings so wertvoll machen.
> Wie aufwendig eine Semantik ist, kann man außerdem eh nicht allgemein
> beantworten.
Semantik? Aufwändig? Warum greifst du dir nicht mal ein Lexikon oder
ein Informatikbuch und informierst dich über die Bedeutung der Worte,
mit denen du hier um dich wirfst?
Semantik ist die Bedeutung von Symbolen oder die Beziehung der
Bedeutungen von Symbolen.
Mit Aufwand hat das genau nichts zu tun. Ich habe ja schon eine Menge
Leute dabei beobachten dürfen, wie sie sich komplett lächerlich machen,
aber deine Effizienz darin ist beeindruckend.
> >> Niemand zwingt dich XSLT zu nutzen. Es hat seine Anwendungsbereiche,
> >> und wenn es nicht passt gibt es reichlich Alternativen.
> >Mir ist noch kein keiner begegnet.
> XSLT funktioniert nach meinen Erfahrungen ganz hervorragend. Sowohl für
> die Konvertierung von Daten, als auch für das Erstellen von Layouts.
Ah, die Konvertierung von Daten also. Ich mail dir mal ein PDF, das
konvertierst du dann mit XSLT in eine Word-Datei.
> Nun ja, wenn man jemanden mutwillig fehlinterpretierten will. Platz ist
> heute genug vorhanden.
Nein.
> Man kann nicht um jedes Byte jammern, was man weniger produzieren
> könnte.
Aha, wie Computer funktionieren, was eine Speicherhierarchie ist, was
Caches sind, das weißt du auch alles nicht, ja?
Du bist ja wirklich außerordentlich wohlqualifiziert, um dich hier über
Programmier-Fragen zu äußern.
> Die ganzen Internet-Protokolle auf der Anwendungsebene (ftp, smtp) und
> Dateiformate (Mail, News, HTML) sind alle keine Meister des
> Platzsparens.
FTP und SMTP sind sehr platzsparend. Mail und News sind nicht toll,
aber auch nicht auffallend schlecht, im krassen Gegensatz zu HTML.
HTML kommt ja auch von den gleichen Versagern, den wir SGML und XML zu
verdanken haben, das verwundert also nicht weiter.
> Das hat auch seinen Grund. Es geht darum die Daten möglichst lesbar zu
> gestalten um sie einfacher handhaben zu können.
Aha, HTML ist also besonders gut lesbar. Klar, das erklärt sofort den
Markt an HTML-Editoren und die vielen kaputten HTML-Parser.
Und Buffer Overflows hat es in den diversen HTML- und HTTP- ja auch noch
nie gegeben, wie? Du willst mir hier nicht ernsthaft gerade sagen, daß
XML nicht so schlimm ist, weil HTML auch scheiße ist, oder?
> Einen gesonderten Layer für die Komprimierung von Daten halte ich auch
> für unsinnig. Komprimierung ist mittlerweile ein so weitreichendes
> Thema, dass sie direkt in die Betriebssysteme als zentraler Service
> eingebaut werden müsste.
ROTFL
Klar, sollen die ruhig alle rumbloaten, das System wird's schon richten.
> Ansonsten werden die Platten halt grösser.
Dem ist nichts hinzuzufügen.
> >Die Verbreitung resultiert direkt aus der Anzahl der Vollidioten in der
> >IT-Branche. Ich habe genau keinerlei Interesse daran, mit Idioten oder
> >von Idioten geschriebener Software zu interagieren.
> Verkürzen wir den Satz auf "Ich habe genau keinerlei Interesse daran
> [...] zu interagieren.".
Oh, ich interagiere mit allen möglichen Protokollen und Programmen.
Nur mit Heiße-Luft-Appareten wie z.B. deiner Wenigkeit muß ich nichts
austauschen.
> >Im Übrigen, warum setzt du nicht Windoze ein, das ist noch viel
> >verbreiteter als Unix!
> Im Übrigen, warum setzt du nicht 'nen Amiga ein, da waren damals auch
> immer genug Leute, die sich gegen alles eingesetzt haben, nur weil es
> auch unter Windows funktionierte.
Du bist ja so derartig stoned, du merkst nicht mal, wenn man deine
Äußerungen persifliert! Unglaublich.
Merkbefreiung jetzt!
Henrik Motakef
> Man liest die Länge, alloziert so viel Speicher, und wenn dann mehr
> kommt, bricht man komplett ab.
Das macht es demjenigen, der den Parser schreibt, einfach. Ich vermute
aber mal, dass mehr XML-Dokumente als XML-Parser geschrieben werden,
und die meisten Leute, die Dokumente verfassen, könnten es als lästig
ansehen, wenn sie jeweils die Länge für alle Elemente angeben müssten.
Man könnte sie natürlich schon von vornherein festlegen, aber selbst
wenn man die Menge der akzeptablen Dokumente auf Haikus beschränkt,
wird das nicht reichen.
Wenn es dir zu kompliziert ist, einen XML-Parser zu schreiben, ist das
ja zum Glück auch kein Problem. Es gibt ja schon genug.
> Zeige ein einziges Problem, das man nur mit XML oder nur mit XSLT lösen
> kann, und das nicht "Kompatibilität mit XML" oder "Kompatibilität mit
> XSTL" heißt oder beinhaltet.
Womit würdest du Textmarkup betreiben wollen?
> FTP und SMTP sind sehr platzsparend. Mail und News sind nicht toll,
> aber auch nicht auffallend schlecht, im krassen Gegensatz zu HTML.
Das HTML keine besonders tolle Markupsprache ist, mag ja stimmen, aber
das der /Platzbedarf/ das große Problem sein soll, habe ich auch noch
nicht gehört. Kannst du mal ein Beispiel geben, wie man die
Information, die ein HTML-Dokument enthält, viel kompakter darstellen
kann? (Zusatzpunkte gibt es für die Beachtung der unten folgenden
Anforderung an die Lesbarkeit und die Erklärung der Begriffe NET,
SHORTTAG und OMITTAG.)
> HTML kommt ja auch von den gleichen Versagern, den wir SGML und XML zu
> verdanken haben, das verwundert also nicht weiter.
Genau. Wie allgemein bekannt, hat Charles Goldfarb, nachdem IBM
zusammen mit dem Cern die ISO übernommen und in W3C umbenannt hat, den
Künstlernamen "Berners-Lee" angenommen, um unerkannt die
Weltherrschaft an sich zu reissen. Die Situation konnte nur durch eine
Thailändisch-Japanische Verschwörung entspannt werden.
>> Das hat auch seinen Grund. Es geht darum die Daten möglichst lesbar zu
>> gestalten um sie einfacher handhaben zu können.
>
> Aha, HTML ist also besonders gut lesbar. Klar, das erklärt sofort den
> Markt an HTML-Editoren und die vielen kaputten HTML-Parser.
Hattest du nicht ASN.1 ins Spiel gebracht? Findest du roff irgendwie
lesbarer?
Und für den Tagsoup-Unsinn in den bekannten HTML-verarbeitenden
Systemen kann *ML nun wirklich nichts, ich glaube kaum, dass ein
Netscape-C-Kompiler irgendwie angenehmer wäre... Wenn die Leute, die
eine Spezifikation umsetzen sollen, lieber raten, was darin stehen
könnte, als mal einfach nachzuschlagen, ist das ein klarer Fall von
PEBKAC.
Wie wärs mit einem Followup in eine Gruppe, in der das On Topic ist?
mfg
Henrik
Felix von Leitner
> > Man liest die Länge, alloziert so viel Speicher, und wenn dann mehr
> > kommt, bricht man komplett ab.
> Das macht es demjenigen, der den Parser schreibt, einfach.
Genau. Und der ist der wichtige.
> Ich vermute aber mal, dass mehr XML-Dokumente als XML-Parser
> geschrieben werden, und die meisten Leute, die Dokumente verfassen,
> könnten es als lästig ansehen, wenn sie jeweils die Länge für alle
> Elemente angeben müssten.
Es macht keinen Sinn, eine Datenaustauschsyntax darauf auszulegen, daß
sie von Menschen manipuliert werden kann. Ich kenne jedenfalls keine
Firma, die ihre Datenbanken mit vi editiert.
Ein Austauschformat für strukturierte Daten sollte so ausgelegt sein,
daß man es einfach lesen und schreiben kann. Wenn man im Notfall auch
mit less reinschauen und mit vi reparieren kann, ist das nett, aber das
sollte nicht Nachteile an anderer Stelle mit sich bringen.
> Man könnte sie natürlich schon von vornherein festlegen, aber selbst
> wenn man die Menge der akzeptablen Dokumente auf Haikus beschränkt,
> wird das nicht reichen.
Wieso? Warum sollte dein Editor nicht (evtl. mit einem Makro-Paket) in
der Lage sein, die Längen mit zu editieren?
> Wenn es dir zu kompliziert ist, einen XML-Parser zu schreiben, ist das
> ja zum Glück auch kein Problem. Es gibt ja schon genug.
Hey, ich verdiene mein Geld damit, Fehler in anderer Leute Code zu
suchen, zu finden und auszunutzen. Ich habe mehr schlechten Code
gesehen als dir in deinem ganzen Leben begegnen wird. Probleme kommen
daher, daß Programmierer das Problem nicht vollständig verstehen und im
Zweifelsfall den einfachen Weg wählen.
Und bevor du wieder jemandem unterstellst, daß ihm etwas zu kompliziert
ist, schau dir mal auf meiner Homepage an, was ich so für Projekte
mache. Möglicherweise ersparst du dir dann, dich so derartig zum Deppen
zu machen wie du es hier gerade geleistet hast.
> > Zeige ein einziges Problem, das man nur mit XML oder nur mit XSLT lösen
> > kann, und das nicht "Kompatibilität mit XML" oder "Kompatibilität mit
> > XSTL" heißt oder beinhaltet.
> Womit würdest du Textmarkup betreiben wollen?
TeX? Postscript? PDF? Roff? Es gibt dutzende Lösungen dafür.
Das war wohl gar nichts.
> > FTP und SMTP sind sehr platzsparend. Mail und News sind nicht toll,
> > aber auch nicht auffallend schlecht, im krassen Gegensatz zu HTML.
> Das HTML keine besonders tolle Markupsprache ist, mag ja stimmen, aber
> das der /Platzbedarf/ das große Problem sein soll, habe ich auch noch
> nicht gehört.
Seit ich auf fefe.de den Webserver von .html auf .html.gz umgestellt
habe, wenn der Browser das kann, hat sich mein gesamter
Internet-Durchsatz halbiert, und da sind auch Emails und sonstiges
Arbeiten auf dem Server drin. Und mein HTML ist bereits mehr als
sparsam.
> Kannst du mal ein Beispiel geben, wie man die Information, die ein
> HTML-Dokument enthält, viel kompakter darstellen kann? (Zusatzpunkte
> gibt es für die Beachtung der unten folgenden Anforderung an die
> Lesbarkeit und die Erklärung der Begriffe NET, SHORTTAG und OMITTAG.)
Auch da gibt es dutzende von Möglichkeiten.
> > HTML kommt ja auch von den gleichen Versagern, den wir SGML und XML zu
> > verdanken haben, das verwundert also nicht weiter.
> Genau. Wie allgemein bekannt, hat Charles Goldfarb, nachdem IBM
> zusammen mit dem Cern die ISO übernommen und in W3C umbenannt hat, den
> Künstlernamen "Berners-Lee" angenommen, um unerkannt die
> Weltherrschaft an sich zu reissen.
Keine Ahnung, wer Berners-Lee sein soll, aber Herr Barners-Lee hat sich
explizit an SGML angelehnt und deshalb sind die SGML-Leute mit Schuld.
Das steht übrigens auch so in seinem Buch.
Aber du faselst lieber als dich zu informieren. Schon klar.
> >> Das hat auch seinen Grund. Es geht darum die Daten möglichst lesbar zu
> >> gestalten um sie einfacher handhaben zu können.
> > Aha, HTML ist also besonders gut lesbar. Klar, das erklärt sofort den
> > Markt an HTML-Editoren und die vielen kaputten HTML-Parser.
> Hattest du nicht ASN.1 ins Spiel gebracht? Findest du roff irgendwie
> lesbarer?
Who cares? "Lesbarkeit" ist subjektiv. Ich persönlich kann roff und
TeX besser lesen als HTML.
Felix
Stefan Nobis
> > Die Syntaxanalyse fällt weg und es ist somit einfacher die Daten
> > zu analysieren.
>
> Aha. Soso, die Syntaxanalyse fällt also weg.
[...]
> Hast du dich mal in einer ruhigen Minute gefragt, wieso man von
> XML-Parsern spricht, wenn XML deiner Meinung nach das Parsen eliminiert?
Du hast ihn falsch verstanden: Er meinte, er kann jetzt endlich eine
tolle, fertige Bibliothek verwenden...
> > Weniger Arbeit ist weniger Arbeit.
...und daher hat er selbst dann weniger Arbeit.
Ihm ist nur noch nie in den Sinn gekommen, dass man das auch ohne XML
genauso gut erreichen kann und obiges kein Alleinstellungsmerkmal von
XML ist.
> HTML kommt ja auch von den gleichen Versagern, den wir SGML und XML
> zu verdanken haben, das verwundert also nicht weiter.
Nun mach aber mal halblang. Für ihren Bereich, nämlich Textmarkup,
klassisches Beispiel Buch, gibt es ja nun wohl keine ernsthafte
Alternative. Da sind SGML und XML sinnvoll und gut und dort spielen
sie auch ihre Stärken aus (und dort sind Längenangaben auch nicht
wirklich sinnvoll).
Was sonst nimmst du zum Textmarkup? TeX? nroff? Wo sind da die
qualitativen Unterschiede zu SGML/XML?
> Klar, sollen die ruhig alle rumbloaten, das System wird's schon
> richten.
Das ist leider eine stark verbreitete Denkweise.
"Wie jetzt? Da laufen auch noch andere Programme auf dem Rechner außer
meinem? Und das auch noch gleichzeitig? Unglaublich!"
"Wie, Prozessorcache? Und mein Programm wird wirklich deutlich
schneller, wenn ich hier mal die Daten etwas abspecke und geschickter
organisiere? Das kann doch gar nicht sein und überhaupt gibt's doch
inzwischen schon einen Pentium 2,4GHz. Da brauch ich doch gar nicht
optimieren! Und Quicksort ist mir auch viel zu kompliziert! Alles
blöder Unsinn!"
--
Stefan.
Felix von Leitner
> > zu verdanken haben, das verwundert also nicht weiter.
> Nun mach aber mal halblang. Für ihren Bereich, nämlich Textmarkup,
> klassisches Beispiel Buch, gibt es ja nun wohl keine ernsthafte
> Alternative.
Zu SGML?
Wie viele Bücher werden denn mit SGML geschrieben?
Meiner vorsichtigen Schätzung von außen sind das weniger als mit TeX
(und ich zähle O'Reilly nicht, weil sie explizit SGML-Evangelismus
betreiben).
> Da sind SGML und XML sinnvoll und gut und dort spielen sie auch ihre
> Stärken aus
Auch da kann man geteilter Meinung sein.
Normale Autoren (d.h. keine Techniker) haben keinen Bock, sich mit
Markup-Sprachen zu beschäftigen. Außerdem der Techniker-Community sind
sogar Schreibmaschinen und Diktiergeräte verbreitet!
> (und dort sind Längenangaben auch nicht wirklich sinnvoll).
Keine Frage.
> Was sonst nimmst du zum Textmarkup? TeX? nroff? Wo sind da die
> qualitativen Unterschiede zu SGML/XML?
Sie sind auch nicht deutlich besser. Das entkräftet meine Kritik an
SGML allerdings nicht.
> "Wie, Prozessorcache? Und mein Programm wird wirklich deutlich
> schneller, wenn ich hier mal die Daten etwas abspecke und geschickter
> organisiere? Das kann doch gar nicht sein und überhaupt gibt's doch
> inzwischen schon einen Pentium 2,4GHz. Da brauch ich doch gar nicht
> optimieren! Und Quicksort ist mir auch viel zu kompliziert! Alles
> blöder Unsinn!"
Jawoll, ab jetzt s/qsort/bogosort/. Prost!
Henrik Motakef
> Thus spake Henrik Motakef (henrik....@web.de):
>>> Man liest die Länge, alloziert so viel Speicher, und wenn dann mehr
>>> kommt, bricht man komplett ab.
>> Das macht es demjenigen, der den Parser schreibt, einfach.
>
> Genau. Und der ist der wichtige.
Fällt dir dazu irgendeine Begründung ein?
>> Man könnte sie natürlich schon von vornherein festlegen, aber selbst
>> wenn man die Menge der akzeptablen Dokumente auf Haikus beschränkt,
>> wird das nicht reichen.
>
> Wieso? Warum sollte dein Editor nicht (evtl. mit einem Makro-Paket) in
> der Lage sein, die Längen mit zu editieren?
Diese Lösung besticht durch Einfachheit und Eleganz.
> Und bevor du wieder jemandem unterstellst, daß ihm etwas zu kompliziert
> ist, schau dir mal auf meiner Homepage an, was ich so für Projekte
> mache.
Ich kenne deine Homepage und weiss im Groben, was du machst; du
versäumst es selten, darauf hinzuweisen. Daher mein Erstaunen.
>>> Zeige ein einziges Problem, das man nur mit XML oder nur mit XSLT lösen
>>> kann, und das nicht "Kompatibilität mit XML" oder "Kompatibilität mit
>>> XSTL" heißt oder beinhaltet.
>> Womit würdest du Textmarkup betreiben wollen?
>
> TeX? Postscript? PDF? Roff? Es gibt dutzende Lösungen dafür.
Dir ist schon klar, dass man mit Texten mehr machen kann, als sie zu
drucken oder sonstwie darzustellen?
Weder Postscript noch PDF sind Markupsprachen. TeX und Roff sind IMHO
deutlich zu präsentationsorientiert, um allgemein benutzbar zu
sein. (TeX würde ich, was die Eignung für logisches Markup angeht,
knapp unterhalb von HTML mit starkem Einsatz von font-Elementen^WTags
sehen, nur dass man noch stärker Implementationsabhängig ist.)
Abgesehen davon, dass TeX und Roff nicht mit XML vergleichbar sind,
sondern eher mit einer Anwendung (oder meinetwegen mit einer
Architektur, dir man aber ja in XML unsinnigerweise abgeschafft hat).
Es wäre mir zumindest neu, dass Leute gewohnheitsmässig
domänenspezifische Vokabulare als TeX-Makros implementieren und diese
dann auch in interessanter Weise benutzen, von Roff ganz zu schweigen.
> Seit ich auf fefe.de den Webserver von .html auf .html.gz umgestellt
> habe, wenn der Browser das kann, hat sich mein gesamter
> Internet-Durchsatz halbiert, und da sind auch Emails und sonstiges
> Arbeiten auf dem Server drin. Und mein HTML ist bereits mehr als
> sparsam.
Das ist ja brennend interessant, aber haben wir nicht eigentlich über
Markupsprachen und nicht über die Features von HTTP geredet?
>>> HTML kommt ja auch von den gleichen Versagern, den wir SGML und XML zu
>>> verdanken haben, das verwundert also nicht weiter.
>> Genau. Wie allgemein bekannt, hat Charles Goldfarb, nachdem IBM
>> zusammen mit dem Cern die ISO übernommen und in W3C umbenannt hat, den
>> Künstlernamen "Berners-Lee" angenommen, um unerkannt die
>> Weltherrschaft an sich zu reissen.
>
> Keine Ahnung, wer Berners-Lee sein soll,
Der hier: http://www.w3.org/People/Berners-Lee/tim.gif
> aber Herr Barners-Lee hat sich explizit an SGML angelehnt
Er hat die Syntax benutzt, ja. "Angelehnt" trifft es ganz gut.
> und deshalb sind die SGML-Leute mit Schuld. Das steht übrigens auch
> so in seinem Buch.
Dann muss es ja stimmen.
>>>> Das hat auch seinen Grund. Es geht darum die Daten möglichst lesbar zu
>>>> gestalten um sie einfacher handhaben zu können.
>>> Aha, HTML ist also besonders gut lesbar. Klar, das erklärt sofort den
>>> Markt an HTML-Editoren und die vielen kaputten HTML-Parser.
>> Hattest du nicht ASN.1 ins Spiel gebracht? Findest du roff irgendwie
>> lesbarer?
>
> Who cares?
Du. Warum sonst hättest du was dazu geschrieben?
> "Lesbarkeit" ist subjektiv. Ich persönlich kann roff und
> TeX besser lesen als HTML.
Lesbarkeit ist natürlich nicht subjektiv, aber TeX, *ML und Roff tun
sich da wirklich nicht so irre viel. Dann können wir das Argument ja
abhaken.
Ich versuche noch mal ein XPost und F'up dctx; du scheinst es
übersehen zu haben. Oder was hat das bitte mit Unix zu tun?
mfg
Henrik
Stefan Nobis
> Wie viele Bücher werden denn mit SGML geschrieben?
Umfangreiche techniche Dokumentationen? AFAIK doch recht viele.
> Meiner vorsichtigen Schätzung von außen sind das weniger als mit TeX
Wie gesagt, mir ging's um das Grundsätzliche, auch Framemaker und
Co. würde ich prinzipiell in diese Klasse packen.
Ich persönlich greife ja auch meist eher zu TeX als SGML-Docbook, aber
das ist ja bei deiner grundsätzlichen Textmarkup-Kritik wohl eher
ein Nebenschauplatz.
> > Da sind SGML und XML sinnvoll und gut und dort spielen sie auch ihre
> > Stärken aus
>
> Auch da kann man geteilter Meinung sein.
> Normale Autoren (d.h. keine Techniker) haben keinen Bock, sich mit
> Markup-Sprachen zu beschäftigen. Außerdem der Techniker-Community sind
> sogar Schreibmaschinen und Diktiergeräte verbreitet!
Nun, von digitaler Dokumentenverarbeitung gehe ich schon aus, sonst
wird diese Betrachtung doch sehr müßig. Und ob nun der Autor selbst
das tippt oder jemanden tippen lässt ist ja nun auch nicht wirklich
spannend.
Ich dachte, wir reden hier primär über technische Aspekte?
> > Was sonst nimmst du zum Textmarkup? TeX? nroff? Wo sind da die
> > qualitativen Unterschiede zu SGML/XML?
>
> Sie sind auch nicht deutlich besser. Das entkräftet meine Kritik an
> SGML allerdings nicht.
Nein, wohl war. Auch ich halte SGML nicht gerade für eine
Offenbarung. Aber deine Kritik war doch sehr grundsätzlich und breit
gefächert (SGML, XML und Co) und da wäre dann halt schon die Frage
nach der Alternative interessant.
--
Stefan.
Dominik Boecker
x-post und f'up nach dciwam:
Es geht in diesem Posting tendenziell eher um HTML, als die Themen, die
in dcou* OnTopic wären.
> Thus spake Henrik Motakef (henrik....@web.de):
> > Das HTML keine besonders tolle Markupsprache ist, mag ja stimmen, aber
> > das der /Platzbedarf/ das große Problem sein soll, habe ich auch noch
> > nicht gehört.
>
> Seit ich auf fefe.de den Webserver von .html auf .html.gz umgestellt
Es geht um den Platzbedarf /von HTML/. Das, was Du gemacht hast, findet
beim Stichwort http statt und hat mit HTML selber nichts mehr zu tun.
> habe, wenn der Browser das kann, hat sich mein gesamter
> Internet-Durchsatz halbiert, und da sind auch Emails und sonstiges
> Arbeiten auf dem Server drin.
Glückwunsch. :-)
> Und mein HTML ist bereits mehr als sparsam.
Zu sparsam und deswegen fehlerhaft. Du schreibst Tagsuppe - zwar andere
als gemeinhin verbreitet - aber Tagsuppe und bist von einer gnädigen
Interpretation des UA abhängig.
Der Anfang des Parse-Trees von <http://fefe.de/> mit Kurzkommentaren:
| AVERSION CDATA -//W3C//DTD HTML 4.01 Transitional//EN
| <HTML>
| <HEAD>
| <TITLE>
| </TITLE>
| <LINK>
| </LINK>
| <BASE>
Bis hierhin schaut es gut aus, aber:
| </BASE>
| </HEAD>
| <BODY>
^^^^^^
| /www.fefe.de/>
Das kann wohl kaum gewollt sein. Und das liegt an der Zeile:
| <base href=http://www.fefe.de/>
Hier nutzt Du NET und eröffnest - ich unterstelle mal ohne es zu wollen
- den <body>, denn den schreibst Du später nochmals explizit in den
Quelltext rein:
| <BODY>
^^^^^^
Doppeltes <body> macht sich nicht allzugut..
| <P>
| I am co-founder of
| <A>
| </A>
| www.codeblau.de/>Code Blau and help
Whoops. Ein leerer Anker - kommt auf der Seite oft vor-.
Wenn der Browser sich an die Spezifikation halten würde, sähe die Zeile
"rückübersetzt" in sauberes HTML so aus:
| <p>I am co-founder of <a href="http:"></a>www.codeblau.de/>Code
| Blau</a> and...</p>
Da ist dann auch ein </a> zu viel.
> > Kannst du mal ein Beispiel geben, wie man die Information, die ein
> > HTML-Dokument enthält, viel kompakter darstellen kann? (Zusatzpunkte
> > gibt es für die Beachtung der unten folgenden Anforderung an die
> > Lesbarkeit und die Erklärung der Begriffe NET, SHORTTAG und OMITTAG.)
JFTR: SHORTTAG ist der Oberbegriff, dazu gehören bei HTML auch NET und
OMITTAG.
> Auch da gibt es dutzende von Möglichkeiten.
-v please. Außer denen fallen mir bei HTML nämlich keine mehr ein. RANK
und SHORTREF gehören nicht zu HTML (und auch nicht zu XML).
> Keine Ahnung, wer Berners-Lee sein soll, aber Herr Barners-Lee hat sich
> explizit an SGML angelehnt
Angelehnt trifft es. Vielleicht sogar besser, als Dir beim Schreiben
bewußt war, aber
> und deshalb sind die SGML-Leute mit Schuld.
halte ich für daneben. Wenn ich Aussagen von Deiner Webseit
mißverstehe(n will) und dann ein Buch schreibe:
> Das steht übrigens auch so in seinem Buch.
Dann bist Du schuld? Das kannst Du nicht ernst meinen..
Dominik
--
Der Ausspruch des Gerichtes "Die Entscheidung ist gebührenfrei" ist
auslegungsbedürftig.
Hartmann, Kostengesetze zu 1953 KV, Rn. 4
Gunnar Ritter
> Nun mach aber mal halblang. Für ihren Bereich, nämlich Textmarkup,
> klassisches Beispiel Buch, gibt es ja nun wohl keine ernsthafte
> Alternative. Da sind SGML und XML sinnvoll und gut und dort spielen
> sie auch ihre Stärken aus (und dort sind Längenangaben auch nicht
> wirklich sinnvoll).
> Was sonst nimmst du zum Textmarkup? TeX? nroff?
Wenn man ein Buch produzieren will, will man kein generisches
Markup. Wer gute Bücher herstellt weiß, daß ein Leser mit
mehr als vier Schrifttypen überfordert ist. Es ist also gerade
nötig, da ein visuelles Markup einzuführen. Deshalb macht man
gute Bücher mit qualifizierten, bewährten Satzprogrammen und
nicht mit XML. Die Aufgabe eines Setzers besteht gerade darin,
eine überorganisierte generische Markup-Wichse in etwas Lesbares
zu verwandeln. Ein Autor, der sich dieser Tatsache bewußt ist,
kann das auch gleich selbst machen.
Es gibt kaum etwas Häßlicheres als LaTeX-Bücher, in denen Dir
der Autor zeigen wollte, wie toll generisches Markup ist. Vor
den Perspektiven von unbereinigtem XML-Markup graust es einem
da nur. Aber ehe wir das vergessen, TeX und groff sind sogar
sehr brauchbare Satzprogramme, wenn man visuelles Markup macht.
Lies ein paar Einführungen in Typographie, bevor Du Dich wieder
öffentlich über Bücher äußerst.
> Wo sind da die qualitativen Unterschiede zu SGML/XML?
Wenn Du das nicht siehst, ist Dir echt nicht mehr zu helfen.
Gunnar
Claus Färber
> Es macht keinen Sinn, eine Datenaustauschsyntax darauf auszulegen, daß
> sie von Menschen manipuliert werden kann.
Wenn man die Daten nicht nur austauschen, sondern vielleicht auch
aufheben will, ist es schon sehr sinnvoll, ein Format zu nehmen, das
auch ein Mensch verstehen kann.
XML kann man -- auch ohne DTD -- auch in 2000 Jahren mit einer einfachen
Frequenzanalyse verstehen. Ein einfaches, aber womöglich binäres
Datenaustauschformat macht da schon eher Probleme.
> Ein Austauschformat für strukturierte Daten sollte so ausgelegt sein,
> daß man es einfach lesen und schreiben kann.
Und damit geht schon mal die Möglichkeit von Erweiterungen flöten.
> Hey, ich verdiene mein Geld damit, Fehler in anderer Leute Code zu
> suchen, zu finden und auszunutzen. Ich habe mehr schlechten Code
> gesehen als dir in deinem ganzen Leben begegnen wird. Probleme kommen
> daher, daß Programmierer das Problem nicht vollständig verstehen und im
> Zweifelsfall den einfachen Weg wählen.
Ah, alles klar. Wenn Programmierer anstatt einen neuen, fehlerhaften
Parsers für ihr einfaches, aber unklar spezifiziertes Format zu
schreiben einfach zu einer Bibliothek mit einem gut getesteten Parser
für ein bekanntes, gut-verstandenes Format greifen, dann hast du weniger
Aufträge zur Fehlersuche.
> TeX? Postscript? PDF? Roff? Es gibt dutzende Lösungen dafür.
> Das war wohl gar nichts.
Klar, und mit allen dieser Lösungen ist man unabhängig vom
Ausgabemedium, kann die Präsentation durch einfache Eingriffe (Suchen-
und-Ersetzen im Editor zählt nicht, weil das nicht gleich formatierte
Sachen unterscheiden kann, die man jetzt verschieden haben möchte)
ändern, usw.?
> Keine Ahnung, wer Berners-Lee sein soll, aber Herr Barners-Lee hat sich
> explizit an SGML angelehnt und deshalb sind die SGML-Leute mit Schuld.
> Das steht übrigens auch so in seinem Buch.
> Aber du faselst lieber als dich zu informieren. Schon klar.
Also http://www.w3.org/People/Berners-Lee/ kennt nur einen "Berners-
Lee", keinen "Barners-Lee". Habe ich was verpasst?
Claus
--
------------------------ http://www.faerber.muc.de/ ------------------------
OpenPGP: DSS 1024/639680F0 E7A8 AADB 6C8A 2450 67EA AF68 48A5 0E63 6396 80F0
Felix von Leitner
> > Keine Ahnung, wer Berners-Lee sein soll, aber Herr Barners-Lee hat sich
> > explizit an SGML angelehnt und deshalb sind die SGML-Leute mit Schuld.
> > Das steht übrigens auch so in seinem Buch.
> > Aber du faselst lieber als dich zu informieren. Schon klar.
> Also http://www.w3.org/People/Berners-Lee/ kennt nur einen "Berners-
> Lee", keinen "Barners-Lee". Habe ich was verpasst?
Ihr habt Recht, der Mann heißt Berners-Lee. Ich ziehe meine Aussage
zurück und behaupte das Gegenteil.
Felix
Felix von Leitner
> aufheben will, ist es schon sehr sinnvoll, ein Format zu nehmen, das
> auch ein Mensch verstehen kann.
Jedes Format, das eine Maschine verstehen kann, kann per Definition auch
ein Mensch verstehen.
> XML kann man -- auch ohne DTD -- auch in 2000 Jahren mit einer einfachen
> Frequenzanalyse verstehen. Ein einfaches, aber womöglich binäres
> Datenaustauschformat macht da schon eher Probleme.
Voraussage sind schwierig, insbesondere über die Zukunft.
--Niels Bohr
In 2000 Jahren haben die Amis versehentlich die Erde zerbombt und die
schwelenden Reste mit Biowaffen benetzt. Wer sagt dir denn, daß ich ein
binäres Format vorschlage? Ich bin schon ein Freund von Text, trotzdem
muß da eine Längenkodierung rein.
Im Übrigen gibt es ganze Industriezweige, die sich mit dem Reverse
Engineering von Binärdaten befassen. Die sind erstaunlich erfolgreich.
> > Ein Austauschformat für strukturierte Daten sollte so ausgelegt sein,
> > daß man es einfach lesen und schreiben kann.
> Und damit geht schon mal die Möglichkeit von Erweiterungen flöten.
Unfug.
HTTP war auch nicht auf Erweiterbarkeit ausgelegt, und sieh nur, was sie
fürchterliches daran verunstaltet haben. Erweitern kann man praktisch
immer. Ein sinnvolles Format muß man allerdings nicht erweitern, weil
es nicht mit irgendwelchen glorreichen Heldensagen daher kommt, was man
damit alles tun oder abbilden können soll, sondern es beschränkt sich
auf eine Nische, und die füllt es dann gut aus.
> > Hey, ich verdiene mein Geld damit, Fehler in anderer Leute Code zu
> > suchen, zu finden und auszunutzen. Ich habe mehr schlechten Code
> > gesehen als dir in deinem ganzen Leben begegnen wird. Probleme kommen
> > daher, daß Programmierer das Problem nicht vollständig verstehen und im
> > Zweifelsfall den einfachen Weg wählen.
> Ah, alles klar. Wenn Programmierer anstatt einen neuen, fehlerhaften
> Parsers für ihr einfaches, aber unklar spezifiziertes Format zu
> schreiben einfach zu einer Bibliothek mit einem gut getesteten Parser
> für ein bekanntes, gut-verstandenes Format greifen, dann hast du weniger
> Aufträge zur Fehlersuche.
Bin ich hier nur von Torfköppen umgeben?
Keinen Plan aber nicht nur dumm rumlabern sondern mir persönliche Motive
unterstellen? Moment, ich grab mal einen besonders tiefen Graben in
mein Killfile, damit du möglichst weit unten verschwindest. *plonk*
Marcus Hampel
Felix von Leitner wrote:
> Thus spake Marcus Hampel (marcus...@myview.de):
[...]>
> Was soll dieser wiederholte peinliche Versuch, die Newsgroup zu
> wechseln? Reicht es dir nicht, dich in dcoup zum Deppen zu machen, oder
> kennt man deine Fähigkeiten in dcoud schon und nimmt dich da eh nicht so
> ernst?
>
> Wenn ich das in dcoud hätte besprechen wollen, hätte ich es dort
> gepostet. Troll, elender!
Sorry, wenn ich noch ein paar alte Postingregeln im Usenet beherrsche:
Crossposting immer mit Followup-To in *eine* Gruppe. Da du aber
entscheidungsschwach bist, muss ich wohl oder übel die Entscheidung in
die eigene Hand nehmen. Für dummes gelaber (Diskussion) ist dcoud nun
mal besser geeignet als dcoup.
>>>> Eine Syntax provoziert Buffer Overflows. Ah, ja.
>>>
>>>Wenn du es nicht verstehst, wieso kommentierst du es dann?
>>
>>Buffer Overflows sind Probleme von veralteten Programmiersprachen und
>>kein Problem des XML-Syntax.
>
>
[... Jaja, Hiwi, Kaffeekocher, etc ...]
Schön, dass du nur persönliche Defermierungen 'drauf hast. Inhaltlich
wahr das ja schon mal eine NULL-Nummer.
>>>> Was soll denn die Länge sein?
>>>
>>>Platzbedarf.
>>
>>Das braucht man nur bei untauglichen Programmiersprachen.
>
>
> Ah, Platz brauchen nur untaugliche Programmiersprachen.
[...]
Nein, aber sie berechnen den Speicherbedarf selbstständig und beseitigen
damit auch die Bufferoverflows.
> Mann, du bist ja so eine Lachnummer, da gibt es echt keine Worte mehr für.
Tja, du scheinst keine andere Programmiersprache als C oder Assembler zu
kennen. Würde ich eher als Bildungslücke bezeichnen.
>>Der Platzbedarf ist redundant.
>
> EBEN. Das ist genau die Beschwerde. XML ist in unglaublichem Maße
> redundant, aber nicht so, daß man damit Fehlerkorrektur oder auch nur
> -Erkennung betreiben könnte.
Es hindert dich keiner die Länge als Attribut in den Tag zu schreiben.
>>Ein Text brauch genau so viel Platz, wie er lang ist.
>
> Plus Markup, ja.
>
> Oder willst du sagen, daß du einen strukturierten Datenstrom mit 10k
> Nutzdaten verteilt auf 100 Records mit je 7 Feldern mit (oder ohne) XML
> und ohne Kompression der Nutzdaten in 10k abbilden kannst? Das will ich
> sehen. Das ist geradezu nobelpreisverdächtig! Das schafft nicht mal
> ASN.1 oder CSV!
Das hat doch überhaupt keiner behauptet. Oder? Lesen bildet.
>>>> Die Interpretation der Daten geht xml nicht an. Und ob es eine
>>>> clevere Idee ist sich auf Längenangaben in einer Datei die
>>>> sonstwoher kommen kann zu verlassen ? Nicht wirklich.
>>>
>>>Wenn du es nicht verstehst, wieso kommentierst du es dann?
>>
>>Bullshit. Die Frage wurde nicht beantwortet. Sich auf die Längenangeben
>>von externen Daten zu verlassen ist unsinnig.
>
> Man sieht, daß du noch nie einen Parser geschrieben hast.
> Du betreibst hier gerade das Usenet-Äquivalent vom sich öffentlich in
> die Hose pinkeln.
>
> Man liest die Länge, alloziert so viel Speicher,
... und das braucht kein Mensch mehr, weil Programme heute eher in C++
und Java geschrieben werden ...
> und wenn dann mehr
> kommt, bricht man komplett ab. Das ist schon mal einfach so eine
> Größenordnung effizienter als typische realloc-Implementationen.
Toll. Das kostet aber an anderer Stelle einen größeren Aufwand, der sich
aufgrund von schnelleren Rechnern und mehr Hauptspeicher nicht rechnet.
>>Damit ist die Längenangabe unsinnig.
>
> Du bist ein Knallkopf sondergleichen.
Du scheintst eine gewisse Entwicklung in der EDV nicht mitbekommen zu haben.
>>>>>b) XML ist nicht hinreichend.
>>>>
>>>> ...für was?
>>>
>>>Für die in der Rationale dargelegten Anwendungsgebiete.
>>
>>Bullshit. Das wird man ja wohl begründen müssen.
>
>
> Die Rationale IST die Begründung! Gibt es eigentlich _irgendein_
> Detail dieser Diskussion, mit dem du dich auch nur in Ansätzen
> vertraut bist? Das ist ja wirklich grotesk, was du hier bietest.
Grotesk nenne ich eher deine NULL-Aussagen. Deine Behauptungen wirst du
ja wohl etwas genauer begründen können, oder?
>>>> Tja, für jede Aufgabenstellung das geeignete Werkzeug. Man wird
>>>> seltenst alle auf einmal brauchen.
>>>
>>>Genau genommen braucht überhaupt keines davon.
>>
>>Bullshit. Das wird man ja wohl begrunden müssen.
> Zeige ein einziges Problem, das man nur mit XML oder nur mit XSLT lösen
> kann, und das nicht "Kompatibilität mit XML" oder "Kompatibilität mit
> XSTL" heißt oder beinhaltet
>
> Gibt es nicht? Genau meine Rede.
Da kommt dann schon etwas mehr. Das ist dann aber tatsächlich etwas
"Grotesk". Mit der Argumentation sind wird bald wieder in der
EDV-Steinzeit bei den Lochkarten ...
>>>>>c) XML ist nur eine Syntax. Semantische Validierung ist untrivial und
>>>>> sehr fummelig.
>>>>
>>>> Was willst Du uns mit diesen Allgemeinplätzen sagen?
>>>
>>>Sag bloß, ASN.1 kennst du also auch nicht?
>>>Deine Inkompetenz ist in der Tat beeindruckend, nur wieso lebst du sie
>>>nicht woanders aus? dag° bietet sich geradezu an für Experten deines
>>>Kalibers.
>>
>>Sorry, du erzählst hier nur Unsinn und versuchst andere Leute persönlich
>>zu beleidigen.
>
>
> Soso, ich erzähle also Unsinn. Gut, daß du dem ASN.1-Dingens komplett
> ausgewichen bist, sonst wäre das Ausmaß deiner Pfuscherei offenbar
> geworden.
>
> Vielleicht willst du jetzt kurz dazu Stellung nehmen?
> Tu es für die zukünftigen Generationen, denn die aktuellen haben dich
> schon alle im Killfile.
Damit sind die Allgemeinplätze immer noch offen. Vielleicht füllst du ja
lieber dein Killfile ...
>>Es ist egal, ob das interpretieren der Semantik aufwendig ist, oder
>>nicht.
>
> Ein Satz, zwei Grammatikfehler. Beeindruckend. Und du willst uns hier
> was von Semantik erzählen?
Toll, wenn du nie einen Fehler übersiehst. Nur an der Interpretation von
Sätzen muss du noch etwas arbeiten ...
>>Die Syntaxanalyse fällt weg und es ist somit einfacher die Daten
>>zu analysieren.
>
>
> Aha. Soso, die Syntaxanalyse fällt also weg.
>
> Brilliant! Du hast einen XML-Parser ohne Parser (Parsen ist ein Synonym
> für Syntaxanalyse) geschrieben! Das ist eine bahnbrechende
> Errungenschaft! Hast du das irgendwo publiziert, damit wir das
> entsprechend würdigen können?
>
> Hast du dich mal in einer ruhigen Minute gefragt, wieso man von
> XML-Parsern spricht, wenn XML deiner Meinung nach das Parsen eliminiert?
Du bist ein echter Meister darin, eine Missinterpretation von Sätze mit
riesigen Antworten zu formulieren. Du solltest vielleicht mal versuchen
die tatsächlich relevanten Dinge genauer zu betrachten.
Relevant ist nämlich nur, dass *ich* den Parser nicht schreiben muss,
wenn ich XML verwenden will.
>>Weniger Arbeit ist weniger Arbeit.
>
> Diese profunden Weisheiten aus dem Fundus deiner Lebensweisheit sind es,
> die deine Postings so wertvoll machen.
Genau.
>>Wie aufwendig eine Semantik ist, kann man außerdem eh nicht allgemein
>>beantworten.
>
>
> Semantik? Aufwändig? Warum greifst du dir nicht mal ein Lexikon oder
> ein Informatikbuch und informierst dich über die Bedeutung der Worte,
> mit denen du hier um dich wirfst?
>
> Semantik ist die Bedeutung von Symbolen oder die Beziehung der
> Bedeutungen von Symbolen.
>
> Mit Aufwand hat das genau nichts zu tun. Ich habe ja schon eine Menge
> Leute dabei beobachten dürfen, wie sie sich komplett lächerlich machen,
> aber deine Effizienz darin ist beeindruckend.
Siehst du. Wenn du nur 3 mm nachgedacht hättest, dann hättest du darauf
kommen können, dass es mir um den Aufwand der Implementierung zum
Auswerten der Semantik ging.
>>>> Niemand zwingt dich XSLT zu nutzen. Es hat seine Anwendungsbereiche,
>>>> und wenn es nicht passt gibt es reichlich Alternativen.
>>>
>>>Mir ist noch kein keiner begegnet.
>>
>>XSLT funktioniert nach meinen Erfahrungen ganz hervorragend. Sowohl für
>>die Konvertierung von Daten, als auch für das Erstellen von Layouts.
>
>
> Ah, die Konvertierung von Daten also. Ich mail dir mal ein PDF, das
> konvertierst du dann mit XSLT in eine Word-Datei.
Tja, PDF-Software ist halt noch nicht XML-Fähig. Word-Datei in PDF ist
da schon wahrscheinlicher, scheitert aber an den schlechten
XML-Fähigkeiten von Word. Aber in ein paar Jahren ...
>>Nun ja, wenn man jemanden mutwillig fehlinterpretierten will. Platz ist
>>heute genug vorhanden.
>
> Nein.
Doch (ist ja 'ne spannende Diskussion)!
>>Man kann nicht um jedes Byte jammern, was man weniger produzieren
>>könnte.
>
> Aha, wie Computer funktionieren, was eine Speicherhierarchie ist, was
> Caches sind, das weißt du auch alles nicht, ja?
>
> Du bist ja wirklich außerordentlich wohlqualifiziert, um dich hier über
> Programmier-Fragen zu äußern.
Also: Doch über die Bytes jammern. Nun ja, die werden ja auch täglich
teurer. Vielleicht solltest du dich beim WDR-Computer-Club melden (immer
ein Bit übrig behalten und so ...)
>>Die ganzen Internet-Protokolle auf der Anwendungsebene (ftp, smtp) und
>>Dateiformate (Mail, News, HTML) sind alle keine Meister des
>>Platzsparens.
> FTP und SMTP sind sehr platzsparend. Mail und News sind nicht toll,
> aber auch nicht auffallend schlecht, im krassen Gegensatz zu HTML.
> HTML kommt ja auch von den gleichen Versagern, den wir SGML und XML zu
> verdanken haben, das verwundert also nicht weiter.
Natürlich sind die Platzsparender als HTML. Die sind ja auch erheblich
älter! Vor nur 5 Jahren hat es noch Diskussionen gegeben, ob denn alle
Header-Felder wirklich notwendig sind. Und sicherlich findet man heute
immer noch Leute die da Probleme sehen.
Auch FTP und SMTP könnte man noch kürzen. Wozu da lange Labertexte
hinter den Meldungen? Die Zahlen sagen doch alles aus. Und wenn die
Ausgabe nicht in ASCII gestaltet währe, dann würde das alles noch
weniger Bytes kosten.
Aber da haben alle (mit Recht) 'drauf geschissen. Bei XML wird das genau
so sein.
>>Das hat auch seinen Grund. Es geht darum die Daten möglichst lesbar zu
>>gestalten um sie einfacher handhaben zu können.
>
> Aha, HTML ist also besonders gut lesbar. Klar, das erklärt sofort den
> Markt an HTML-Editoren und die vielen kaputten HTML-Parser.
Das ist ein Argument. Also, ich komme mit einem normalen Editor klar.
Dass es mit einer Syntaxunterstützung u.U. noch etwas besser geht, hat
niemand bestritten. Dadurch ist XML aber immer noch lange nicht schlecht
zu lesen.
Zu den "kaputten" HTML-Parsern: Das liegt einzig und allein an den
Browsern, die Fehler in HTML-Dateien nicht frühzeitig abgelehnt haben.
Dadurch ist kaputtes HTML gesellschaftsfähig geworden. Das ist aber
schon mit dem Mosaic verbockt worden. Diese Fehlentwicklung hat die
Parserbauer für HTML dazu bewegt nach dem GIGO-Prinzip zu arbeiten (GIGO
= garbage in, garbage out).
XML ist aber kein HTML! HTML ist nicht einmal XML!
> Und Buffer Overflows hat es in den diversen HTML- und HTTP- ja auch noch
> nie gegeben, wie? Du willst mir hier nicht ernsthaft gerade sagen, daß
> XML nicht so schlimm ist, weil HTML auch scheiße ist, oder?
Bufferoverflows existieren überhaupt erst, weil einige Programmierer das
nicht gebacken bekommen. Dem kann man nur mit neuen Programmierern
(Genforschung?) oder neuen Programmiersprachen begegnen.
>>Einen gesonderten Layer für die Komprimierung von Daten halte ich auch
>>für unsinnig. Komprimierung ist mittlerweile ein so weitreichendes
>>Thema, dass sie direkt in die Betriebssysteme als zentraler Service
>>eingebaut werden müsste.
>
>
> ROTFL
>
> Klar, sollen die ruhig alle rumbloaten, das System wird's schon richten.
Oder neue Hardware. Das ist alles besser, als das 1000'te Dateiformat
oder plattgeklopfte komplexe Strukturen.
>>Ansonsten werden die Platten halt grösser.
>
> Dem ist nichts hinzuzufügen.
Genau.
[...]
>>Verkürzen wir den Satz auf "Ich habe genau keinerlei Interesse daran
>>[...] zu interagieren.".
>
> Oh, ich interagiere mit allen möglichen Protokollen und Programmen.
> Nur mit Heiße-Luft-Appareten wie z.B. deiner Wenigkeit muß ich nichts
> austauschen
Deine Argumente werden immer besser ...
>>>Im Übrigen, warum setzt du nicht Windoze ein, das ist noch viel
>>>verbreiteter als Unix!
>>
>>Im Übrigen, warum setzt du nicht 'nen Amiga ein, da waren damals auch
>>immer genug Leute, die sich gegen alles eingesetzt haben, nur weil es
>>auch unter Windows funktionierte.
>
>
> Du bist ja so derartig stoned, du merkst nicht mal, wenn man deine
> Äußerungen persifliert! Unglaublich.
Hast du vielleicht die Personen durcheinander geworfen? Oder machst du
jetzt Zeitreisen. Ich mein nur so, wenn du mich schon persiflierst,
bevor ich überhaupt etwas zum Thema geschrieben habe :-))
Ich glaube, dir fehlt etwas der Durchblick.
>
> Merkbefreiung jetzt!
>
Genau!
Bis denne ...
Marcus
Marcus Hampel
Stefan Nobis wrote:
> Marcus Hampel <marcus...@myview.de> writes:
>
>
>>Buffer Overflows sind Probleme von veralteten Programmiersprachen und kein
>>Problem des XML-Syntax.
>
>
> Das ist ja nun schon eine gewagte These. Ich würde da schon fast eher
> zu "Buffer Overflows sind Probleme von unfähigen Programmierern"
> tendieren.
Dazu hab ich in einem anderen Artikel geschrieben. Kurz: Wenn der Berg
halt nicht zum Propheten will ... oder so.
> Aber gleich kommst du bestimmt mit so genialen Sprache wie Java oder
> C#, die voll ultra cool sind -- und die dafür sorgen, dass auch ein
> 2GHz Pentium mit 4GB RAM irgendwann selbst für Textverarbeitung viel
> zu klein dimensioniert ist.
Du schreibst also in Assembler. Ich dachte immer, die ganzen coolen
Leute schreiben (proggen) Assembler-Demos für den Amiga, dass es nur so
funzt :-)
Scherz beiseite: Die Programme werden immer aufwendiger und die
Programmierer nicht klüger. Also müssen die Programmiersprachen diese
Schere wieder einfangen. Anders kann das nicht funktionieren.
Deshalb ist man ja schon von Assembler auf C umgestiegen. Heute steigt
man halt von C auf Java um (C# eher von Turbo-Pascale). C++ ist leider
wegen totaler Überfrachtung des Sprachkonzeptes und schlechter
STL-Klassen gescheitert.
>>Bullshit. Die Frage wurde nicht beantwortet. Sich auf die
>>Längenangeben von externen Daten zu verlassen ist unsinnig. Damit
>>ist die Längenangabe unsinnig.
>
>
> Schon aus Redundanzgründen ist dein Bullshit ziemlich dämlich. Je mehr
> Redundanz, desto leichter fallen i.d.R. z.B. auch
> Plausibilitätsprüfungen. Von Fehlererkennung/-korrektur mal zu
> schweigen.
Für eine Fehlerkorrektur, ok, hindert dich ja keiner 'dran in einen Tag
die Längenangabe anzugeben. Aber sich darauf verlassen, um dann Puffer
zu reservieren, die eh überflüssig sind?
>>>>> c) XML ist nur eine Syntax. Semantische Validierung ist untrivial und
>>>>> sehr fummelig.
>>>>
>>>> Was willst Du uns mit diesen Allgemeinplätzen sagen?
>>>
>>>Sag bloß, ASN.1 kennst du also auch nicht?
>>
>
>>Es ist egal, ob das interpretieren der Semantik aufwendig ist, oder
>>nicht. Die Syntaxanalyse fällt weg und es ist somit einfacher die
>>Daten zu analysieren. Weniger Arbeit ist weniger Arbeit.
>
>
> OK. Du packst in dein Programm eine Megalibrary, die ohne Ende RAM und
> Rechenpower frisst, um ein extrem aufgeblähtes Dateiformat zu
> parsen. Und dann findest du das auch noch obercool.
Na, so viel ist es ja nun auch nicht. Rechne das mal in Euro um. Das
sind Pfennigsbeträge. Kein Kunde hat sich bis jetzt über die
Speicheranforderungen beschwert. Das ist meist Kleingeld gegenüber der
Programmierung, die notwendig ist, selber zu parsen oder ein Eigenformat
zu verwenden.
[...]
> Nicht zu vergessen, dass du das eigentlich Kernargument (Problem
> Validierung) offensichtlich gar nicht verstanden hast. Ein
> validierender XML-Parser ist nicht nur riesengroß, der ist auch noch
> so komplex, dass der extrem Fehleranfällig ist. Und schon ist der
> große Vorteil (tolle Lib, leicht zu benutzen) gleich wieder im Arsch.
Also gravierende Fehler hab ich z.B. bei Xerxes noch nicht entdeckt.
Ansonsten werden die halt irgendwann ausgemerzt sein. Mit dem gleichen
Argument könnte ich mich auch gegen ein UNIX wehren. Ein DOS passt in
gerade mal 100k (geschätzt). Das ist viel Kleiner, weniger komplex und
damit auch Fehleruranfälliger. Warum also ein UNIX?
>>Wie aufwendig eine Semantik ist, kann man außerdem eh nicht
>>allgemein beantworten.
>
> Die Semantik von XML-Dateien, die der Parser validieren soll, ist aber
> beurteilbar: Die ist recht komplex. Das führt überproportional schnell
> zu Fehlern.
Ich bin erst mal von der Semantik der Daten ausgegangen. Die Semantik in
XML kann ich nicht so recht sehen. Ich sehe da eher einen Syntax.
>>Nun ja, wenn man jemanden mutwillig fehlinterpretierten will. Platz
>>ist heute genug vorhanden. Man kann nicht um jedes Byte jammern, was
>>man weniger produzieren könnte.
>
> Ja, diese saublöden Sprüche kenne ich. Hast du schon mal an die Firma
> gedacht, die ihre Hardware nur alle 5-10 Jahre *teilweise*
> erneuert.
Selbst das Finanzamt schreibt einen Rechner nach 4 Jahren ab. Und wenn
es um Geld geht, dann sind die recht kleinkariert. Nach 4 Jahren hat ein
Rechner nur noch Schrottwert. Bei mir in der Firma werden Rechner 3
Jahre von den Mitarbeitern genutzt (nicht nur die Programmierer). Danach
wandert der Rechner in den Studentenpool oder wird zur Austauschmasse.
Danach sind die Teile meist eh hinüber (Hardwaredefekte) und kaum noch
zu gebrauchen.
> Da steht dann plötzlich kein 2GH Pentium, 4GB RAM mit 2 TB
> RAID-Array, da gibt's dann plötzlich nur ein Pentium-100, 64MB RAM und
> die Platte hat auch nur noch 20MB frei. Und mit diesen Eckwerten kann
> ein guter Programmierer wirklich sehr, sehr viel machen.
Natürlich kann man damit etwas machen. Aber eben halt keine moderne
Anwendungen. In meiner Freizeit hab ich auch immer gerne mit total
unterdimensionierten Rechnern gearbeitet (Minix auf 10 Jahre altem XT).
Aber für eine Firma, die Geld verdienen möchte, ist ein alter Rechner zu
teuer. Dort muss halt zu viel Entwicklungsarbeit in Detailfragen
stecken, die heute einfach überflüssig sind. Ein Tag Entwicklung kostet
ca. 1000 Euro. Da hast du schnell das Geld für einen neuen Rechner
'raus. Von den Reparaturkosten und Folgekosten wegen Ausfällen ganz zu
schweigen.
> Hey, i.d.R. soll deine Software nicht auf einem eigenen,
> hochgerüsteten Rechner laufen -- da soll auch andere Software
> laufen. Wenn jeder so denken würde wie du, gäbe es heute ganz sicher
> kein Internet.
Wie? Ich kenn noch die Zeiten, als TCP/IP in Liunx eingebaut wurde und
die Leute gestöhnt haben, dass der 4MB-Rechner nicht mehr so schnell
war. Die ganze GNU-Software galt früher mal als reine Speicherfresser
(EMACS = Eight Megabytes And Constantly Swapping). Die bash war größer
als MGR (Grafische Fensteroberfläche). Da lachen wir doch heute 'drüber.
>>Die ganzen Internet-Protokolle auf der Anwendungsebene (ftp, smtp)
>>und Dateiformate (Mail, News, HTML) sind alle keine Meister des
>>Platzsparens. Das hat auch seinen Grund. Es geht darum die Daten
>>möglichst lesbar zu gestalten um sie einfacher handhaben zu können.
>
> Oh, nicht einmal das hast du verstanden. Ein gutes Protokoll zu
> designen ist wirklich nicht gerade leicht, aber ich dachte nicht, dass
> es so schwer ist, die Ideen anderer, ausführlich kommentiert, zu
> verstehen. Hast du auch schon mal in einen RFC geschaut? Auch schon
> mal versucht zu verstehen, was da so geschrieben steht?
Mir scheint, dass *du* da was nicht verstanden hast. Ich kann mich noch
immer an das gezeterte Erinnern, als einige Leute sich über die ellen
langen Header in Mail und News aufgeregt haben. Dabei hätte man doch
alles so schön kompakt in kryptischen binäre Datenströme packen können.
Und wie viel es kostet, die ganzen Header auch noch durch komplizierte
Parser zu schicken ... und was das an Rechenzeit kostet ...
Aber genau das hat man nicht gemacht, weil es besser ist, wenn man die
Protokolle und Daten im Zweifelsfall auch per Hand bedienen/bearbeiten
kann.
Heute lachen wir 'drüber, so wie wir später über die ganze
XML-Diskussion lachen werden.
>>Einen gesonderten Layer für die Komprimierung von Daten halte ich
>>auch für unsinnig. Komprimierung ist mittlerweile ein so
>>weitreichendes Thema, dass sie direkt in die Betriebssysteme als
>>zentraler Service eingebaut werden müsste. Ansonsten werden die
>>Platten halt grösser.
>
>
> Was bitte stammelst du da? "Komprimierung... ein so weitreichendes
> Thema"? Sag mal, bist du irgendwie auf Drogen oder sowas? Was ist da
> weitreichend?
Wird praktisch überall verwendet.
> Wieso gehört das ins Betriebssystem (OK, Kompression
> on-the-fly auf Dateisystemebne ist ganz nett, aber das können doch eh
> schon so ziemlich alle Systeme)?
Genau. Nur dass es noch nicht alle Dateisysteme unterstützen. Aber auch
noch an anderen Stellen ist es schon stellenweise Vorhanden: Netzwerk
(PPP) oder Grafik (Komprimierung von Texturen). Das muss nur noch etwas
ausgeweitet werden. Damit hat sich die Größe von XML-Dateien dann eh ins
Nirwana verflüchtigt.
>>Dann kann ich auch verstehen, warum XML nix für dich ist. XML
>>braucht man, damit alle sich untereinander verstehen. Ungeachtet
>
> Prust! Du meinst auch, problemlosen Datenaustausch zwischen den
> unterschiedlichsten Systemen gibt es erst seit XML, wie?
Nein. Aber nicht in der Komplexität der Daten. Die Anwendungen werden
komplexer und somit auch die Daten, die ausgetauscht werden müssen. Da
kommt man CSV nicht mehr ohne grosse Hirnwicherei hin.
[...]
> XML ist im Großen und Ganzen so ziemlich das dämlichste, was gerade so
> an Hype durch die IT-Landschaft tigert. Es gibt ein paar wenige,
> begrenzte Bereiche, in denen es Sinn macht. Aber der Hype und dieses
> "XML für alles" ist einfach nur schwachsinnig.
Nein. TCP/IP für alles ist genau so hirnrissig. Trotzdem wird das
überall versucht. Der Grund ist ganz einfach: Je mehr
Formate/Protokolle, desto mehr Aufwand für die Implementierung. Es gibt
nichts teureres als die Personalkosten eines Programmierers (besonders,
wenn er auch noch gut sein soll).
> Konfigurationsdateien in XML -- das ist grober Unfug, das gehört
> eigentlich schon mit Berufsverbot bestraft. Von dem ganzen anderen
> Müll, der da so getrieben wird, mal zu schweigen.
Auch hier ist es eine reine Kostenfrage. Was kostet es mich einen Parser
für eine Konfigurationsdatei zu schreiben.
Wir stellen uns vor, wir müssten in einem UNIX alle Konfigurationen
Maschinell bearbeitet. Preisfragen: Wie viel Parser müssen wird dafür
schreiben um all die Konfigurationen zu lesen? Wie Fehleranfällig ist
das? Wie oft müssen die Parser angepasst werden, weil die
Konfigurationen komplexer wurden?
Da muss man mal die Folgekosten abschätzen. Den XML-Hype gibt es nicht
ohne Grund: Die Leute kennen die Kosten für das Datenchaos. Da kann eine
Datenübernahme mal eben 100.000 Euro kosten. Und wenn die Kosten durch
XML auf nur 80.000 Euro gesenkt werden, dann hat sich eine schnelle CPU
und mehr Hauptspeicher schnell gerechnet.
Sicher: Für den Heim-PC im Studentenwohnheim rechnet sich das nicht. Das
kostet dann halt der Programmierer (der nicht schlecht sein muss) halt
0.00 Euro.
Bis denne ...
Marcus
Lukas Geyer
> Scherz beiseite: Die Programme werden immer aufwendiger und die
> Programmierer nicht klüger. Also müssen die Programmiersprachen diese
> Schere wieder einfangen. Anders kann das nicht funktionieren.
Naja, die Intelligenz einer Programmiersprache ist sehr beschraenkt,
und die Frage, welche Programmiersprache man benutzt, ist lange nicht
so wichtig, wie Du hier behauptest. Ein entscheidender Fortschritt
ist, wenn man beim Programmieren von groesseren Projekten einmal
anerkennt, dass es um "Software Engineering" geht, und dass man
einiges von den Ingenieuren lernen kann in Bezug auf Methodik. Und
genau das wird vor allem bei sicherheitsrelevanter Software auch
angewandt und hat wahrscheinlich dazu gefuehrt, dass wir nicht
staendig unabsichtliche Atomkriege und Flugzeugabstuerze sehen.
> Deshalb ist man ja schon von Assembler auf C umgestiegen. Heute steigt
> man halt von C auf Java um (C# eher von Turbo-Pascale). C++ ist leider
> wegen totaler Überfrachtung des Sprachkonzeptes und schlechter
> STL-Klassen gescheitert.
Turbo-Pascale? OK, lassen wir das mit der Orthographie, aber auch die
inhaltliche Seite Deiner Aussage hier wuerde ich sehr stark
anzweifeln, kannst Du das bitte mal belegen? Mir fallen gerade jede
Menge groessere Projekte ein, die in C und C++ programmiert sind:
Apache, Darwin, Linux, MacOS X (Aqua oder Jaguar oder wie das heute
heisst), Windows (da das ja noch nie in Turbo-Pascal geschrieben war,
werden sie sicher auch nicht auf C# umsteigen...), OpenOffice
resp. StarOffice, naja, es gibt noch viel mehr. Meinst Du, die
schreiben das jetzt alles neu in Java und C#? Da setze ich einen
Kasten Bier dagegen, meinetwegen gucken wir in 10 Jahren nochmal.
> >>Es ist egal, ob das interpretieren der Semantik aufwendig ist, oder
> >>nicht. Die Syntaxanalyse fällt weg und es ist somit einfacher die
> >>Daten zu analysieren. Weniger Arbeit ist weniger Arbeit.
> > OK. Du packst in dein Programm eine Megalibrary, die ohne Ende RAM und
>
> > Rechenpower frisst, um ein extrem aufgeblähtes Dateiformat zu
> > parsen. Und dann findest du das auch noch obercool.
>
> Na, so viel ist es ja nun auch nicht. Rechne das mal in Euro um. Das
> sind Pfennigsbeträge. Kein Kunde hat sich bis jetzt über die
> Speicheranforderungen beschwert. Das ist meist Kleingeld gegenüber der
> Programmierung, die notwendig ist, selber zu parsen oder ein
> Eigenformat zu verwenden.
Naja, angeblich beschweren sich Kunden auch bei Microsoft nicht ueber
Bloat und Bugs, sondern wollen nur neue Features. Es faellt mir schwer
zu glauben, aber wenn das wahr waere, sind halt die meisten Kunden
schlechte Software gewohnt und nehmen es als gegeben hin, dass man mit
Unstabilitaet und unglaublichen Hardwareanforderungen leben muss, das
ist an sich schon traurig genug. Und wie man Bloat in Euros umrechnet,
habe ich leider nie gelernt.
> > Nicht zu vergessen, dass du das eigentlich Kernargument (Problem
> > Validierung) offensichtlich gar nicht verstanden hast. Ein
> > validierender XML-Parser ist nicht nur riesengroß, der ist auch noch
> > so komplex, dass der extrem Fehleranfällig ist. Und schon ist der
> > große Vorteil (tolle Lib, leicht zu benutzen) gleich wieder im Arsch.
>
> Also gravierende Fehler hab ich z.B. bei Xerxes noch nicht
> entdeckt. Ansonsten werden die halt irgendwann ausgemerzt sein. Mit
> dem gleichen Argument könnte ich mich auch gegen ein UNIX wehren. Ein
> DOS passt in gerade mal 100k (geschätzt). Das ist viel Kleiner,
> weniger komplex und damit auch Fehleruranfälliger. Warum also ein UNIX?
Es gibt auch so Mini-Unix-Varianten, die koennen dann halt auch nicht
viel. Es geht doch eher darum, ob man fuer den ganzen Aufwand auch
entsprechenden Gegenwert bekommt, und in vielen Faellen ist sicher
eine einfache Konfigurationsdatei, meinetwegen Apache-Format oder was
auch immer, einfacher.
> >>Nun ja, wenn man jemanden mutwillig fehlinterpretierten will. Platz
> >>ist heute genug vorhanden. Man kann nicht um jedes Byte jammern, was
> >>man weniger produzieren könnte.
> > Ja, diese saublöden Sprüche kenne ich. Hast du schon mal an die Firma
>
> > gedacht, die ihre Hardware nur alle 5-10 Jahre *teilweise*
> > erneuert.
>
> Selbst das Finanzamt schreibt einen Rechner nach 4 Jahren ab. Und wenn
> es um Geld geht, dann sind die recht kleinkariert. Nach 4 Jahren hat
> ein Rechner nur noch Schrottwert. Bei mir in der Firma werden Rechner
> 3 Jahre von den Mitarbeitern genutzt (nicht nur die
> Programmierer). Danach wandert der Rechner in den Studentenpool oder
> wird zur Austauschmasse. Danach sind die Teile meist eh hinüber
> (Hardwaredefekte) und kaum noch zu gebrauchen.
Tja, schoen fuer Dich. Die Realitaet ist aber, dass oft noch so
Uralt-Rechner herumstehen, u.a. an Unis. Und wenn es nicht noetig ist,
braucht man diese armen Leute doch nicht unbedingt zu ignorieren,
oder? Ausserdem, was fuer Hardwaredefekte? Platten kann man immer
austauschen, neues RAM kriegt man oft auch noch fuer aeltere Kisten,
man muss ja nicht gleich alles wegschmeissen.
> > Da steht dann plötzlich kein 2GH Pentium, 4GB RAM mit 2 TB
> > RAID-Array, da gibt's dann plötzlich nur ein Pentium-100, 64MB RAM und
> > die Platte hat auch nur noch 20MB frei. Und mit diesen Eckwerten kann
> > ein guter Programmierer wirklich sehr, sehr viel machen.
>
> Natürlich kann man damit etwas machen. Aber eben halt keine moderne
> Anwendungen. In meiner Freizeit hab ich auch immer gerne mit total
> unterdimensionierten Rechnern gearbeitet (Minix auf 10 Jahre altem XT).
Naja, was heisst hier "modern"?
> Aber für eine Firma, die Geld verdienen möchte, ist ein alter Rechner
> zu teuer. Dort muss halt zu viel Entwicklungsarbeit in Detailfragen
> stecken, die heute einfach überflüssig sind. Ein Tag Entwicklung
> kostet ca. 1000 Euro. Da hast du schnell das Geld für einen neuen
> Rechner 'raus. Von den Reparaturkosten und Folgekosten wegen Ausfällen
> ganz zu schweigen.
Die Entwickler koennen ja sicher neue Superrechner benutzen, aber
warum muss man voraussetzen, dass auch jeder Benutzer solche Dinger
rumstehen hat? Das sind doch zwei verschiedene Sachen.
> > Hey, i.d.R. soll deine Software nicht auf einem eigenen,
> > hochgerüsteten Rechner laufen -- da soll auch andere Software
> > laufen. Wenn jeder so denken würde wie du, gäbe es heute ganz sicher
> > kein Internet.
>
> Wie? Ich kenn noch die Zeiten, als TCP/IP in Liunx eingebaut wurde und
> die Leute gestöhnt haben, dass der 4MB-Rechner nicht mehr so schnell
> war. Die ganze GNU-Software galt früher mal als reine Speicherfresser
> (EMACS = Eight Megabytes And Constantly Swapping). Die bash war größer
> als MGR (Grafische Fensteroberfläche). Da lachen wir doch heute
> 'drüber.
Nein, es gibt immer noch Leute, die lieber vi(m) als (X)emacs benutzen
und irgendwelche anderen Shells, weil ihnen die bash zu bloatig ist.
> >>Einen gesonderten Layer für die Komprimierung von Daten halte ich
> >>auch für unsinnig. Komprimierung ist mittlerweile ein so
> >>weitreichendes Thema, dass sie direkt in die Betriebssysteme als
> >>zentraler Service eingebaut werden müsste. Ansonsten werden die
> >>Platten halt grösser.
> > Was bitte stammelst du da? "Komprimierung... ein so weitreichendes
>
> > Thema"? Sag mal, bist du irgendwie auf Drogen oder sowas? Was ist da
> > weitreichend?
>
> Wird praktisch überall verwendet.
>
> > Wieso gehört das ins Betriebssystem (OK, Kompression
> > on-the-fly auf Dateisystemebne ist ganz nett, aber das können doch eh
> > schon so ziemlich alle Systeme)?
>
> Genau. Nur dass es noch nicht alle Dateisysteme unterstützen. Aber
> auch noch an anderen Stellen ist es schon stellenweise Vorhanden:
> Netzwerk (PPP) oder Grafik (Komprimierung von Texturen). Das muss nur
> noch etwas ausgeweitet werden. Damit hat sich die Größe von
> XML-Dateien dann eh ins Nirwana verflüchtigt.
Naja, das Problem ist damit von Speicher auf CPU-Last verlagert.
> > XML ist im Großen und Ganzen so ziemlich das dämlichste, was gerade so
> > an Hype durch die IT-Landschaft tigert. Es gibt ein paar wenige,
> > begrenzte Bereiche, in denen es Sinn macht. Aber der Hype und dieses
> > "XML für alles" ist einfach nur schwachsinnig.
>
> Nein. TCP/IP für alles ist genau so hirnrissig. Trotzdem wird das
> überall versucht. Der Grund ist ganz einfach: Je mehr
> Formate/Protokolle, desto mehr Aufwand für die Implementierung. Es
> gibt nichts teureres als die Personalkosten eines Programmierers
> (besonders, wenn er auch noch gut sein soll).
TCP/IP ist ein robustes Protokoll fuer unzuverlaessige Netze. Bei
Streaming wird doch normalerweise UDP benutzt, bei schnellen Clustern
wird eh wieder was anderes benutzt etc. Und fuer welche Anwendungen
moechtest Du gerne TCP/IP durch was bitte ersetzen?
Lukas
Gunnar Ritter
> Scherz beiseite: Die Programme werden immer aufwendiger und die
> Programmierer nicht klüger. Also müssen die Programmiersprachen diese
> Schere wieder einfangen. Anders kann das nicht funktionieren.
>
> Deshalb ist man ja schon von Assembler auf C umgestiegen. Heute steigt
> man halt von C auf Java um (C# eher von Turbo-Pascale).
Nicht in dieser Newsgroup.
> Die ganze GNU-Software galt früher mal als reine Speicherfresser
> (EMACS = Eight Megabytes And Constantly Swapping). Die bash war größer
> als MGR (Grafische Fensteroberfläche). Da lachen wir doch heute 'drüber.
Ich lache da nicht drüber. bash ist untragbar bloatig, langsam,
fehlerbehaftet und die proprietären Features des GNU-Toolchests
sind die Hauptursache dafür, daß Shell-Skripte immer schlechter
werden, weil die Leute nur noch nach Switches in der Dokumentation
suchen und nicht mehr selbst programmieren. In der Folge verstehen
sie nicht mal den Code, den sie gerade selbst geschrieben haben.
Genau wie bei Deinen «modernen» Programmiersprachen. Früher oder
später wird dieser Müllhaufen unter seinem eigenen Gewicht
zusammenbrechen.
> Da muss man mal die Folgekosten abschätzen. Den XML-Hype gibt es nicht
> ohne Grund: Die Leute kennen die Kosten für das Datenchaos. Da kann eine
> Datenübernahme mal eben 100.000 Euro kosten. Und wenn die Kosten durch
> XML auf nur 80.000 Euro gesenkt werden, dann hat sich eine schnelle CPU
> und mehr Hauptspeicher schnell gerechnet.
> Sicher: Für den Heim-PC im Studentenwohnheim rechnet sich das nicht. Das
> kostet dann halt der Programmierer (der nicht schlecht sein muss) halt
> 0.00 Euro.
Exakt, und genau deshalb produzieren diese Leute (und ihre
Gesinnungsgenossen) seit Jahren Software, die sich dann für
Firmen rechnet.
Viele gallische Dörfer haben mehr als ein Imperium überlebt,
indem sie es nach Kräften ignoriert haben.
Gunnar
King Leo - Martin Oberzalek
> Marcus Hampel <marcus...@myview.de> writes:
>> Deshalb ist man ja schon von Assembler auf C umgestiegen. Heute steigt
>> man halt von C auf Java um (C# eher von Turbo-Pascale). C++ ist leider
>> wegen totaler Überfrachtung des Sprachkonzeptes und schlechter
>> STL-Klassen gescheitert.
>
> Turbo-Pascale? OK, lassen wir das mit der Orthographie, aber auch die
> inhaltliche Seite Deiner Aussage hier wuerde ich sehr stark
> anzweifeln, kannst Du das bitte mal belegen? Mir fallen gerade jede
> Menge groessere Projekte ein, die in C und C++ programmiert sind:
> Apache, Darwin, Linux, MacOS X (Aqua oder Jaguar oder wie das heute
> heisst), Windows (da das ja noch nie in Turbo-Pascal geschrieben war,
> werden sie sicher auch nicht auf C# umsteigen...), OpenOffice
> resp. StarOffice, naja, es gibt noch viel mehr.
Alle Projekte die du da nennst sind viel zu alt. Als die entstanden gabs
kein Java, C++ war fern von Standards...
> Meinst Du, die
> schreiben das jetzt alles neu in Java und C#?
Nein, aber was ist mit neuen Projekten?
>> >>Es ist egal, ob das interpretieren der Semantik aufwendig ist, oder
>> >>nicht. Die Syntaxanalyse fällt weg und es ist somit einfacher die
>> >>Daten zu analysieren. Weniger Arbeit ist weniger Arbeit.
>> > OK. Du packst in dein Programm eine Megalibrary, die ohne Ende RAM und
>>
>> > Rechenpower frisst, um ein extrem aufgeblähtes Dateiformat zu
>> > parsen. Und dann findest du das auch noch obercool.
>>
>> Na, so viel ist es ja nun auch nicht. Rechne das mal in Euro um. Das
>> sind Pfennigsbeträge. Kein Kunde hat sich bis jetzt über die
>> Speicheranforderungen beschwert. Das ist meist Kleingeld gegenüber der
>> Programmierung, die notwendig ist, selber zu parsen oder ein
>> Eigenformat zu verwenden.
Dann stellt sich auch noch die Frage, was zb in PHP perfomanter,
speicherfressender ist: ein eigens entwickelter Parser, oder XML via
expact?
>> > Da steht dann plötzlich kein 2GH Pentium, 4GB RAM mit 2 TB
>> > RAID-Array, da gibt's dann plötzlich nur ein Pentium-100, 64MB RAM und
>> > die Platte hat auch nur noch 20MB frei. Und mit diesen Eckwerten kann
>> > ein guter Programmierer wirklich sehr, sehr viel machen.
Gut, und der Entwickler dreht dann immer wieder recht lang däumchen, weil
das Programm halt 10 Minuten compiliert, oder ähnliches :)
Gruß, Martin!
--
I have an appointement with the eternity and I don't want to be late.
(Star Trek 7)
Lukas Geyer
> Lukas Geyer wrote:
>
> > Marcus Hampel <marcus...@myview.de> writes:
>
> >> Deshalb ist man ja schon von Assembler auf C umgestiegen. Heute steigt
> >> man halt von C auf Java um (C# eher von Turbo-Pascale). C++ ist leider
> >> wegen totaler Überfrachtung des Sprachkonzeptes und schlechter
> >> STL-Klassen gescheitert.
> >
> > Turbo-Pascale? OK, lassen wir das mit der Orthographie, aber auch die
> > inhaltliche Seite Deiner Aussage hier wuerde ich sehr stark
> > anzweifeln, kannst Du das bitte mal belegen? Mir fallen gerade jede
> > Menge groessere Projekte ein, die in C und C++ programmiert sind:
> > Apache, Darwin, Linux, MacOS X (Aqua oder Jaguar oder wie das heute
> > heisst), Windows (da das ja noch nie in Turbo-Pascal geschrieben war,
> > werden sie sicher auch nicht auf C# umsteigen...), OpenOffice
> > resp. StarOffice, naja, es gibt noch viel mehr.
>
> Alle Projekte die du da nennst sind viel zu alt. Als die entstanden gabs
> kein Java, C++ war fern von Standards...
Naja, Mac OS X ist nicht so alt, ausserdem sind trotz des fehlenden
Standards sowohl Darwin, Mac OS X als auch Star/OpenOffice in C++
geschrieben. Neuere Projekte? So grosse fallen mir im Moment gar nicht
ein, aber der groesste Teil der neuen Projekte, die ich so fuer Linux
oder ueberhaupt als freie Software sehe, sind C und C++. Es gibt da
gegenueber Java naemlich auch noch den Vorteil, dass diese Sprachen
nicht so halb einer Firma gehoeren. C# scheint ja wenigstens ein
offener Standard zu werden, aber ohne .NET oder Mono ist das ja wohl
erstmal noch nicht richtig interessant. Und ich sehe trotz neuer
Projekte in C# und diesen neuen Modesprachen nicht, dass C++
gescheitert ist, im Gegenteil ist es wahnsinnig erfolgreich, obwohl es
anscheinend der Alptraum aller Informatiker ist. (Was zumindest eine
positive Seite von C++ ist...)
> > Meinst Du, die
> > schreiben das jetzt alles neu in Java und C#?
>
> Nein, aber was ist mit neuen Projekten?
Naja, so User-Interfaces und sowas in Java schreiben die Leute sogar
in der numerischen Mathematik, die eigentliche Arbeit wird aber oft
sogar noch von Fortran erledigt. :) Ein grosser Vorteil von C und C++
ist die grosse Menge an freien Bibliotheken, und die Verfuegbarkeit
von freien Compilern auf fast allen Plattformen, weshalb auch
weiterhin viel freie Software in C und C++ geschrieben sein wird.
Lukas
--
Forgive him, for he believes that the customs of his tribe are the laws
of nature!
-- G.B. Shaw
René Möhring
Felix von Leitner <usenet-...@fefe.de> wrote:
> > Womit würdest du Textmarkup betreiben wollen?
>
> TeX? Postscript? PDF? Roff? Es gibt dutzende Lösungen dafür.
> Das war wohl gar nichts.
Wobei PDF ja im Prinzip Postscript ohne Programmierelemte (Schleifen, if
usw.), also quasi ein elektronischer Ausdruck davon ist. Zumindest
verwenden beide denselben Unterbau.
René Möhring
Marcus Hampel <marcus...@myview.de> wrote:
> C++ ist leider wegen totaler Überfrachtung des Sprachkonzeptes und
> schlechter STL-Klassen gescheitert.
Davon hab ich aber noch gar ichts bemerkt. Nicht nur viel freie
Projekte, auch viele Firmen nutzen C++.
Die "Überfrachtung" kann auch Vorteile haben. Du kannst verschiedene
Programmierparadigmen nutzen (prozedural,objektorientiert, generativ).
Wenn dir das als zuviel erscheint kannst du den Teil den du meinst nicht
zu brauchen immer noch ignorieren.
Stefan Nobis
> Wenn man ein Buch produzieren will, will man kein generisches
> Markup. Wer gute Bücher herstellt weiß, daß ein Leser mit
> mehr als vier Schrifttypen überfordert ist. Es ist also gerade
Richtig. Im wesentlichen stimme ich dir auch zu. Vorteil hat aber das
generische/logische Markup, wenn man das Dokument mehrfach
konvertieren muss, also nicht nur gezielt für den Print-Bereich
produziert, sondern das Buch/Dokument auch anderweitig (elektronisch)
verarbeiten will/muss.
Und dass alle LaTeX Bücher, bei denen die Autoren großen Wert auf
logisches Markup legten, häßlich aussehen, kann ich so auch nicht
akzeptieren. Der Lamport und der LaTeX-Begleiter sehen schon ganz
ordentlich aus und dort wurde AFAIK schon Wert auf logisches Markup
gelegt (gleiches gilt z.B. auch für die Bücher/Scripte von Markus
Kohm, der auch recht viel Wert darauf legt).
> nötig, da ein visuelles Markup einzuführen. Deshalb macht man
> gute Bücher mit qualifizierten, bewährten Satzprogrammen und
Klar. Wenn der Print-Bereich (nahezu) alleiniges Ziel der
Buchproduktion ist, wäre SGML/XML auf jeden Fall mit Kanonen auf
Spatzen geschossen, da gebe ich dir uneingeschränkt recht.
> nicht mit XML. Die Aufgabe eines Setzers besteht gerade darin,
> eine überorganisierte generische Markup-Wichse in etwas Lesbares
> zu verwandeln. Ein Autor, der sich dieser Tatsache bewußt ist,
> kann das auch gleich selbst machen.
Der Vorteil hier wäre aber, dass mit gutem generischem Markup der
Autor nur sehr wenig Ahnung von Typographie haben muss und der Setzer
diese Markup-Wichse eben noch recht leicht (sprich größtenteils
automatisiert) in etwas Lesbares verwandeln kann.
> > Wo sind da die qualitativen Unterschiede zu SGML/XML?
>
> Wenn Du das nicht siehst, ist Dir echt nicht mehr zu helfen.
Natürlich sehe ich da weitgehende Unterschiede -- die Frage war wohl
schlecht formuliert. Mir ging es darum, dass Felix Kritik sich für
mich sehr grundlegend anhörte (nach dem Motte, Textmarkup ist per se
einfach nur Scheiße) und von diesem Standpunkt betrachtet, ist der
Unterschied zwischen SGML/XML, TeX und Co dann wirklich
nebensächlich.
Aber anscheinend habe ich Felix da auch falsch verstanden. Sorry für
das Missverständnis.
--
Stefan.
Marcus Hampel
Felix von Leitner wrote:
[...]
> Seit ich auf fefe.de den Webserver von .html auf .html.gz umgestellt
> habe, wenn der Browser das kann, hat sich mein gesamter
> Internet-Durchsatz halbiert, und da sind auch Emails und sonstiges
> Arbeiten auf dem Server drin. Und mein HTML ist bereits mehr als
> sparsam.
Sicher, dass kann nur am HTML liegen:
marcus.hampel@RIKER2:tmp>gzip -9 < message.txt > message.txt.gz
marcus.hampel@RIKER2:tmp>ls -al message.txt*
-rwxrwxrwx 1 root Kein 4574 Oct 4 03:41 message.txt
-rw-rw-rw- 1 marcus.h Kein 2336 Oct 4 03:42 message.txt.gz
marcus.hampel@RIKER2:tmp>
Das war jetzt allerdings deine Message, auf die ich hier Antworte. Nur
soviel zu deinen messerscharfen "Analysen". *Jede* Textdatei wird durch
gzip auf ca. 50% ihrer Größe verkleinert.
Bis denne ...
Marcus
PS. Fup, da immer noch in *zwei* Gruppen gepostet wird.
Stefan Nobis
> XML kann man -- auch ohne DTD -- auch in 2000 Jahren mit einer einfachen
> Frequenzanalyse verstehen. Ein einfaches, aber womöglich binäres
> Datenaustauschformat macht da schon eher Probleme.
Word-Format kann man auch heute und in 2000 Jahren noch lesen. Ja und?
Den Datenmüll mit Sinn zu füllen ist in beiden Fällen etwa gleich
schwer.
> Ah, alles klar. Wenn Programmierer anstatt einen neuen, fehlerhaften
> Parsers für ihr einfaches, aber unklar spezifiziertes Format zu
> schreiben einfach zu einer Bibliothek mit einem gut getesteten Parser
> für ein bekanntes, gut-verstandenes Format greifen, dann hast du weniger
> Aufträge zur Fehlersuche.
Das war doch gerade der Kernpunkt. Versucht du eigentlich auch
gelegentlich mal zu verstehen, was da so an Wörtern an deinen Augen
vorbeiflattert?
Die Hauptkritik an XML ist, dass es ein extrem aufgeblasenes, extrem
komplexes Format ist, für das es eben keine ausgereiften, fehlerlosen
Parser gibt.
Und der Umkehrschluss, auf XML zu verzichten, heißt doch nicht, dass
wieder jeder alles selber bastelt. Es gibt gute Alternativen zu XML
inkl. fertigem Code für die Parser.
Zudem sind viele einfache Formate (gerade für Konfigurationsdateien,
um die es ursprünglich mal ging) so simpel, dass man als einigermaßen
fähiger Programmierer das auch als Aufwärmübung ohne gravierende
Mängel/Bugs hinbekommen sollte. Mit XML ist das natürlich unmöglich,
vermutlich 99,999% aller Leute, die XML propagiert und intensiv
einsetzt, wäre schlicht nicht in der Lage, einen konformen XML-Parser
auch nur im Ansatz hinzubekommen. Daher sind die Leute, auf diese
aufgeblähten, durchaus fehlerhaften XML-Libs *angewiesen*, sie haben
gar keine echte Wahl (es im Notfall halt mal schnell selbst zu
implementieren).
Das ist das große Problem. Und aus diesen Gründen ist XML (zumindest
als Dateiformat für nahezu alles) einfach grauenvoller Unsinn (vom
Bloat mal ganz zu schweigen).
Ach ja, warum gibt es denn so wenig wirklich gute Tools für XML?
Vielleicht, weil XML so simpel ist?
> Klar, und mit allen dieser Lösungen ist man unabhängig vom
> Ausgabemedium, kann die Präsentation durch einfache Eingriffe (Suchen-
> und-Ersetzen im Editor zählt nicht, weil das nicht gleich formatierte
> Sachen unterscheiden kann, die man jetzt verschieden haben möchte)
> ändern, usw.?
Es gibt Einsatzgebiete, in denen SGML/XML Sinn macht -- aber XML als
das Universal-Dateiformat für alles, von Müll, den die
Textverarbeitung produziert, über Tabellen und Grafiken bis hin zu
Konfigurationsdateien, das ist einfach haarsträubender Unsinn. Wer
sowas propagiert ist auf Drogen oder hat keine Ahnung.
--
Stefan.
Stefan Nobis
[Neuere Programmiersprachen]
> Nein, aber sie berechnen den Speicherbedarf selbstständig und
> beseitigen damit auch die Bufferoverflows.
Solange du nicht mit C++ kommst (da gibt's auch reichlich Beispiele
mit Buffer-Overflows) und Java außen vor lässt (das ist einfach
grausam langsam -- passt aber gut zum XML-Bloat; ich stelle mir gerade
eine Textverarbeitung oder ein Textsatzsystem vor, dass in Java
geschrieben ist und XML als einziges Dateiformat verwendet -- da
dürfte dann auch ein Pentium 2GHz mit 4GB RAM völlig
unterdimensioniert sein; da wäre ja sogar Smalltalk aus
Performance-Sicht ein echtes Highlight).
> Tja, du scheinst keine andere Programmiersprache als C oder Assembler zu
> kennen. Würde ich eher als Bildungslücke bezeichnen.
Und du scheinst außer ein bischen oberflächliches C++ und Java keine
Ahnung von Programmierung, Compilern und Interpetern zu haben.
> ... und das braucht kein Mensch mehr, weil Programme heute eher in C++ und
> Java geschrieben werden ...
...was sich hier gerade bestätigt. Wenn man von leistungsfähigen,
flexiblen Sprachen sprechen will, die wirklich über C/C++ hinausgehen,
dann sollte schon mind. Haskell, Common Lisp/CLOS, OCaml und
dergleichen kommen. Aber C++ und Java, das ist ja nun wirklich
ärmlich (C++ ist schon recht alt und hat eine Menge größerer
Schwächen, lies mal dcl.iso-c++, und Java ist einfach grauenvoll --
kein richtiges OOP, völlig ärmlich an Ausdrucksmitteln, schränk
Programmierer noch mehr ein als Pascal etc pp).
> Toll. Das kostet aber an anderer Stelle einen größeren Aufwand, der sich
> aufgrund von schnelleren Rechnern und mehr Hauptspeicher nicht rechnet.
Ach ja, stimmt ja, es ist ja billiger wenn so mittelständiges
Unternehmen sich jedes Jahr neue Rechner zu legt, weil die
Programmierer alle unfähig sind.
Nehmen wir mal ein solches Unternehmen. Sagen wir 500 Mitarbeiter. Da
gibt's dann vielleicht 200 Computerarbeitsplätze über 5 Standorte
verteilt. Und die sollen sich alle 1-2 Jahre komplett neue Rechner
kaufen, nur weil du zu faul bist, mal effizient zu programmieren? Es
ist also billiger jedes Jahr rund eine halbe Million Euro rauszuwerfen
(bitte denke daran, dass es mit dem Kauf der Rechner alleine nicht
getan ist -- die müssen konfiguriert, katalogisiert und aufgestellt
werden)?
Da ist es doch billiger 2 fähige Entwickler anzustellen, die dann
effiziente Programme schreiben, so dass die Hardware auch in 5 Jahren
noch bequem ausreicht. (So kosten dann nämlich die Programmierer nur,
sagen wir mal, 200.000 EUR pro Jahr, dann muss noch Geld für neue
Rechner in 5 Jahren gespart werden, macht 100.000 EUR jährlich, und
schon hat die Firma 200.000 EUR pro Jahr gespart.)
Solche Idioten wie du sind der Ruin der deutschen Wirtschaft -- zum
Glück gibt es da aber noch die Kaufleute und Controller, die dir dann
schon vorrechen, wann das nächste Mal neue Rechner gekauft werden und
wie lange du mit den alten Mühlen zu arbeiten hast.
> Auch FTP und SMTP könnte man noch kürzen. Wozu da lange Labertexte
> hinter den Meldungen? Die Zahlen sagen doch alles aus. Und wenn die
> Ausgabe nicht in ASCII gestaltet währe, dann würde das alles noch
> weniger Bytes kosten.
Du hast es schlicht nicht verstanden. Du laberst rum. Bitte informiere
dich! Es gibt (ausführliche) Begründungen für die Protokolle, die
i.d.R. sogar wissenschaftlich belegt sind -- z.T. stehen die sogar in
den RFCs direkt drin.
Lesen bildet!
> Aber da haben alle (mit Recht) 'drauf geschissen. Bei XML wird das
> genau so sein.
Nein, da wird nicht "'drauf geschissen". Das ist haarsträubender
Schwachsinn. Du hast wirklich gar keine Ahnung!
Bitte informiere dich und phantasiere nicht so einen Unsinn
zusammen. Danke.
> Bufferoverflows existieren überhaupt erst, weil einige Programmierer
> das nicht gebacken bekommen.
Richtig.
> Dem kann man nur mit neuen Programmierern (Genforschung?) oder neuen
> Programmiersprachen begegnen.
Dazu benötigt man weder neue Programmiersprachen noch
Genforschung. Die Zauberformel heißt Ausbildung plus Haftung. Ganz
einfach.
Und das ist schon in Teilen vorhanden. Hast du dich in letzter Zeit
mal mit dem BGB beschäftigt, speziell dem Vertrag- und Haftungsrecht?
Ein freier Programmierer, der da Müll produziert, ist für seinen Müll
auch voll haftbar und kann für Schäden recht heftig zur Kasse gebeten
werden.
Mir geht da zwar einiges noch nicht weit genug (Sicherheitslücken und
sonstige Bugs sind da bei Schadensersatzansprüchen AFAIK noch der
Einzelfallwürdigung der Richter unterworfen, da müsste man mal härter
durchgreifen), aber es ist ein guter Anfang.
Ach ja, Gewährleistungsrecht gilt auch für Software.
> Oder neue Hardware. Das ist alles besser, als das 1000'te
> Dateiformat oder plattgeklopfte komplexe Strukturen.
Ah, danke. Du bist also doch gegen XML! Denn XML macht gerade komplexe
Strukturen kaputt. Glaubst du nicht? Dann informiere dich über
Datenbanken -- dort hatte man das Thema semistrukturierte Datenformate
(genau das ist XML) nämlich schon vor ca. 30-40 Jahren
durchgekaut. Das ist (außer in wenigen Sonderfällen) obsolet.
Und was bringt mir XML schon. Klasse, da habe benutzen jetzt alle
dieselbe Parser-Bibliothek. Die liefert mir ein DOM -- die eigentlich
Hauptarbeit bleibt dieselbe. Und wenn jemand ein proprietäres
Datenformat will, kriegt er das auch mit XML auf die Reihe, indem
wichtige Details schlicht nicht (öffentlich) dokumentiert werden.
Das Problem heutiger Datenformate ist nicht, dass sie nicht auf XML
beruhen -- Probleme entstehen eigentlich nur dadurch, dass einige
Hersteller ihre Formate geheim halten und Details dazu nicht
veröffentlichen. Und das wird sich auch mit XML nicht ändern, daher
ist XML schlicht obsolet (von einigen Spezialbereichen mal abgesehen).
Dateiformate sind nichts mystisches -- letztlich musst du dir darum
auch bei XML noch viele Gedanken machen. Du gewinnst mit XML als
Dateiformat schlicht gar nichts (mit XML als Textmarkup gewinnt man in
einigen Fällen etwas), erkaufst dir das aber mit einem gigantischen,
extrem fehleranfällig Overhead. Das ist das Problem.
XML hat in wenigen Bereichen seine Existenzberechtigung -- als
universelles Dateimetaformat taugt es überhaupt nicht!
--
Stefan.
Stefan Nobis
> > Aber gleich kommst du bestimmt mit so genialen Sprache wie Java oder
> > C#, die voll ultra cool sind -- und die dafür sorgen, dass auch ein
> > 2GHz Pentium mit 4GB RAM irgendwann selbst für Textverarbeitung viel
> > zu klein dimensioniert ist.
>
> Du schreibst also in Assembler. Ich dachte immer, die ganzen coolen Leute
> schreiben (proggen) Assembler-Demos für den Amiga, dass es nur so funzt :-)
Du laberst Stuss!
Was soll der Schwachsinn? Gehen dir die Argumente aus? Weißt du
letztlich gar nicht, wovon du sprichst?
Man kann in verschiedenen Sprachen, z.B. C, C++, Haskell, OCaml,
Common Lisp/CLOS etc. durchaus sowohl schnell entwickeln als auch sehr
effiziente Programme schreiben.
Mit Java ist das (i.a.) nicht möglich, mit C# sehr schwierig (und mit
C++ und einigen anderen der obigen Liste immer noch schwierig,
d.h. man muss die Sprache und ihre Eigenheiten schon gut kennen).
> Scherz beiseite: Die Programme werden immer aufwendiger und die
> Programmierer nicht klüger. Also müssen die Programmiersprachen
> diese Schere wieder einfangen. Anders kann das nicht funktionieren.
Schwachsinn! Man nehme eine fundierte Ausbildung und schon klappt
das. Gar kein Problem.
Wenn man natürlich meint, jeder Hinz und Kunz solle unbedingt auch
Industrieanwendungen entwickeln, nun, dann ist man halt schief
gewickelt.
In anderen Branchen gibt es auch Neuerungen: Brücken- und Straßenbau,
Elektrotechnik, Avionik,...
Da werden dann die Leute eben entsprechend ausgebildet und die
Qualitätssicherung bemüht und dann wird das auch 'was. Im Notfall
gibt's halt gesetzliche Auflagen (z.B. externe Kontrollingenieure).
Das ist alles eigentlich kein Problem. Und wenn man da in der EDV
endlich mal anfangen würde, professionell zu arbeiten, dann gäbe es
auch weniger Geschrei nach vernünftigem Fachpersonal, weil dann würde
das eben laufen und man müsste nicht ständig (wahllos) rumbasteln,
weil man keine Ahung hat, was man da eigentlich tut.
> Deshalb ist man ja schon von Assembler auf C umgestiegen. Heute steigt man
> halt von C auf Java um (C# eher von Turbo-Pascale). C++ ist leider wegen
> totaler Überfrachtung des Sprachkonzeptes und schlechter STL-Klassen
> gescheitert.
Klar, du hast richtig Ahnung. "Ich programmiere Java, weil ich zu dumm
bin, C++ oder C zu verstehen." Klar, doch. Da kommen dann ganz tolle,
garantiert fehlerfreie und problemlos laufende Programme bei
heraus. Und wen interessiert es schon, dass EDV-Bugdets begrenzt sind
und man nicht alle 2 Monate neue Hardware kaufen kann.
Sag mal, merkst du noch was?
Ich war vor einiger Zeit (ist jetzt wohl ca. 1,5-2 Jahre her) in einer
Rechtsanwaltskanzlei. Da wurde ich gefragt, ob man den 486er nicht
noch irgendwie fit machen könne -- schon wieder einen neuen Rechner zu
kaufen, wäre eigentlich nicht diskutabel.
Ach ja, und dann waren da noch die Anwendungen, effizient in C
geschrieben, die auch einen 4-fach Xeon mit 16GB RAM in die Knie
bringen. Aber auch das hätte man wohl besser in Java geschrieben, weil
das ist dann ja billiger, gelle.
Sag mal, wann warst du zuletzt mal in unserem Universum zu besuch?
> Für eine Fehlerkorrektur, ok, hindert dich ja keiner 'dran in einen
> Tag die Längenangabe anzugeben. Aber sich darauf verlassen, um dann
> Puffer zu reservieren, die eh überflüssig sind?
Hast du eigentlich überhaupt mal versucht, die Aussagen von mir oder
Felix zu verstehen? Nein? Dachte ich mir.
> > Was bitte stammelst du da? "Komprimierung... ein so weitreichendes
> > Thema"? Sag mal, bist du irgendwie auf Drogen oder sowas? Was ist da
> > weitreichend?
>
> Wird praktisch überall verwendet.
Richtig. Daher ist es auch kein "weitreichendes" Thema, sondern eine
nebensächliche Selbstverständlichkeit.
Ach ja, das komprimiertes XML dann wieder ein Binärformat ist, ist dir
schon klar?
> Genau. Nur dass es noch nicht alle Dateisysteme unterstützen. Aber
> auch noch an anderen Stellen ist es schon stellenweise Vorhanden:
> Netzwerk (PPP) oder Grafik (Komprimierung von Texturen). Das muss
> nur noch etwas ausgeweitet werden. Damit hat sich die Größe von
> XML-Dateien dann eh ins Nirwana verflüchtigt.
Der Plattenplatz, klar. Ich bin ja auch ein Freund von Unicode, das
wäre also eh nicht das Thema.
Aber XML hat einen gewaltigen Overhead und zum Augleich (als
universelles Dateiformat) keine (echten) Vorteile. Das ist das
Problem. XML löst (im Gegensatz zu Unix, TeX,...) keine Probleme, die
(konzeptionell) anders nicht (vernünftig) zu lösen wären. So bekomme
ich Bloat.
> > unterschiedlichsten Systemen gibt es erst seit XML, wie?
>
> Nein. Aber nicht in der Komplexität der Daten. Die Anwendungen
> werden komplexer und somit auch die Daten, die ausgetauscht werden
> müssen. Da kommt man CSV nicht mehr ohne grosse Hirnwicherei hin.
Argh! Da nehme ich dann doch aber kein Format aus der Steinzeit der
Datenbank-Forschung, da nehme ich dann etwas, dass der Struktur der
Daten angemessen ist. XML ist ein semistrukturiertes Datenformat --
bitte informiere dich.
> > Konfigurationsdateien in XML -- das ist grober Unfug, das gehört
> > eigentlich schon mit Berufsverbot bestraft. Von dem ganzen anderen
> > Müll, der da so getrieben wird, mal zu schweigen.
>
> Auch hier ist es eine reine Kostenfrage. Was kostet es mich einen
> Parser für eine Konfigurationsdatei zu schreiben.
Du mischst hier verschiedene Dinge. Es ist absolut lächerlich zu
behaupten, nur mit XML gäbe es ein einheitliches Programmierinterface
und bei anderen Dateiformaten wäre das unmöglich und der Programmierer
müsste wieder alles selber machen.
Wenn du auf diesem Nievau diskutieren willst, dann aber bitte ohne
mich.
> Da muss man mal die Folgekosten abschätzen. Den XML-Hype gibt es
> nicht ohne Grund: Die Leute kennen die Kosten für das Datenchaos. Da
Nur löst XML das Datenchaos nicht wirklich. Die Ursache hat meistens
nichts mit den Dateiformaten zu tun und selbst wenn ist XML so oder so
nicht die Lösung (entweder ist mangelde Dokumentation die Ursache oder
es wäre eh gleich ein RDBMS gefragt gewesen -- in beidn Fällen gewinnt
man durch XML rein gar nichts).
Den Leuten wird (wieder mal) der heilge Gral versprochen und in 5-6
Jahren merken sie dann, dass sie ihn wieder mal nicht bekommen haben
(aber der nächste wird schon unterwegs sein und man wird auch ihm
nachlaufen, um die Probleme, die XML verursacht hat, jetzt endlich in
den Griff zu bekommen und dann wird das Leben wieder paradisisch und
die Gewinne in Strömen fließen... ja, klar doch).
--
Stefan.
Stefan Nobis
> Alle Projekte die du da nennst sind viel zu alt. Als die entstanden gabs
> kein Java, C++ war fern von Standards...
Alle größeren Java-Projekte im Bereich Anwendungen (also jetzt keine
Java-Servlets oder -Applets, sondern richtige, umfangreiche
Standalone-Applikationen, die jenen in C/C++ das Wasser reichen
können), von denen ich so gehört habe (prominentestes Beispiel Corel
Office), sind gescheitert.
--
Stefan.
Henrik Motakef
> Die Hauptkritik an XML ist, dass es ein extrem aufgeblasenes, extrem
> komplexes Format ist, für das es eben keine ausgereiften, fehlerlosen
> Parser gibt.
Das Hauptproblem an dieser Kritik ist, das sie sachlich falsch
ist.
Die Hoffnung, dass ein Perl-Hacker an einem Wochenende einen Parser
bauen kann, mag sich nicht erfüllt haben, aber mal ehrlich: Das größte
Problem sind die verschiedenen erlaubten Encodings, der Rest ist doch
eher Fleissarbeit.
Und wenn du wirklich keine ausgereiften, fehlerlosen Parser kennst,
sei dir eine Suchmaschine ans Herz gelegt.
Nicht das es keine Probleme gibt, aber es sind andere. Zum Beispiel
ist XML für manche Anwendungen nicht mächtig genug - zum Beispiel wird
es schnell hässlich, wenn man mehrere überlappende Strukturen
auszeichnen will, da wäre etwas wie CONCUR oder etwa
Out-of-line-Markup oft eleganter. Noch deutlicher sind die Mängel bei
DTDs, bei denen man schon sehr oft gezwungen ist, Regeln im Prosa-Teil
der Dokumenttypdefinition unterzubringen.
Auch die Syntax selbst könnte besser sein; wenn man sowieso für jedes
Element das Ende explizit angeben muss und Überlappungen nicht
zugelassen sind, braucht man den GI im End-Tag eigentlich nicht mehr
wirklich.
DATA-Attribute wären auch ganz nett, wenn wir schon bei Wunschzetteln
sind. Aber XML ist eben genau mit Blick auf die Wünsche von
Parserherstellern entwickelt worden, die für SGML erwiesenermassen zu
blöd waren, diese premature optimization rächt sich gerade an
verschiedenen Stellen.
> Es gibt Einsatzgebiete, in denen SGML/XML Sinn macht -- aber XML als
> das Universal-Dateiformat für alles, von Müll, den die
> Textverarbeitung produziert, über Tabellen und Grafiken bis hin zu
> Konfigurationsdateien, das ist einfach haarsträubender Unsinn. Wer
> sowas propagiert ist auf Drogen oder hat keine Ahnung.
ACK - natürlich kann man XML missbrauchen. Bei Konfigurationsdateien
ist IMHO das Killerargument, dass man sie nicht mehr ohne
spezialisierte Tools automatisch bearbeiten kann - cat, grep und echo
versagen bei XML-Dateien normalerweise. Das stinkt in der Tat.
Und manche /Anwendungen/ von XML sind einfach auf so vielen Ebenen
schlecht ausgedacht, dass es tatsächlich ein Trauerspiel ist. SOAP
(die Fortführung von <font> mit anderen Mitteln, IMHO) ist ein gutes
Beispiel, W3C XML Schema ein anderes, zur Erheiterung sei auch
http://xplusplus.sf.net erwähnt. Dass das keine Probleme sind,
die durch XML unvermeidbar sind, zeigen die existierenden
Alternativen, im Falle von WXS zum Beispiel die DSDL-Sprachen wie
RELAX NG und Schematron. Aber scheussliche Sprachen kann man auch
prima ohne XML entwickeltn.
Gruß
Henrik, der immer nicht weiss, was das mit Unix zu tun hat, aber wenn
es euch so wichtig ist...
Rainer Weikusat
> Scherz beiseite: Die Programme werden immer aufwendiger und die
> Programmierer nicht klüger. Also müssen die Programmiersprachen diese
> Schere wieder einfangen. Anders kann das nicht funktionieren.
>
> Deshalb ist man ja schon von Assembler auf C umgestiegen.
Das ist ausgemachter Blödsinn. Ich habe mich gestern (wg Feiertag
partiell am Arbeiten gehindert) mal einen Nachmittag lang durch
'ancient Unix sources' (und man-pages und so) gewühlt und ua eine ca
eine halbe Seite lange 'cat'-Implementierung in Assembler gefunden. Es
gibt genau einen Grund, so etwas triviales in C zu machen: Man muß es
nicht für jeden Rechner neu schreiben.
> > Redundanz, desto leichter fallen i.d.R. z.B. auch
> > Plausibilitätsprüfungen. Von Fehlererkennung/-korrektur mal zu
> > schweigen.
>
> Für eine Fehlerkorrektur, ok, hindert dich ja keiner 'dran in einen
> Tag die Längenangabe anzugeben. Aber sich darauf verlassen, um dann
> Puffer zu reservieren, die eh überflüssig sind?
Kann es sein, das Du 'ein wenig' auf vorgeblich komplexe Anwendungen,
die vornehmlich interaktiv sind, fixiert bist?
> >>Nun ja, wenn man jemanden mutwillig fehlinterpretierten will. Platz
> >>ist heute genug vorhanden. Man kann nicht um jedes Byte jammern, was
> >>man weniger produzieren könnte.
> > Ja, diese saublöden Sprüche kenne ich. Hast du schon mal an die Firma
> > gedacht, die ihre Hardware nur alle 5-10 Jahre *teilweise*
> > erneuert.
>
> Selbst das Finanzamt schreibt einen Rechner nach 4 Jahren ab. Und wenn
> es um Geld geht, dann sind die recht kleinkariert. Nach 4 Jahren hat
> ein Rechner nur noch Schrottwert.
'Auf der Arbeit' sitze ich momentan vor einem coolen, älteren 19"-PC
(mit ISA-CPU-Karte und AMD K5 266 oder sowas). Wäre mir nicht
aufgefallen, daß der nur noch Schrottwert hätte, im Gegenteil: System
installiert, eingeschaltet, seitdem läuft er. Der Rechner kann auch
mit Sicherheit vollkommen problemlos jegliche Anforderungen an ein
Desktop-System erfüllen, falls man dafür geeignete Software
verwendet. Das konnten 4.77-Mhz-PCs eigentlich auch schon ganz gut,
sogar mit GUI, vgl Starwriter 6. Man kann das auch schnell
implementieren, im Gegensatz zu bspw bei Win3.
> Aber für eine Firma, die Geld verdienen möchte, ist ein alter Rechner
> zu teuer. Dort muss halt zu viel Entwicklungsarbeit in Detailfragen
> stecken, die heute einfach überflüssig sind. Ein Tag Entwicklung
> kostet ca. 1000 Euro.
Bitte?
> > XML ist im Großen und Ganzen so ziemlich das dämlichste, was gerade so
> > an Hype durch die IT-Landschaft tigert. Es gibt ein paar wenige,
> > begrenzte Bereiche, in denen es Sinn macht. Aber der Hype und dieses
> > "XML für alles" ist einfach nur schwachsinnig.
>
> Nein. TCP/IP für alles ist genau so hirnrissig.
TCP/IP ist kein Datenformat, sondern ein Protokoll, um 'irgendetwas'
über paketvermittelnde Netze zu übertragen. Und genau dafür wird es
auch verwendet. Ich kann hier keine Vergleichbarkeiten erkennen.
> > Konfigurationsdateien in XML -- das ist grober Unfug, das gehört
> > eigentlich schon mit Berufsverbot bestraft. Von dem ganzen anderen
> > Müll, der da so getrieben wird, mal zu schweigen.
>
> Auch hier ist es eine reine Kostenfrage. Was kostet es mich einen
> Parser für eine Konfigurationsdatei zu schreiben.
[...]
> Sicher: Für den Heim-PC im Studentenwohnheim rechnet sich das
> nicht. Das kostet dann halt der Programmierer (der nicht schlecht
> sein muss) halt 0.00 Euro.
Näherungsweise nichts: Die Shell hat bereits einen.
Gunnar Ritter
> Richtig. Im wesentlichen stimme ich dir auch zu. Vorteil hat aber das
> generische/logische Markup, wenn man das Dokument mehrfach
> konvertieren muss, also nicht nur gezielt für den Print-Bereich
> produziert, sondern das Buch/Dokument auch anderweitig (elektronisch)
> verarbeiten will/muss.
Vielleicht bin ich etwas altmodisch, aber unter einem _Buch_
verstehe ich etwas, das aus Papier und einer Heftung besteht.
Ich würde sogar behaupten, daß das die allgemein übliche
Bedeutung dieses Wortes ist. Du hättest einfach nicht «Buch»
sagen sollen.
> Und dass alle LaTeX Bücher, bei denen die Autoren großen Wert auf
> logisches Markup legten, häßlich aussehen, kann ich so auch nicht
> akzeptieren. Der Lamport und der LaTeX-Begleiter sehen schon ganz
> ordentlich aus
Wie bitte? Ich sagte doch, daß Du mal ein bißchen über Typographie
lesen solltest. Lamport habe ich gerade nicht zur Hand, aber die
deutsche Ausgabe des LaTeX-Begleiters besticht geradezu durch einen
total verkorksten Satzspiegel, viel zu breite Absatzeinzüge und ein
Sammelsurium von Schriften. Die Mikrotypographie ist auch scheiße,
Doppelpunkte, Semikolons und Fragezeichen kleben am vorhergehenden
Wort, Bindestriche ragen wie Streichhölzer aus der Satzkante heraus.
Wer das gesetzt hat, sollte dringend professionellen Rat einholen.
Wie üblich bei LaTeX-Leuten, die zwar mit Recht davon ausgehen, da
ein extrem brauchbares Satzprogramm zu haben, aber fälschlicherweise
auch der Überzeugung sind, sie müßten sich deshalb nicht persönlich
mit Typographie auskennen.
> und dort wurde AFAIK schon Wert auf logisches Markup
> gelegt
Allerdings. Geradezu ein Paradebeispiel für diese Unsitte.
>> nötig, da ein visuelles Markup einzuführen. Deshalb macht man
>> gute Bücher mit qualifizierten, bewährten Satzprogrammen und
> Klar. Wenn der Print-Bereich (nahezu) alleiniges Ziel der
> Buchproduktion ist, wäre SGML/XML auf jeden Fall mit Kanonen auf
> Spatzen geschossen, da gebe ich dir uneingeschränkt recht.
s/Buchproduktion/Produktion technischer Dokumentation/
> Der Vorteil hier wäre aber, dass mit gutem generischem Markup der
> Autor nur sehr wenig Ahnung von Typographie haben muss und der Setzer
> diese Markup-Wichse eben noch recht leicht (sprich größtenteils
> automatisiert) in etwas Lesbares verwandeln kann.
Nein. Er kann die Auszeichnungen halt komplett wegwerfen. Besser
ist es, wenn der Autor selbst mit Bedacht ausgezeichnet hat, dann
können Text und Auszeichnungen eine sinnvolle Einheit bilden.
Gunnar
Gunnar Ritter
> Naja, Mac OS X ist nicht so alt, ausserdem sind trotz des fehlenden
> Standards sowohl Darwin, Mac OS X als auch Star/OpenOffice in C++
> geschrieben.
Ach wirklich? Darwin? Also ich habe das immer für C gehalten. Und
mit Kompatibilität mußt Du jetzt nicht kommen.
Gunnar
Lukas Geyer
> Lukas Geyer <lu...@debian.org> wrote:
>
> > Naja, Mac OS X ist nicht so alt, ausserdem sind trotz des fehlenden
> > Standards sowohl Darwin, Mac OS X als auch Star/OpenOffice in C++
> > geschrieben.
>
> Ach wirklich? Darwin? Also ich habe das immer für C gehalten. Und
> mit Kompatibilität mußt Du jetzt nicht kommen.
Ich meinte das I/O Kit, dass eine API in einer eingeschraenkten
C++-Variante zur Verfuegung stellt, weshalb viele der Geraetetreiber
in Darwin halt in C++ geschrieben sind. Siehe zum Beispiel
http://www.cs.nmsu.edu/~lking/kernel.html
oder halt den ganzen Kram bei Apple. Also, ich war ungenau, aber
zumindest ein Teil von Darwin ist C++.
Lukas
Claus Färber
>> Wenn man die Daten nicht nur austauschen, sondern vielleicht auch
>> aufheben will, ist es schon sehr sinnvoll, ein Format zu nehmen, das
>> auch ein Mensch verstehen kann.
> Jedes Format, das eine Maschine verstehen kann, kann per Definition auch
> ein Mensch verstehen.
Wenn er die Beschreibung zu dem Format hast, sicher. Wenn die
Beschreibung zum Format aber verloren gegangen ist, kann es sehr
schwierig bis unmöglich sein.
XML hat hier den Vorteil, dass es ein bekanntes Grund-Format ist (bzw.
das Format sich durch die schiere Vielzahl an Dokumenten sich
rekonstruieren lässt) und die Strukturelemente dadurch, dass sie aus
Worten gebildet werden, leicht einer Bedeutung zugeordnet werden können.
> Wer sagt dir denn, daß ich ein binäres Format vorschlage?
Bislang hast du noch gar kein konkretes Format vorgeschlagen. Das
vereinfacht die Sache natürlich. Irgendetwas schlecht zu machen, ist
immer einfacher als etwas besseres zu erfinden.
> Ich bin schon ein Freund von Text, trotzdem muß da eine
> Längenkodierung rein.
Überlebt deine Längenkodierung ein recode?
>> Ah, alles klar. Wenn Programmierer anstatt einen neuen, fehlerhaften
>> Parsers für ihr einfaches, aber unklar spezifiziertes Format zu
>> schreiben einfach zu einer Bibliothek mit einem gut getesteten Parser
>> für ein bekanntes, gut-verstandenes Format greifen, dann hast du weniger
>> Aufträge zur Fehlersuche.
> Bin ich hier nur von Torfköppen umgeben? Keinen Plan aber nicht nur
> dumm rumlabern sondern mir persönliche Motive unterstellen?
Ah ja, fleißig austeilen, aber nicht einstecken können.
Claus Färber
> Und der Umkehrschluss, auf XML zu verzichten, heißt doch nicht, dass
> wieder jeder alles selber bastelt. Es gibt gute Alternativen zu XML
> inkl. fertigem Code für die Parser.
Es gibt sehr viele Alternativen. Viele davon haben Haken, die man erst
bemerkt, wenn's zu spät ist. Also wird wieder ein handgestrickter Work-
around eingebaut.
> Zudem sind viele einfache Formate (gerade für Konfigurationsdateien,
> um die es ursprünglich mal ging) so simpel, dass man als einigermaßen
> fähiger Programmierer das auch als Aufwärmübung ohne gravierende
> Mängel/Bugs hinbekommen sollte.
Man kann so viel falsch machen, man glaubt es kaum. Irgendein Benutzer
kommt immer auf die Idee, Werte einzugeben, die Zeichen enthalten, die
man als Trennzeichen vorgesehen hat. Und schon gehen die simplen Datei-
formate kaputt, man muss sie erweitern, man baut wieder andere Fehler
ein, das Format wäre schon wieder inkompatibel, etc.
Ich möchte es ehrlich gesagt nicht wissen, wieviele Leute sogar bei
etwas simplen wie einem CSV-Schreiber und -Parser patzen.
XML hätte außerdem den Vorteil, dass man sich als Administrator darauf
verlassen kann, dass sie immer gleich geparset werden. Man müsste nicht
mehr für jedes Programm ein anderes Format lernen (was im schlimmsten
Fall dazu führt, dass man seine Software falsch konfiguriert, weil das
Programm andere Vorstellungen über das Format hat).
Stefan Nobis
> Bedeutung dieses Wortes ist. Du hättest einfach nicht «Buch»
> sagen sollen.
Sorry, mein Fehler.
> Wie bitte? Ich sagte doch, daß Du mal ein bißchen über Typographie
> lesen solltest. Lamport habe ich gerade nicht zur Hand, aber die
> deutsche Ausgabe des LaTeX-Begleiters besticht geradezu durch einen
> total verkorksten Satzspiegel, viel zu breite Absatzeinzüge und ein
> Sammelsurium von Schriften. Die Mikrotypographie ist auch scheiße,
Was die Absatzeinzüge nun mit generischem/logischem kontra visuellem
Markup zu tun haben, wirst du auch irgendwann noch erläutern?
Hmmm... in den Fließtexten kann ich so viele verschiedene Schriften,
wie du hier suggerierst, nicht entdecken...
> Doppelpunkte, Semikolons und Fragezeichen kleben am vorhergehenden
...hierbei gebe ich dir allerdings Recht, für meinen Geschmack ist das
etwas eng gesetzt -- aber das hat auch wieder nichts mit generisch
kontra visuell zu tun.
> Wort, Bindestriche ragen wie Streichhölzer aus der Satzkante heraus.
> Wer das gesetzt hat, sollte dringend professionellen Rat einholen.
Das hingegen nennt man optischen Randausgleich und ob man darauf
steht, ist dann wieder eine grundlegende Frage, die mit Technik und
speziell generischem kontra visuellem Markup nichts zu tun hat.
> Wie üblich bei LaTeX-Leuten, die zwar mit Recht davon ausgehen, da
> ein extrem brauchbares Satzprogramm zu haben, aber fälschlicherweise
> auch der Überzeugung sind, sie müßten sich deshalb nicht persönlich
> mit Typographie auskennen.
Goossens, Mittelbach und Samarin haben gerade einen ziemlich großen
Aufwand getrieben, den optischen Randausgleich hinzubekommen, weil der
von vielen Typographen als Vorteilhaft angesehen wird.
Übrigens hat schon Gutenberg in seiner Bibel den optischen
Randausgleich (also Bindestriche und ähnliches, was ein Loch in das
Blockbild des Textes reißen würde) verwandt.
Wer soll sich hier jetzt eingehender mit Typographie beschäftigen?
--
Stefan.
Stefan Nobis
> XML hat hier den Vorteil, dass es ein bekanntes Grund-Format ist (bzw.
> das Format sich durch die schiere Vielzahl an Dokumenten sich
> rekonstruieren lässt) und die Strukturelemente dadurch, dass sie aus
> Worten gebildet werden, leicht einer Bedeutung zugeordnet werden können.
Mit dieser These wäre es auch beim Word-Format einfach, es ohne Doku
zu interpretieren. Auch XML schleppt keine Semantik mit und damit löst
XML gerade das Kernproblem beim Datenaustausch, nämlich die fehlende
semantische Beschreibung der Datenformate gerade nicht.
Böswillige würden sogar behaupten, dass durch den Aufbau von XML,
deren Tags ja (gelegentlich) lesbare Wörter sind, Missverständnisse
geradezu herausgefordert werden, da ein semantisches Verständnis
suggeriert wird, das gar nicht vorhanden ist -- bei klassischeren
Dateiformaten ist man sich der Problematik meist deutlicher bewusst.
--
Stefan.
Stefan Nobis
> Es gibt sehr viele Alternativen. Viele davon haben Haken, die man erst
> bemerkt, wenn's zu spät ist. Also wird wieder ein handgestrickter Work-
> around eingebaut.
Klasse. Und weil da irgendwann mal vielleicht ein Problem auftauchen
kann, nimmt gleich ein Format, nämlich XML, das ganz viele bekannte
Probleme hat. Gute Idee, ich bin begeistert.
> Ich möchte es ehrlich gesagt nicht wissen, wieviele Leute sogar bei
> etwas simplen wie einem CSV-Schreiber und -Parser patzen.
Und die können dann natürlich mit komplexen DOM-Strukturen umgehen
(nach dem Parsen muss man mit den Daten schließlich auch mal etwas
sinnvolles tun). Klar, sehe ich auch sofort ein.
> XML hätte außerdem den Vorteil, dass man sich als Administrator darauf
> verlassen kann, dass sie immer gleich geparset werden. Man müsste nicht
> mehr für jedes Programm ein anderes Format lernen (was im schlimmsten
> Fall dazu führt, dass man seine Software falsch konfiguriert, weil das
> Programm andere Vorstellungen über das Format hat).
Na Klasse. Ich verzichte also auf die leichte Manipulation von
kleinen, kompakten Konfigurationsdateien (durch sed, awk, cat, echo
und Co) und statt einer meist sehr leicht zu entdeckenden
Fehlkonfiguration durch Syntaxfehler bekommen ich dann zuhauf
semantische Fehler in meine Konfigurationsdateien, weil zwar dank XML
die Syntax korrekt war, aber leider zwei verschiedene Programme mit
demselben Tag völlig verschiedene Dinge meinen (und der semantische
Fehler natürlich durch das Programm praktisch unmöglich abgefangen
werden kann, im Gegensatz zu syntaktischen Fehlern).
Also so richtig begeistert bin ich von deinen Ideen nun wirklich
nicht.
--
Stefan.
Christian Parpart
> Marcus Hampel <marcus...@myview.de> writes:
>
> [Neuere Programmiersprachen]
>> Nein, aber sie berechnen den Speicherbedarf selbstständig und
>> beseitigen damit auch die Bufferoverflows.
>
> Solange du nicht mit C++ kommst (da gibt's auch reichlich Beispiele
> mit Buffer-Overflows)
Nun, nenn mir mal bitte die so reichlichen Buffer Overflows die man deiner
Meinung nach staendig in C++ Programmiert. Ich bin nur neugierig, da ich
persoenlich C++, gerade durch die STL, fuer eine sicherere Alternative als
die plain C API halte.
MfG,
Christian Parpart.
Stefan Nobis
> Nun, nenn mir mal bitte die so reichlichen Buffer Overflows die man deiner
> Meinung nach staendig in C++ Programmiert. Ich bin nur neugierig, da ich
> persoenlich C++, gerade durch die STL, fuer eine sicherere Alternative als
> die plain C API halte.
Gerade im Bereich STL gibt es durchaus einige Fallen, wenn auch nicht
alle auf klassische BOs hinauslaufen. Auch in C++ hat man noch ständig
mit manueller Speicherverwaltung (new/delete -- oder benutzt du die
nie in C++ Programmen?) zu tun, auch wenn man das in Klassen kapselt
-- und dort ist dann eben immer auch Platz für BOs.
Zudem greift nicht immer jeder auf die C++ Klasse string zurück, zumal
sie IIRC wirklich erst ganz zum Schluss in den Standard aufgenommen
wurde.
--
Stefan.
Rainer Weikusat
> Zudem greift nicht immer jeder auf die C++ Klasse string zurück, zumal
> sie IIRC wirklich erst ganz zum Schluss in den Standard aufgenommen
> wurde.
Die STL-'Feldersatz'-Typen sind für reale Programmierung (also nicht
nur als framework jockey) nicht geeignet, weil sie keinerlei Garantien
über das Speicherlayout machen, dh per se mit nichts interagieren
können.
Ansonsten stelle ich mal wiederholt die Frage: Was ist so unglaublich
esoterisch daran, nicht 29 chars in einen Puffer der Größe 28 zu
schreiben? Die 'klassische' Un*x-Ausrede dürfte 'performance' gewesen
sein, damit gibt es heute wohl dabei keine Probleme mehr. Ich verwende
maschinennahe Sprachen gezielt deswegen, weil sie nicht versuchen,
meine Fehler zu verbessern. Eine innere Schleife, die char-weise Daten
über Zeiger kopiert, wird zu einem unerträglich bloat-monster, wenn
man stattdessen array-indices verwendet und die auch noch bei jedem
Zugriff sinnloserweise mit einem irgendwo gespeicherten Maxmialwert
vergleicht. Das immer wieder gerne angeführte Argument, daß die
Computer ja heute so schnell wären, scheint mir in diesem Zusammenhang
unsinnig: Was bringt mir ein schneller Computer, wenn dessen erhoehte
Leistung dafür draufgeht, daß Programme mit weniger Sorgfalt
entwickelt werden koennen?
Stefan Nobis
> Die STL-'Feldersatz'-Typen sind für reale Programmierung (also nicht
> nur als framework jockey) nicht geeignet, weil sie keinerlei Garantien
> über das Speicherlayout machen, dh per se mit nichts interagieren
> können.
Unfug. Das wurde schon mehrfach in dcl.iso-c++ durchgekaut: Es gibt
einen Defekt-Report, der eben genau klarstellt, dass vor allem vector
und string bei entsprechenden Zugriffsmethoden zusammenhängenden
Speicher liefern muss (der dann problemlos an ein typ[] einer
C-Funktion übergeben werden kann).
Und schon vorher war dieses Verhalten naheliegend, so dass auch alle
mir bekannten STL-Implementierungen nie etwas anderes getan haben.
(Aber du hast schon insoweit Recht, dass im Wortlaut des eigentlichen
Standards keine solchen Garantien gemacht werden -- aber die
Defekt-Reports sind letztlich auch Bestandteil des Standards und
sollten daher nicht einfach ignoriert werden.)
> sein, damit gibt es heute wohl dabei keine Probleme mehr. Ich verwende
> maschinennahe Sprachen gezielt deswegen, weil sie nicht versuchen,
> meine Fehler zu verbessern. Eine innere Schleife, die char-weise Daten
Die meisten höheren Sprachen, wurden nicht entwickelt, um Fehler des
Entwicklers irgendwie zu verbessern -- hinter Haskell, OCaml, Lisp
etc. stecken da doch deutlich andere Ideen und Motivationen.
> unsinnig: Was bringt mir ein schneller Computer, wenn dessen erhoehte
> Leistung dafür draufgeht, daß Programme mit weniger Sorgfalt
> entwickelt werden koennen?
Full ACK. Ich finde diesen Kreislauf auch reichlich dümmlich.
--
Stefan.
Stefan Nobis
> Stefan Nobis <ste...@snobis.de> writes:
> >Na Klasse. Ich verzichte also auf die leichte Manipulation von
> >kleinen, kompakten Konfigurationsdateien (durch sed, awk, cat, echo
> >und Co)
>
> Das ist doch haltloses Gejammer, das seine Ursache
> hauptsaechlich darin hat, dass Dir Kommandoteilentools fuer XML
> fehlen, also ein xmlxpathselect zur Selektion von Teilbaeumen
> auf der Basis von XPath-Ausdruecken, ein xmlcontentgrep zur
> Ausgabe matchendem Cdata in Containern mit matchenden
> Elementnamen und vielleicht ein domoperation-Kommando zur
> Ausfuehrung selbiger Operationen auf einem Domtree, der aus
> einem Dokument generiert wird. Sowie vielleicht noch ein csv2xml
> und xml2csv (mit waehlbaren Quote- und Kommazeichen verarbeitet
> das nahezu jedes Flatfile-Format).
Nur ist das eine deutlich komplexere Angelegenheit als die derzeitige
Struktur von Konfigurationsdateien -- meinst du wirklich, man gewinnt
mit XML für *Konfigurationsdateien* irgend etwas, das diesen
Komplexitätszuwachs rechtfertigt?
--
Stefan.
Henrik Motakef
> Stefan Nobis <ste...@snobis.de> writes:
>> Na Klasse. Ich verzichte also auf die leichte Manipulation von
>> kleinen, kompakten Konfigurationsdateien (durch sed, awk, cat, echo
>> und Co)
>
> Das ist doch haltloses Gejammer, das seine Ursache
> hauptsaechlich darin hat, dass Dir Kommandoteilentools fuer XML
> fehlen, also ein xmlxpathselect zur Selektion von Teilbaeumen
> auf der Basis von XPath-Ausdruecken, ein xmlcontentgrep zur
> Ausgabe matchendem Cdata in Containern mit matchenden
> Elementnamen und vielleicht ein domoperation-Kommando zur
> Ausfuehrung selbiger Operationen auf einem Domtree, der aus
> einem Dokument generiert wird. Sowie vielleicht noch ein csv2xml
> und xml2csv (mit waehlbaren Quote- und Kommazeichen verarbeitet
> das nahezu jedes Flatfile-Format).
Abgesehen davon, dass du das vermutlich ohnehin nicht ernst meinst (es
könnten Kinder mitlesen!): NACK.
Erstens ist ein wesentliches Feature von sedgrepechocatawk, das es
einfach überall schon da ist, was man von "xmlcontentgrep" wohl kaum
behaupten kann; selbst sgrep, was es sogar tatsächlich gibt, ist eher
selten.
Zweitens wäre eine normale Unix-Pipe, die aus den von dir
vorgeschlagenen Programmen zusammengesetzt ist, tatsächlich enorm
ineffektiv. Da man nur XML-Syntax und kein Infoset zwischen den
Programmen hin- und herschieben könnte, müsste jedes Popel-Programm
die Ausgabe des Vorgängers erst mal parsen.
Drittens: Was würde xmlxpathselect ausgeben? Ich vermute mal, ein
Nodeset, also mitnichten zwangsläufig ein wohlgeformtes (oder auch nur
"well-balanced") XML-Dokument, was notwendigerweise geeigneter Input
für das nächste Element der Pipe sein könnte. Nebenbei bemerkt ist
XPath ohne geeignete Host Language auch kein Spass, man kann nicht mal
Variablen definieren. Ganz abgesehen davon, dass man z.B. auf
document() verzichten müssten, das ist nämlich Teil von XSLT, nicht
XPath.
Viertens wäre insbesondere eine shelltaugliche Version des DOM
wirklich nur als Braindead zu bezeichnen. Nicht nur, dass die API
offenkundig bis ins Mark Cobol^WJava(Script)?-orientiert ist (was aus
ihrer Geschichte ja verständlich ist - DOM ist als Vermittlungsversuch
im Browser-War entstanden, nicht als schlau ausgedachte XML-API. Das
ist was, worin das W3C sogar einigermassen gut war. Hätten sie sich
mal darauf beschränkt.) und man sich bei den einfachsten Sachen
tottippt, es ist auch aus XML-Sicht wie auch aus allgemeinen
ästhetischen Überlegungen heraus, wenn man ehrlich ist, ziemlicher
Kappes. Warum darf doc.createComment("foo -- bar") keine Exception
werfen? Oder doc.createCDATASection("tag ]]> soup")? Ist es wirklich
sinnvoll, createAttribute, createAttributeNS, createAttributeNode und
createAttributeNodeNS zu haben, wenn deren Beziehungen allenfalls
halbherzig spezifiziert sind? Was ist der Unterschied zwischen
element.nodeName() und element.tagName()? Warum ist attributes Teil
des Node-Interfaces, wenn es sowieso nur für Element != NULL ist?
Und wie man ein Infoset - inklusive z.B. IDREFS - so in eine
CSV-Struktur zwingt, dass es sinnvoll ist, sie mit sedgrepechocatawk
zu bearbeiten ist, musst du erst mal vormachen. Wenn schon, scheint
Pyxie sinnvoll zu sein, mit Übersetzungen von/zu XML am Anfang und
Ende der Pipe, aber auch damit stösst man verdammt schnell an die
Grenzen.
> Oder anders gesagt, das ist leicht reparierbar (Ich haette da
> ein paar PEAR-Klassen, mit denen man Prototypen bauen kann,
> bevor man das in C finalisiert).
Wenn sich in den letzten zwei Monaten nicht wirklich viel geändert
hat, wäre PHP eine der wenigen Sprachen, die mir für die
XML-Bearbeitung noch ungeeigneter erscheinen als Q&D-Hacks wie C. In C
gibt es wenigstens die libxml, und nicht nur die Teile, die irgendein
ungewaschener "PHP-Hacker" verstanden hat. Auch wenn man davon
absieht, dass PHP als Sprache nun wirklich von Wäppdisainern für
Wäppdisainer entwickelt wurde, strahlen im Vergleich bezüglich
benutzbarer Bibliotheken selbst OCaml und Erlang als Silberstreif am
Horinzont, wenn es um Sachen geht, die Leute interessieren, die lesen
können.
next please
Henrik
Gunnar Ritter
> Was die Absatzeinzüge nun mit generischem/logischem kontra visuellem
> Markup zu tun haben, wirst du auch irgendwann noch erläutern?
Ich habe hier Dein «... und der LaTeX-Begleiter sehen schon ganz
ordentlich aus» kommentiert.
> Das hingegen nennt man optischen Randausgleich
Mann! Halte doch einfach die Fresse, wenn Du keine Ahnung hast.
Dafür gibt es Lehrbücher, in denen steht, wie man sowas richtig
macht.
> Wer soll sich hier jetzt eingehender mit Typographie beschäftigen?
Du.
Gunnar
Gunnar Ritter
> meine Fehler zu verbessern. Eine innere Schleife, die char-weise Daten
> über Zeiger kopiert, wird zu einem unerträglich bloat-monster, wenn
> man stattdessen array-indices verwendet
Das muß man nicht tun. Man kann auch Pointer mit einem Maximum
vergleichen. Und wenn es nur wenige Pointer sind, kann man die
nach dem realloc() mühelos neu setzen. BTDT.
Außerdem, who cares? Was man an Code draufsetzt, spart man an
nicht zwischen Programminstanzen zu sharenden Daten im Normalfall
mühelos damit ein. In POSIX-kompatiblen Programmen kommt man statt
mit LINE_MAX-Buffern bei typischen Eingabedaten mit 80 Bytes aus.
> und die auch noch bei jedem Zugriff sinnloserweise mit einem irgendwo
> gespeicherten Maxmialwert vergleicht.
Nicht unbedingt. Man kann sowas richtig und performant machen. Als
sie bei Sun in den Achtzigern ihre Bourne-Shell vom SEGV-Handling
auf sowas umgestellt hatten, haben sie schon damals keinen
Performancenachteil mehr messen können. Und Performance innerhalb
des Parsers oder Lexers ist bei unbloatigen Sprachen auch wirklich
nicht von großer Bedeutung.
Nur sind die meisten Leute halt zu dämlich, sowas zu programmieren.
Gunnar
Gunnar Ritter
> Übrigens hat schon Gutenberg in seiner Bibel den optischen
> Randausgleich (also Bindestriche und ähnliches, was ein Loch in das
> Blockbild des Textes reißen würde) verwandt.
Klar hat Gutenberg das in der 42-zeiligen Bibel auch so gemacht.
Aber er hat da auch Satzzeichen gleich weit vom vorangegangenen
Wort wie vom folgenden abgesetzt, so daß es wie Plenken aussieht:
«foo . bar». Er hat Wörter an anderen Stellen bis auf etwa ein
Sechstelgeviert zusammengedrängt. Aber er hatte auch eine ganz
andere Schrift mit einem viel höheren Grauwert.
Möchtest Du das alles auch so machen, nur weil es Gutenberg gemacht
hat? Das möchte ich mal sehen, Dein Informatiklehrbuch in Texturtype.
Du solltest Deine Lehrtexte lieber von Berufstypographen beziehen
als von herumdilettierenden Informatikern.
Gunnar
Gunnar Ritter
> Übrigens hat schon Gutenberg in seiner Bibel den optischen
> Randausgleich (also Bindestriche und ähnliches, was ein Loch in das
> Blockbild des Textes reißen würde) verwandt.
Klar hat Gutenberg das in der 42-zeiligen Bibel auch so gemacht.
Aber er hat da auch Satzzeichen gleich weit vom vorangegangenen
Wort wie vom folgenden abgesetzt, so daß es wie Plenken aussieht:
«foo . bar». Er hat Wörter an anderen Stellen bis auf etwa ein
Sechstelgeviert zusammengedrängt. Aber er hatte auch eine ganz
andere Schrift mit einem viel höheren Grauwert.
Möchtest Du das alles auch so machen, nur weil es Gutenberg gemacht
hat? Das möchte ich mal sehen, Dein Informatikbuch in Texturtype.
Du solltest Deine Lehrtexte lieber von Fachtypographen beziehen
Stefan Nobis
> > Das hingegen nennt man optischen Randausgleich
>
> Mann! Halte doch einfach die Fresse, wenn Du keine Ahnung hast.
> Dafür gibt es Lehrbücher, in denen steht, wie man sowas richtig
> macht.
Gunnar, wenn du nur rumpöbeln willst, sag das doch einfach.
Ich dachte, zur Abwechslung hättest du mal an einer konstruktiven
Diskussion interesse. Sorry für das Missverständnis, ich versuche,
dich in Zukunft nicht mehr ernst zu nehmen.
--
Stefan.
Uwe Ohse
>Hoffnung. Von daher ist ein vorgefertigter XML-Parser einem
>selbstgehackten Stueck Scheisse, das vorgeblich CSV parsen kann,
>deutlich vorzuziehen.
Es sei denn, der vorgefertigte XML-Parser ist selbst kein bischen besser.
Was natürlich nicht in der Praxis auftritt, denn XML-Parser sind ja
professionell gemacht, wohl designed und entsprechend der Komplexität
des Problems getestet und überprüft.
Apropos, vergleichst Du gerade von Idioten selbstgemachte schlechte
CSV-Parser mit von Idioten eingesetzten, aber nicht von Idioten
gemachten XML-Parsern?
Schade nur, daß die XML-Parser, mit denen zu tun zu bekommen ich bisher
das Mißvergnügen hatte, allesamt Softwaremüll waren. Ok, ich bin in dem
Punkt sicherlich kein Maßstab, ich habe wahrscheinlich nur Pech bei der
Auswahl meine Software.
Von daher stammt das Folgenden nicht von mir, sondern aus einem Code,
der ziemlich viel mit XML macht (Datenbank <-> XML <-> externe Anwendungen).
/* absichtlich nicht kommentiert. Mir wird schlecht wenn ich darueber
* nachsinniere. Hamann, ukck, 16-28.10.2001, 24-26.7.2002. */
/* outbound */
static void xml_workaround_no_cr(stralloc *);
static void xml_workaround_electric_junk_library(stralloc *);
static void xml_workaround_8bit_to_7bit(stralloc *);
static void xml_workaround_libxml1_bugs(stralloc *);
static void xml_workaround_tag_to_lower(stralloc *);
static void xml_workaround_unknown_java_junk_library(stralloc *);
static void xml_workaround_KUNDENNAME1(stralloc *);
[...]
/* inbound */
static void xml_workaround_broken_utf8_cleanup(stralloc *);
static void xml_workaround_latin1_to_utf8(stralloc *);
static void xml_workaround_dos_to_utf8(stralloc *);
static void xml_workaround_windows_to_utf8(stralloc *);
static void xml_workaround_fix_tag_capitalization(stralloc *);
static void xml_workaround_tab_to_8_spaces(stralloc *); /* wa. f. KUNDE */
static void xml_workaround_libxml2_sanitize1(stralloc *); /* reihenfolge: 1*/
static void xml_workaround_libxml2_bugs(stralloc *); /* reihenfolge: 2*/
static void xml_workaround_libxml2_sanitize2(stralloc *); /* reihenfolge: 3*/
Richtig übel war aber erst der Abschnitt mit den Funktionen, die mit
xml_optimize_ begannen. Ein halber XML-Parser, um die Performanceprobleme
anderer Parser zu umgehen.
Ach ja, wenn man an deren Datenbank heran will, darf man zusätzlich zu
allem Vertragsmüll, auch noch angeben, welche XML-Lirary man nutzt.
Meine eigenen Erfahrungen mit xml-Libraries bestätigen dies. Ich habe bisher
keine einzige xml-Library gefunden, die auch nur _wenig_ Bugs gehabt hätte.
Was war noch mal Deine Aussage? Daß XML aus einem Elfenbeinturm betrachtet
einen gewissen Reiz hat?
Gruß, Uwe
Florian Cramer
> Gunnar Ritter <g...@bigfoot.de> writes:
>
>> > Das hingegen nennt man optischen Randausgleich
>>
>> Mann! Halte doch einfach die Fresse, wenn Du keine Ahnung hast.
>> Dafür gibt es Lehrbücher, in denen steht, wie man sowas richtig
>> macht.
>
> Gunnar, wenn du nur rumpöbeln willst, sag das doch einfach.
Was wäre diese Newsgroup ohne Flamefests?
Und: Wo Gunnar recht hat, hat er recht. Bei der
Standard-LaTeX-Propaganda, derzufolge "Sie sich nicht mehr um
Typographie kümmern müssen, weil LaTeX den Typographen ersetzt", wurde
mir schon immer schlecht (obwohl ich LaTeX intensiv einsetze).
Die für diese Newsgroup geeigneten Nachweis liefert Jürgen Gulbins,
der nicht nur die bekannte Unix-Einführung geschrieben hat, sondern auch
zusammen mit der Schriftsetzerin Christine Kahrmann das Handbuch "Mut
zur Typographie". Wer letzteres gelesen hat, weiß, warum einen
Typographen ebensowenig durch einen Algorithmus ersetzen kann wie z.B.
auch einen Architekten oder Ingenieur, es sei denn, man beschäftigt sich
ernsthaft mit KI.
Florian
--
http://userpage.fu-berlin.de/~cantsin/homepage/
http://www.complit.fu-berlin.de/institut/lehrpersonal/cramer.html
GnuPG/PGP public key ID 3200C7BA, finger can...@mail.zedat.fu-berlin.de
Rainer Weikusat
Vorab: Entweder, ich verstehe überhaupt nicht, wovon Du redest,
oder wir reden beide total aneinander vorbei. Deswegen muß ich
jetzt mal ein paar möglicherweise wirklich dumme Fragen
stellen.
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
> > meine Fehler zu verbessern. Eine innere Schleife, die char-weise Daten
> > über Zeiger kopiert, wird zu einem unerträglich bloat-monster, wenn
> > man stattdessen array-indices verwendet
>
> Das muß man nicht tun. Man kann auch Pointer mit einem Maximum
> vergleichen. Und wenn es nur wenige Pointer sind, kann man die
> nach dem realloc() mühelos neu setzen. BTDT.
if (!remain) { \
ptrdiff_t ofs = p - dtk->start; \
int rc; \
rc = dtoken_expand(dtk); \
if (rc) return rc; \
p = dtk->start + ofs; \
remain = dtk->alloc - ofs; \
}
?
Falls Du nicht soetwas ähnliches meinst, s.o. Hatte ich schon mal
erwähnt, das ich grundsätzlich niemals stdio verwende (readline
manchmal -- 'display updateing' unter Un*x macht 'von ferne' den
Eindruck, daß man es ohne eine solide Erfahrung mit unterschiedlichen
Terminals und ohne einen zwingenden Grund dafür lieber den Leuten
überlassen sollte, die welche haben), weil das schöne bei blockweiser
I/O ist, daß man nicht herumraten muß, wie groß ein Puffer werden
soll, sondern einfach mit einem kleinen anfängt und den schnell
vergrößert, solange noch Daten ankommen (und ggf später mit realloc
wieder einschrumpft, falls man nicht denselben weiterverwenden
möchte) und zwar vor allem deswegen, weil die I/O-Operationen von
(Turbo) Pascal (3) so ausnehmend pathetic waren, daß es einfacher war,
sie (in x86-Assembler) etwas gebrauchsfähiger zu re-implementieren,
anstatt um ihre Defekte herumzuwürgen? DOS-Programmierung ist
überhaupt eine empfehlenswerte Sache, um einen Sinn für Details zu
entwickeln, weil das ungefähr so aussieht:
Back around 1970-71, Unix on the PDP-11/20 ran on hardware
that not only did not support virtual memory, but didn't
support any kind of hardware memory mapping or protection, for
example against writing over the kernel. This was a pain,
because we were using the machine for multiple users. When
anyone was working on a program, it was considered a courtesy
to yell "A.OUT?" before trying it, to warn others to save
whatever they were editing.
<URL:http://cm.bell-labs.com/cm/cs/who/dmr/odd.html>
... und es noch die schöne Zusatzmöglichkeit gibt, mit Hilfe wahllos
überschriebener Gerätetreiberteile wirklich (teuren) Schaden
anzurichten.
Zumal ja auch readv(2)/writev(2) sinnvolle Einsatzzwecke haben.
> > und die auch noch bei jedem Zugriff sinnloserweise mit einem irgendwo
> > gespeicherten Maxmialwert vergleicht.
>
> Nicht unbedingt. Man kann sowas richtig und performant machen.
Huh?
Das Problem, daß viele Leute bei Zeigern sehen, ist ja, das die
'unbound' sind, dh es gibt keine Möglichkeit, dem Zeiger anzusehen, ob
*(p += 2) jetzt einen segfault oder sonstwas ergibt. Die
'objektorientierte' Methode, dieses Problem zu umgehen, bestünde jetzt
darin, zu dem Schluß zu kommen, daß man 'eigentlich' nicht mit
Speicherbereichen arbeitet, sondern diversen spezialisierten Varianten
dynamisch alloziierter Puffer, deren Verwaltungs-Kontrollstrukturen
nicht versehentlich änderbar sind, wobei die Abstraktion interne
Konsistenz gewährleistet. Auf deren Elemente greife ich dann über
einen Index oder mit Hilfe an das Objekt gebundener Zeiger-Emulationen
zu, wobei in Wahnsinnsfällen 'out of bounds'-Exceptions erzeugt
werden. Je nach (GNU-)Compilerversion gibt es stattdessen
gelegentlich ein SIGSEGV und falls ich tausende dieser Zugriff
hintereinander mache, sind das ziemlich viele Vergleiche, von denen
die meisten vollkommen sinnlos sind. Wenn man sich mal anschaut, was
für einen Müll bspw gcc produziert, ist die Vermutung gerechtfertigt,
daß irgendeine meiner Variablen todsicher trotz eines freien Registers
auf dem Stack enden wird, das bläht die Dinge dann noch weiter auf.
Natürlich gibt das für den Einzelfall keine meßbaren Unterschiede,
aber falls das Programm sechs Monate durchläuft, dürfte sich da
einiges an CPU-Zeit aufsummieren.
Als eigentliches Gegenargument würde ich aber "Es nützt nichts"
ansehen.
Rainer Weikusat
Vorab: Entweder, ich verstehe überhaupt nicht, wovon Du redest,
oder wir reden beide total aneinander vorbei. Deswegen muß ich
jetzt mal ein paar möglicherweise wirklich dumme Fragen
stellen.
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
> > meine Fehler zu verbessern. Eine innere Schleife, die char-weise Daten
> > über Zeiger kopiert, wird zu einem unerträglich bloat-monster, wenn
> > man stattdessen array-indices verwendet
>
> Das muß man nicht tun. Man kann auch Pointer mit einem Maximum
> vergleichen. Und wenn es nur wenige Pointer sind, kann man die
> nach dem realloc() mühelos neu setzen. BTDT.
if (!remain) { \
ptrdiff_t ofs = p - dtk->start; \
int rc; \
rc = dtoken_expand(dtk); \
if (rc) return rc; \
p = dtk->start + ofs; \
remain = dtk->alloc - ofs; \
}
?
> > und die auch noch bei jedem Zugriff sinnloserweise mit einem irgendwo
> > gespeicherten Maxmialwert vergleicht.
>
> Nicht unbedingt. Man kann sowas richtig und performant machen.
Huh?
Holger Marzen
> Hallo Kristian,
s/Hallo Kristian/Kristian schrieb/
>>Hoffnung. Von daher ist ein vorgefertigter XML-Parser einem
>>selbstgehackten Stueck Scheisse, das vorgeblich CSV parsen kann,
>>deutlich vorzuziehen.
>
> Es sei denn, der vorgefertigte XML-Parser ist selbst kein bischen besser.
> Was natürlich nicht in der Praxis auftritt, denn XML-Parser sind ja
> professionell gemacht, wohl designed und entsprechend der Komplexität
> des Problems getestet und überprüft.
Eben das befürchte ich doch immer. Das kriegen die "Junger Entwickler
gesucht für Windows NT/2000, MFC-Kenntnisse erforderlich" einfach nicht
hin.
[Horrorcode mit vielen selbstgebauten Fixes für kaputte, wahrscheinlich
"professionelle" und "fertige" XML-Libs gesnipt]
> Meine eigenen Erfahrungen mit xml-Libraries bestätigen dies. Ich habe bisher
> keine einzige xml-Library gefunden, die auch nur _wenig_ Bugs gehabt hätte.
Ich behaupte, dass XML-Utilities in den meisten Fällen komplexer sind
als das eigentlich zu lösende Problem. Gut, das gilt auch für Compiler,
insbesondere in den frühen Jahren und bei kaufmännischen Anwendungen.
Wir müssen also nur ein paar Jahrzehnte warten, dann ist die Sache im
Griff, und es wird mit XML alles gut[TM] (falls sich dann noch einer
daran erinnern will).
Uwe Ohse
>Ich möchte es ehrlich gesagt nicht wissen, wieviele Leute sogar bei
>etwas simplen wie einem CSV-Schreiber und -Parser patzen.
Schließt Du auch aus der Tatsache, daß manche Leute grauenvolle Romane,
Essays, Kurzgeschichten, Dokumentationen oder Reportagen schreiben, daß
niemand das kann / sollte?
>XML hätte außerdem den Vorteil, dass man sich als Administrator darauf
>verlassen kann, dass sie immer gleich geparset werden. Man müsste nicht
Nope. Du übersiehst das Problem, daß ein Verständnis des Format nichts,
aber auch gar nichts, über das Verständnis des Inhalts aussagt.
Das Problem löst weder eine (bestimmt irgendwo existierende) miese
CSV-Implementierung noch eine hypothetische perfekte XML-Library.
>mehr für jedes Programm ein anderes Format lernen (was im schlimmsten
>Fall dazu führt, dass man seine Software falsch konfiguriert, weil das
>Programm andere Vorstellungen über das Format hat).
Wie schlimm.
Da ist es doch viel besser, daß <useridentifikation>2500</useridentifikation>
vom einen Programm als Benutzername 2500 angesehen wird, während das Bächste
auf den Gedanken verfällt, den Namen des Benutzers aus den Daten des
Benutzers Nummer 2500 herauszusuchen.
Ach so, wenn man das entstehende Chaos sortieren will, darf man, wie gehabt,
Quelltexte lesen. Nur diesmal die Quelltexte der Programme kombiniert mit
der / den DTD(s).
Insofern bleibt alles beim Alten.
Gruß, Uwe
Gunnar Ritter
> Ich dachte, zur Abwechslung hättest du mal an einer konstruktiven
> Diskussion interesse.
Du kannst wiederkommen, wenn Du Dich informiert hast. Solange
Du hier nur uninformiert herumfaselst, habe ich natürlich in
der Tat kein Interesse, mit Dir konstruktiv zu diskutieren.
Wieso sollte ich auch? Ich diskutiere nur dann konstruktiv,
wenn der Diskussionsgegner über die nötige Minimalkompetenz
verfügt. Dazu gehört, daß er nicht mit ihm nicht vertrauten
Fachwörtern wie «Randausgleich» um sich wirft. Ich gehe ja
auch nicht nach de.sci.medizin und erzähle den Leuten was
über Hepatitis.
Gunnar
Gunnar Ritter
> Die für diese Newsgroup geeigneten Nachweis liefert Jürgen Gulbins,
> der nicht nur die bekannte Unix-Einführung geschrieben hat, sondern auch
> zusammen mit der Schriftsetzerin Christine Kahrmann das Handbuch "Mut
> zur Typographie".
In dem sich (2. Auflage 2000) auf S. 91 übrigens auch ein schönes
Beispiel dafür findet, wie man Randausgleich richtig macht.
Gunnar
Gunnar Ritter
> Vorab: Entweder, ich verstehe überhaupt nicht, wovon Du redest,
> oder wir reden beide total aneinander vorbei.
Ich hatte dich so verstanden, daß Du behauptet hattest, daß
dynamische (Re-)Allokation unweigerlich mehr Bloat erzeugt
als statische Buffer. Ich entgegne, daß das nicht stimmt.
Ich habe in letzterer Zeit aus mehreren älteren Programmen
statische Buffer eliminiert, und sie sind alle nur um wenige
kB Code größer und nicht nachvollziehbar langsamer geworden,
verbrauchen aber erheblich weniger Speicher für Daten.
>> Das muß man nicht tun. Man kann auch Pointer mit einem Maximum
>> vergleichen. Und wenn es nur wenige Pointer sind, kann man die
>> nach dem realloc() mühelos neu setzen. BTDT.
> if (!remain) { \
#define check(ptr, buf, len) if (&ptr[1] >= &buf[len]) { \
size_t ppos = ptr - buf; \
buf = realloc(buf, len += 32); \
ptr = &buf[ppos]; \
}
anstatt von Code wie
char *bufend = &buf[sizeof buf];
...
if (&ptr[1] >= bufend)
error(nomem);
Da Du den ersten Check wg. Vermeidung von Buffer Overflows sowieso
irgendwo machen mußt, besteht der ganze Mehraufwand in den drei
Zeilen darunter. Die sparen ein Vielfaches ihrer Größe an Speicher
in schreibbaren Datenpages wieder ein.
> Das Problem, daß viele Leute bei Zeigern sehen, ist ja, das die
> 'unbound' sind, dh es gibt keine Möglichkeit, dem Zeiger anzusehen, ob
> *(p += 2) jetzt einen segfault oder sonstwas ergibt.
Ah, und bei p[i += 2] («array-indices») sieht man das eher, ja?
> Die 'objektorientierte' Methode, dieses Problem zu umgehen, bestünde jetzt
... wahrscheinlich in Bloat. Das könnte an der Objektorientierung
liegen, aber es liegt mit Sicherheit nicht daran, daß Du mit einem
kleinen Buffer anfängst, seine Länge checkst und ggf. reallozierst.
Denn _irgendwo_ mußt Du diesen Check ja sowieso durchführen, auch
bei statischen Buffern.
In schönem objektverachtenden C sieht das so aus, daß Du halt noch
eine Variable mit der Länge des Buffers hast und den Pointer mit
der anstatt mit sizeof buffer oder einer Präprozessor-Konstante
vergleichst. Natürlich führt man das nur für die Buffer durch, bei
denen es konkret Sinn macht.
> gelegentlich ein SIGSEGV und falls ich tausende dieser Zugriff
> hintereinander mache, sind das ziemlich viele Vergleiche, von denen
> die meisten vollkommen sinnlos sind. Wenn man sich mal anschaut, was
> für einen Müll bspw gcc produziert, ist die Vermutung gerechtfertigt,
> daß irgendeine meiner Variablen todsicher trotz eines freien Registers
> auf dem Stack enden wird, das bläht die Dinge dann noch weiter auf.
> Natürlich gibt das für den Einzelfall keine meßbaren Unterschiede,
> aber falls das Programm sechs Monate durchläuft, dürfte sich da
> einiges an CPU-Zeit aufsummieren.
Der Grund, warum man in altem Code statische Buffer verwendet hat,
besteht aber nicht darin, daß man nicht auf die Buffersize checken
mußte. Im Gegenteil, solche Checks finden sich in den besseren
Teilen etwa des Ancient Unix-Codes zuhauf. Der Grund liegt darin,
daß malloc() usw. in den siebziger Jahren echte Performancekiller
waren und der Platz so knapp war, daß schon die Verwaltungsdaten
für malloc() ein einzusparendes Gut waren. Unter der Bedingung,
daß ich eh nur 64 kB abzüglich Codesize für Daten und Stack habe,
wie sie im Unix Mitte der siebziger Jahre galt, würde ich mir das
mit dem malloc() auch noch mal überlegen und sehen, ob ich das
nicht mit geschickt dimensionierten statischen Buffern besser
machen kann. Nur programmiere ich halt nicht mehr für 16-Bit-
Maschinen ohne virtual memory - und Du wohl auch nicht - und
deshalb ist diese Überlegung total obsolet.
Ich will gar nicht bestreiten, daß man Stringklassen so bloatig
implementieren kann, daß die Performance massiv darunter leidet,
aber das ist dann ein spezifisches Problem der Stringklasse und
keines der dynamischen Reallokation von Speicher für Strings.
Gunnar
Gunnar Ritter
> Vorab: Entweder, ich verstehe überhaupt nicht, wovon Du redest,
> oder wir reden beide total aneinander vorbei.
Ich hatte dich so verstanden, daß Du behauptet hattest, daß
dynamische (Re-)Allokation unweigerlich mehr Bloat erzeugt
als statische Buffer. Ich entgegne, daß das nicht stimmt.
Ich habe in letzterer Zeit aus mehreren älteren Programmen
statische Buffer eliminiert, und sie sind alle nur um wenige
kB Code größer und nicht nachvollziehbar langsamer geworden,
verbrauchen aber erheblich weniger Speicher für Daten.
>> Das muß man nicht tun. Man kann auch Pointer mit einem Maximum
>> vergleichen. Und wenn es nur wenige Pointer sind, kann man die
>> nach dem realloc() mühelos neu setzen. BTDT.
> if (!remain) { \
#define check(ptr, buf, len) if (&ptr[1] >= &buf[len]) { \
size_t ppos = ptr - buf; \
buf = realloc(buf, len += 32); \
ptr = &buf[ppos]; \
}
anstatt von Code wie
char *bufend = &buf[sizeof buf];
...
if (&ptr[1] >= bufend)
error(nomem);
Da Du den ersten Check wg. Vermeidung von Buffer Overflows sowieso
irgendwo machen mußt, besteht der ganze Mehraufwand in den drei
Zeilen darunter. Die sparen ein Vielfaches ihrer Größe an Speicher
in schreibbaren Datenpages wieder ein.
> Das Problem, daß viele Leute bei Zeigern sehen, ist ja, das die
> 'unbound' sind, dh es gibt keine Möglichkeit, dem Zeiger anzusehen, ob
> *(p += 2) jetzt einen segfault oder sonstwas ergibt.
Ah, und bei p[i += 2] («array-indices») sieht man das eher, ja?
> Die 'objektorientierte' Methode, dieses Problem zu umgehen, bestünde jetzt
... wahrscheinlich in Bloat. Das könnte an der Objektorientierung
liegen, aber es liegt mit Sicherheit nicht daran, daß Du mit einem
kleinen Buffer anfängst, seine Länge checkst und ggf. reallozierst.
Denn _irgendwo_ mußt Du diesen Check ja sowieso durchführen, auch
bei statischen Buffern.
In schönem objektverachtendem C sieht das so aus, daß Du halt noch
eine Variable mit der Länge des Buffers hast und den Pointer mit
der anstatt mit sizeof buffer oder einer Präprozessor-Konstante
vergleichst. Natürlich führt man das nur für die Buffer durch, bei
denen es konkret Sinn macht.
> gelegentlich ein SIGSEGV und falls ich tausende dieser Zugriff
> hintereinander mache, sind das ziemlich viele Vergleiche, von denen
> die meisten vollkommen sinnlos sind. Wenn man sich mal anschaut, was
> für einen Müll bspw gcc produziert, ist die Vermutung gerechtfertigt,
> daß irgendeine meiner Variablen todsicher trotz eines freien Registers
> auf dem Stack enden wird, das bläht die Dinge dann noch weiter auf.
> Natürlich gibt das für den Einzelfall keine meßbaren Unterschiede,
> aber falls das Programm sechs Monate durchläuft, dürfte sich da
> einiges an CPU-Zeit aufsummieren.
Der Grund, warum man in altem Code statische Buffer verwendet hat,
besteht aber nicht darin, daß man nicht auf die Buffersize checken
mußte. Im Gegenteil, solche Checks finden sich in den besseren
Teilen etwa des Ancient Unix-Codes zuhauf. Der Grund liegt darin,
daß malloc() usw. in den siebziger Jahren echte Performancekiller
waren und der Platz so knapp war, daß schon die Verwaltungsdaten
für malloc() ein einzusparendes Gut waren. Unter der Bedingung,
daß ich eh nur 64 kB abzüglich Codesize für Daten und Stack habe,
wie sie im Unix Mitte der siebziger Jahre galt, würde ich mir das
mit dem malloc() auch noch mal überlegen und sehen, ob ich das
nicht mit geschickt dimensionierten statischen Buffern besser
machen kann. Nur programmiere ich halt nicht mehr für 16-Bit-
Maschinen ohne virtual memory - und Du wohl auch nicht - und
deshalb ist diese Überlegung total obsolet.
Ich will gar nicht bestreiten, daß man Stringklassen so bloatig
implementieren kann, daß die Performance massiv darunter leidet,
aber das ist dann ein spezifisches Problem der Implementation und
Thomas Skora
> Nein. TCP/IP für alles ist genau so hirnrissig. Trotzdem wird das
> überall versucht. Der Grund ist ganz einfach: Je mehr
> Formate/Protokolle, desto mehr Aufwand für die Implementierung.
Der Hauptgrund für die bevorzugte Benutzung vom
TCP/IP dürfte sein, daß wir heutzutage eine fertige
Infrastruktur(Internet, um konkret zu werden) für die Datenübertragung
besitzen, die eben auf diese Protokolle aufbaut. Keiner würde auf die
total hirnverbrannte Idee kommen ein neues Netz mit diesen Ausmaßen zu
bauen, nur weil er meint irgendeine tolle Anwendung erfunden zu
haben. Zwar ist TCP/IP(und UDP gibts ja auch noch) für viele Anwendung
noch zu redundant, der Vorteil auf ein fertiges Netz zurückgreifen zu
können ist da meistens wichtiger. Du vergißt außerdem, daß die
Protokolle über TCP/IP sehr wohl unabhängig voneinander sind und auch
proprietär sein können. So wird es dann wohl auch bei XML sein. Keiner
zwingt die Programmierer ihre DTDs an irgendwelche (semantischen)
Standards auszurichten.
Thomas
Uwe Ohse
>Da ist es doch billiger 2 fähige Entwickler anzustellen, die dann
>effiziente Programme schreiben, so dass die Hardware auch in 5 Jahren
Du hast leider keine Ahnung.
Zwei fähige Programmierer können gegen die Tendenz, das Feature of the
month haben zu müssen, sehr wenig ausrichten.
>Du hast es schlicht nicht verstanden. Du laberst rum. Bitte informiere
>dich! Es gibt (ausführliche) Begründungen für die Protokolle, die
>i.d.R. sogar wissenschaftlich belegt sind -- z.T. stehen die sogar in
>den RFCs direkt drin.
Könntest Du mir mal eine wissenschaftliche Begründung für RFC 821 und
822 (oder 2821 und 2822) zeigen?
Außer der historischen Erklärung, "Die Verursacher erkannten, daß sie beim
Nachrichtenformat überkomplizierten Mist gebaut haben, waren aber nicht
in der Lage, sich und Anderen das einzugestehen, und versuchten den
Schaden dadurch wieder gut zu machen, SMTP viel zu einfach zu machen.
Unter diesen Charakterdefiziten leiden wir nicht heute, sie haben uns
circa N*10^9 Spammails und unzählige verlorene Nachrichten sowie
unvorstellbare viele Terabytes an Workaroundkosten gebracht.", bitte.
>Lesen bildet!
Das stimmt. Jedes mal, wenn ich 822/2822 lese, bildet sich in mir eine
Abneigung dagegen.
>> Bufferoverflows existieren überhaupt erst, weil einige Programmierer
>> das nicht gebacken bekommen.
>
>Richtig.
Falsch.
Bufferoverflows existieren primär durch den das Gehirn nicht anstrengenden
Gebrauch von Programmiersprachen und deren Libraries, was leider auch genau
so gelehrt wird, sowie durch kranke Libraries, die unsicher konzipiert
und/oder so überladen sind, daß sie niemand mehr kennt (der geneigte Leser
möge sich überlegen, wieviele Prozent der Standardlibrary seiner gewählten
Sprache er kennt, und wie oft er demnach vorhandene Routinen ad-hoc
nachempfindet).
Die Tendenz, erworbenes Knowhow nach kurzer Zeit zugunsten der nächsten
Silver Bullet Of The Year wegzuwerfen, hat natürlich den Effekt, daß man
nirgendwo mehr als ein Halbwissen hat.
Die Tatsachen, daß jeder Idiot glaubt, er könne programmieren, und daß
kaum noch Qualitätskontrolle gemacht wird, tun ihr Übriges, sind aber
eher sekundär. Im Normalfall bekäme man selbst Idioten mit einer
halbwegs brauchbaren Ausbildung und sinnvollen Werkzeugen dahin,
nicht mehr gemeingefährlich zu sein.
>> Dem kann man nur mit neuen Programmierern (Genforschung?) oder neuen
>> Programmiersprachen begegnen.
Was natürlich Unsinn ist. Ausbildung heißt das Zauberwort.
Bufferoverflows sind ein Problem - unter vielen.
Man verbietet Nägel nicht, nur weil manche Leute sich mit dem Hammer
den Daumen blau hauen.
>Datenbanken -- dort hatte man das Thema semistrukturierte Datenformate
>(genau das ist XML) nämlich schon vor ca. 30-40 Jahren
>durchgekaut. Das ist (außer in wenigen Sonderfällen) obsolet.
ich wünschte, Du wüßtest, worüber Du sprichst.
Gruß, Uwe
Stefan Nobis
> >Datenbanken -- dort hatte man das Thema semistrukturierte Datenformate
> >(genau das ist XML) nämlich schon vor ca. 30-40 Jahren
> >durchgekaut. Das ist (außer in wenigen Sonderfällen) obsolet.
>
> ich wünschte, Du wüßtest, worüber Du sprichst.
Könntest du das näher erläutern?
Mein Kommentar bezog sich auf die Aussage, dass XML doch ein
Fortschritt sei, da man "komplexe Strukturen" nicht mehr platt klopfen
müsse. Und das richt sehr nach DB-Bereich und in dieser Hinsicht ist
XML ganz sicher kein Fortschritt (nach dem Motto, weg mit Oracle, mit
XML geht das alles viel besser).
Und semistrukturierte Datenformate sind sicherlich schon 30-40 Jahre
alt (insofern ist XML auch nichts wirklich grundlegend Neues).
Was also meinst du?
--
Stefan.
Rainer Weikusat
> u...@ohse.de (Uwe Ohse) writes:
>
> > >Datenbanken -- dort hatte man das Thema semistrukturierte Datenformate
> > >(genau das ist XML) nämlich schon vor ca. 30-40 Jahren
> > >durchgekaut. Das ist (außer in wenigen Sonderfällen) obsolet.
> >
> > ich wünschte, Du wüßtest, worüber Du sprichst.
>
> Fortschritt sei, da man "komplexe Strukturen" nicht mehr platt klopfen
> müsse.
Jede Form textueller Repräsentation bedeutet auch Serialisierung. Weil
es sich mittlerweile herumgesprochen hat, das sowas 'wirklich
gerbraucht wird' haben die Leute, die auch sonst ständig
'Programmierprobleme' allgemein lösen (as oposed to 'real world
problem') mittlerweile 'ein universelles textuelles
Serialisierungsformat' entwickelt.
> Und semistrukturierte Datenformate
Falls ich da mal eine Holzhammerdefinition versuchen darf: SDU/PDU
sind so austariert, daß sowohl Menschen als auch Computer wirklich
Mühe haben, 'den Sinn dahinter zu erkennen' ('having trouble to make
sense of sth.').
Rainer Weikusat
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
>
> > Vorab: Entweder, ich verstehe überhaupt nicht, wovon Du redest,
> > oder wir reden beide total aneinander vorbei.
>
> Ich hatte dich so verstanden, daß Du behauptet hattest, daß
> dynamische (Re-)Allokation unweigerlich mehr Bloat erzeugt
> als statische Buffer.
Also letzteres.
'Buffer overflows' sind natürlich eine tolle Sache (mainstream press
coverage!), aber nur ein (einfacher) Spezialfall eines anderen
Fehlers, nämlich 'out of bounds'-Zugriffe. Falls eine virtuelle
Maschine mich dafür 'beschützen' möchte, 'daß ein Puffer überläuft'
bedeutet das 'eigentlich', sie verhindert, daß ich auf
Speicherbereiche anders zugreife, als ich es vorher mit ihr vereinbart
hatte. Daraus resultiert ein garstiges Problem: Entweder ich überprüfe
vor jedem Zugriff, ob er im genannten Rahmen legal ist, oder das
dahinterliegende Programm beweist sich auf einen geeignete Art selber,
daß diese Überprüfung deswegen nicht notwendig ist, weil der Code die
Invariante nicht verletzen kann. Damit öffnet man die Tür zu einem
langen, dunklen Korridor, wo irgendwo am anderen Ende das Halteproblem
steht und einem fröhlich zuwinkt.
[...]
> buf = realloc(buf, len += 32); \
Es ist vermutlich günstiger, den Puffer in Abhängigkeit seiner
momentanen Größe zu erweitern, vor allem für 'Zeilen' > 100
Zeichen. Im 'worst case' kopiert jedes realloc und dadurch bekommt man
ein exponentielles Laufzeitverhalten. Falls man knapp an Speicher ist,
kann man den Puffer im nachhinein verkleinern. Andernfalls könnte man
ihn evtl weiterverwenden (ein paar Spielzeugmessungen suggerieren
len += len/3 oder größer, je nachdem, wo man sparen möchte).
> > Das Problem, daß viele Leute bei Zeigern sehen, ist ja, das die
> > 'unbound' sind, dh es gibt keine Möglichkeit, dem Zeiger anzusehen, ob
> > *(p += 2) jetzt einen segfault oder sonstwas ergibt.
>
> Ah, und bei p[i += 2] («array-indices») sieht man das eher, ja?
p[] könnte 'T &operator [](size_t ndx)' sein.
Gunnar Ritter
> Gunnar Ritter <g...@bigfoot.de> writes:
>> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
>> > Vorab: Entweder, ich verstehe überhaupt nicht, wovon Du redest,
>> > oder wir reden beide total aneinander vorbei.
>> Ich hatte dich so verstanden, daß Du behauptet hattest, daß
>> dynamische (Re-)Allokation unweigerlich mehr Bloat erzeugt
>> als statische Buffer.
> Also letzteres.
> 'Buffer overflows' sind natürlich eine tolle Sache (mainstream press
> coverage!), aber nur ein (einfacher) Spezialfall eines anderen
> Fehlers, nämlich 'out of bounds'-Zugriffe.
Wenn Du mir jetzt auch noch erklärst, wo das in dem Text aus
<87y99ek...@winter.inter-i.wohnheim.uni-mainz.de> steht,
auf den ich mich bezogen hatte, hast Du gewonnen.
> Falls eine virtuelle Maschine mich dafür 'beschützen' möchte,
> 'daß ein Puffer überläuft' bedeutet das 'eigentlich', sie
> verhindert, daß ich auf Speicherbereiche anders zugreife, als
> ich es vorher mit ihr vereinbart hatte.
Nein. Es bedeutet nur, daß man sich gegen einen besonders häufigen
Spezialfall absichern möchte.
Nur weil Du an Treppen ein Geländer baust, um zu vermeiden, daß
Leute versehentlich an der Seite runterfallen, mußt Du doch nicht
automatisch dafür sorgen wollen, daß sie nicht volltrunken über
die Stufen stolpern können.
> Daraus resultiert ein garstiges Problem: Entweder ich überprüfe
> vor jedem Zugriff, ob er im genannten Rahmen legal ist, oder das
> dahinterliegende Programm beweist sich auf einen geeignete Art selber,
> daß diese Überprüfung deswegen nicht notwendig ist, weil der Code die
> Invariante nicht verletzen kann.
Es ist doch jedem hier, der auch nur ein wenig von der Sache
versteht, klar, daß das in C++ nicht einmal versucht wird.
Wieso spricht das jetzt dagegen, daß man den Speicher für
Eingabedaten so alloziert, daß man _an_dieser_Stelle_ weder
arbiträre Limits einbaut noch buffer overflows fürchten muß?
>> buf = realloc(buf, len += 32); \
> Es ist vermutlich günstiger, den Puffer in Abhängigkeit seiner
> momentanen Größe zu erweitern, vor allem für 'Zeilen' > 100
> Zeichen.
Der Code da oben wurde für den Parser einer sed-Implementation
geschrieben, konkret für einen Buffer, der den Substitution-Teil
von s/foo/bar/ aufnehmen soll. Jede Überlegung zur Performance
scheint mir hier eine Zeitverschwendung zu sein, die das Programm
in der summierten Laufzeit all seiner Instanzen nie wieder aufholen
kann.
> Im 'worst case' kopiert jedes realloc und dadurch bekommt man
> ein exponentielles Laufzeitverhalten. Falls man knapp an Speicher ist,
> kann man den Puffer im nachhinein verkleinern. Andernfalls könnte man
> ihn evtl weiterverwenden (ein paar Spielzeugmessungen suggerieren
> len += len/3 oder größer, je nachdem, wo man sparen möchte).
Klar, _so_ kann man natürlich prima Bloat einführen, indem man
an Stellen auf Performance optimiert, an denen das genau nichts
bringt.
Gunnar
Rainer Weikusat
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
> > 'Buffer overflows' sind natürlich eine tolle Sache (mainstream press
> > coverage!), aber nur ein (einfacher) Spezialfall eines anderen
> > Fehlers, nämlich 'out of bounds'-Zugriffe.
>
> Wenn Du mir jetzt auch noch erklärst, wo das in dem Text aus
> <87y99ek...@winter.inter-i.wohnheim.uni-mainz.de> steht,
Eine innere Schleife, die char-weise Daten über Zeiger
kopiert, wird [...], wenn man [...] array-indices verwendet
und die [...] bei jedem Zugriff [...] mit einem [...]
Maxmialwert vergleicht.
[bounds checking]
> Nur weil Du an Treppen ein Geländer baust, um zu vermeiden, daß
> Leute versehentlich an der Seite runterfallen, mußt Du doch nicht
> automatisch dafür sorgen wollen, daß sie nicht volltrunken über
> die Stufen stolpern können.
Die konventionelle Theorie besagt, daß der Programmierer zu dämlich
ist, um das zu tun und deswegen braucht es 'Stringklassen' etc pp, die
dafür sorgen (cf Kristian). Ich hatte nicht behauptet, daß ich das für
sinnvoll halte. Im Gegenteil.
> Wieso spricht das jetzt dagegen, daß man den Speicher für
> Eingabedaten so alloziert, daß man _an_dieser_Stelle_ weder
> arbiträre Limits einbaut noch buffer overflows fürchten muß?
Fällt Dir etwas ein? Mir nicht.
> >> buf = realloc(buf, len += 32); \
[...]
> (ein paar Spielzeugmessungen suggerieren
> > len += len/3 oder größer, je nachdem, wo man sparen möchte).
>
> Klar, _so_ kann man natürlich prima Bloat einführen, indem man
> an Stellen auf Performance optimiert, an denen das genau nichts
> bringt.
Falls das irgendwen interessiert:
<URL:http://www.wohnheim.uni-mainz.de/~rw/re-alloc>
Eine 'professionielle' Lösung würde vermutlich nach Maßgabe
irgendeiner Heuristik Algorithmen wechseln, wozu Statistiken über die
Länge von Eingabezeilen geführt werden müßten, was wiederum ... und
das wäre dann 'bloatig'.
Gunnar Ritter
> Gunnar Ritter <g...@bigfoot.de> writes:
>> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
>> > 'Buffer overflows' sind natürlich eine tolle Sache (mainstream press
>> > coverage!), aber nur ein (einfacher) Spezialfall eines anderen
>> > Fehlers, nämlich 'out of bounds'-Zugriffe.
>> Wenn Du mir jetzt auch noch erklärst, wo das in dem Text aus
>> <87y99ek...@winter.inter-i.wohnheim.uni-mainz.de> steht,
> Eine innere Schleife, die char-weise Daten über Zeiger
> kopiert, wird [...], wenn man [...] array-indices verwendet
> und die [...] bei jedem Zugriff [...] mit einem [...]
> Maxmialwert vergleicht.
> [bounds checking]
Genau. Da hast Du den Spezialfall beschrieben, den ich kommentiert
hatte. Daß die Verallgemeinerung sinnlos wird, ist keine Aussage
über den Spezialfall.
>> (ein paar Spielzeugmessungen suggerieren
>> > len += len/3 oder größer, je nachdem, wo man sparen möchte).
>> Klar, _so_ kann man natürlich prima Bloat einführen, indem man
>> an Stellen auf Performance optimiert, an denen das genau nichts
>> bringt.
> Falls das irgendwen interessiert:
> <URL:http://www.wohnheim.uni-mainz.de/~rw/re-alloc>
Ich meinte die Performance im Kontext des Programmes, Du Witzbold.
Natürlich ist das langsamer. Nur ist das an vielen Stellen - etwa
in Parsern - völlig irrelevant. Das real existierende sed-Programm
möchte ich sehen, bei dem Du da irgendeinen Performanceunterschied
messen kannst.
Gunnar
Felix von Leitner
> >>Buffer Overflows sind Probleme von veralteten Programmiersprachen und kein
> >>Problem des XML-Syntax.
> >Das ist ja nun schon eine gewagte These. Ich würde da schon fast eher
> >zu "Buffer Overflows sind Probleme von unfähigen Programmierern"
> >tendieren.
> Dazu hab ich in einem anderen Artikel geschrieben. Kurz: Wenn der Berg
> halt nicht zum Propheten will ... oder so.
Ihr beiden seid ja echt ein tolles Duo.
NATÜRLICH sind die Programmierer schuld, wenn ihr Code stinkt!
Aber was nützt dir das, wenn deine Firma ein paar Wochen Umsatzausfall
hat, weil anderer Leute XML-Code einen Buffer Overflow hat und derjenige
dann halt insolvent oder ins Ausland gegangen ist?
Eben. Brauchbare Standards sind so, daß man auch als inkompetenter
Flachwichser möglichst wenig falsch machen kann. Schau dir mal die
diversen Stecker-Designs im Rechner an: man kann sie nicht (bzw. nur mit
viel Gewalt) falsch herum aufstecken. Das sind (an der Stelle) gute
Standards. Und genau so hätte man auch XML machen können und müssen.
Hat man aber nicht. Deshalb ist XML Scheiße.
> Scherz beiseite: Die Programme werden immer aufwendiger und die
> Programmierer nicht klüger.
Programmierer programmieren nicht absichtlich schlechten Code.
Gib ihnen ein API, mit dem es schwieriger ist, unsicheren oder langsamen
Code zu schreiben, als normalen und sicheren Code, und die dummen
Programmierer werden plötzlich anfangen, normalen und sicheren Code zu
erzeugen.
> Also müssen die Programmiersprachen diese Schere wieder einfangen.
> Anders kann das nicht funktionieren.
So funktioniert es auch nicht. Es gibt hunderte von mehr oder weniger
obskuren Müll-Sprachen, und keine von ihnen ist auch nur annähernd so
verbreitet wie C.
> Deshalb ist man ja schon von Assembler auf C umgestiegen.
Gibt es eigentlich auch ein Thema, mit dem du dich auskennst?
> Heute steigt man halt von C auf Java um (C# eher von Turbo-Pascale).
Nein.
> C++ ist leider wegen totaler Überfrachtung des Sprachkonzeptes und
> schlechter STL-Klassen gescheitert.
Soso, "schlechte STL-Klassen". ROTFL.
Du bist wirklich so inkompetent, oder?
> Also gravierende Fehler hab ich z.B. bei Xerxes noch nicht entdeckt.
> Ansonsten werden die halt irgendwann ausgemerzt sein. Mit dem gleichen
> Argument könnte ich mich auch gegen ein UNIX wehren. Ein DOS passt in
> gerade mal 100k (geschätzt). Das ist viel Kleiner, weniger komplex und
> damit auch Fehleruranfälliger. Warum also ein UNIX?
Wenn du unter DOS den Netzwerkstack, den Speicherschutz, den Buffer
Cache und das Multitasking nachträgst, bist du bei der Größe von Unix.
> >Die Semantik von XML-Dateien, die der Parser validieren soll, ist aber
> >beurteilbar: Die ist recht komplex. Das führt überproportional schnell
> >zu Fehlern.
> Ich bin erst mal von der Semantik der Daten ausgegangen. Die Semantik in
> XML kann ich nicht so recht sehen. Ich sehe da eher einen Syntax.
Wieso diskutierst du eigentlich, wenn du so offenkundig keine Ahnung hast?
> >Da steht dann plötzlich kein 2GH Pentium, 4GB RAM mit 2 TB
> >RAID-Array, da gibt's dann plötzlich nur ein Pentium-100, 64MB RAM und
> >die Platte hat auch nur noch 20MB frei. Und mit diesen Eckwerten kann
> >ein guter Programmierer wirklich sehr, sehr viel machen.
> Natürlich kann man damit etwas machen. Aber eben halt keine moderne
> Anwendungen.
Doch. Ich habe über Jahre einen Mail- und Webserver auf einem i386sx-25
mit 8 MB RAM betrieben. 4 hätten auch gereicht.
> Aber für eine Firma, die Geld verdienen möchte, ist ein alter Rechner zu
> teuer.
Nein. Im Gegenteil: kostenlos. Steht noch rum.
Und als Proxy/DHCP/DNS/Router eignet sich sowas wunderbar.
> Dort muss halt zu viel Entwicklungsarbeit in Detailfragen stecken, die
> heute einfach überflüssig sind.
Unsinn.
Felix von Leitner
> >gepostet. Troll, elender!
> Sorry, wenn ich noch ein paar alte Postingregeln im Usenet beherrsche:
Ach ja? Du beherrschst ja nicht mal anständiges Quoting mit deiner
Newsreader-Simulation und deine Editor-Simulation erzeugt Leerzeichen am
Zeilenende. Lange hat uns hier nicht mehr so eine Lachnummer wie du
heimgesucht.
> Crossposting immer mit Followup-To in *eine* Gruppe.
Du tust ja geradezu so, als habe _ich_ angefangen, nach dcoud zu
crossposten! Das kannst du ja gleich noch mal nachprüfen und dich dann
mit eingezogenem Schwanz zurückziehen.
> >>>> Was soll denn die Länge sein?
> >>>Platzbedarf.
> >>Das braucht man nur bei untauglichen Programmiersprachen.
> >Ah, Platz brauchen nur untaugliche Programmiersprachen.
> [...]
> Nein, aber sie berechnen den Speicherbedarf selbstständig und beseitigen
> damit auch die Bufferoverflows.
Merkst du eigentlich noch die Widersprüche, in denen du dich hier
verfängst?
Abgesehen davon, daß du mangels Erfahrung nicht erkennst, daß das eine
Frage der Laufzeitumgebung und nicht der Programmiersprache ist.
> >Mann, du bist ja so eine Lachnummer, da gibt es echt keine Worte mehr für.
> Tja, du scheinst keine andere Programmiersprache als C oder Assembler zu
> kennen. Würde ich eher als Bildungslücke bezeichnen.
ROTFL
> >>Der Platzbedarf ist redundant.
> >EBEN. Das ist genau die Beschwerde. XML ist in unglaublichem Maße
> >redundant, aber nicht so, daß man damit Fehlerkorrektur oder auch nur
> >-Erkennung betreiben könnte.
> Es hindert dich keiner die Länge als Attribut in den Tag zu schreiben.
Merkbefreiung jetzt!1!!
> >>Ein Text brauch genau so viel Platz, wie er lang ist.
> >Plus Markup, ja.
> >
> >Oder willst du sagen, daß du einen strukturierten Datenstrom mit 10k
> >Nutzdaten verteilt auf 100 Records mit je 7 Feldern mit (oder ohne) XML
> >und ohne Kompression der Nutzdaten in 10k abbilden kannst? Das will ich
> >sehen. Das ist geradezu nobelpreisverdächtig! Das schafft nicht mal
> >ASN.1 oder CSV!
> Das hat doch überhaupt keiner behauptet.
Doch. Du. Und du Knalltüte hast es sogar auch noch mitgequotet!
> >>Bullshit. Die Frage wurde nicht beantwortet. Sich auf die Längenangeben
> >>von externen Daten zu verlassen ist unsinnig.
> >Man sieht, daß du noch nie einen Parser geschrieben hast.
> >Du betreibst hier gerade das Usenet-Äquivalent vom sich öffentlich in
> >die Hose pinkeln.
> >
> >Man liest die Länge, alloziert so viel Speicher,
> ... und das braucht kein Mensch mehr, weil Programme heute eher in C++
> und Java geschrieben werden ...
Selbstverständlich braucht man das auch in C++ und Java noch. Es ist
_immer_ effizienter, wenn man vorher sagen kann, wie viel Platz man
brauchen wird. Wenn deine Java- oder C++-API zu scheiße ist, um das
anzubieten, dann ist das ein weiteres Argument gegen deine API.
> >und wenn dann mehr
> >kommt, bricht man komplett ab. Das ist schon mal einfach so eine
> >Größenordnung effizienter als typische realloc-Implementationen.
> Toll. Das kostet aber an anderer Stelle einen größeren Aufwand,
Nein.
> Du scheintst eine gewisse Entwicklung in der EDV nicht mitbekommen zu haben.
Die, daß zunehmend merkbefreite Vollidioten im Usenet rumposen und von
neuen Paradigmen, Java und C# faseln? So Leute wie du? Doch, das ist
mir schmerzhaft bewußt.
> >Die Rationale IST die Begründung! Gibt es eigentlich _irgendein_
> >Detail dieser Diskussion, mit dem du dich auch nur in Ansätzen
> >vertraut bist? Das ist ja wirklich grotesk, was du hier bietest.
> Grotesk nenne ich eher deine NULL-Aussagen. Deine Behauptungen wirst du
> ja wohl etwas genauer begründen können, oder?
Das hat echt keinen Sinn mit dir.
Lies obigen Absatz nochmal. Und nochmal. Und nochmal. Und nochmal.
Bis du verstehst, was er dir zu sagen versucht.
Und dann erschießt du dich am besten, weil dir auffällt, wie sehr du
dich hier selbst zerlegt hast.
> >Zeige ein einziges Problem, das man nur mit XML oder nur mit XSLT lösen
> >kann, und das nicht "Kompatibilität mit XML" oder "Kompatibilität mit
> >XSTL" heißt oder beinhaltet
> >
> >Gibt es nicht? Genau meine Rede.
> Da kommt dann schon etwas mehr. Das ist dann aber tatsächlich etwas
> "Grotesk". Mit der Argumentation sind wird bald wieder in der
> EDV-Steinzeit bei den Lochkarten ...
Und _wieder_ hast du nichts zu sagen! Nimmst du bitte mal deinen Finger
aus deinem Arsch? Das ist ja unglaublich, was du hier bietest!
Das war eine klare Frage. Bringe eine Antwort oder halte die Schnauze
und akzeptieren, daß deine Aussage gerade widerlegt wurde.
> >Vielleicht willst du jetzt kurz dazu Stellung nehmen?
> >Tu es für die zukünftigen Generationen, denn die aktuellen haben dich
> >schon alle im Killfile.
> Damit sind die Allgemeinplätze immer noch offen. Vielleicht füllst du ja
> lieber dein Killfile ...
Warum nimmst du nicht einfach Stellung zu der ASN.1-Frage?
Das Muster ist frappierend. Du behauptest irgendeinen himmelschreienden
Bullshit, jemand fragt nach einer Begründung oder auch nur einem einzige
Beispiel, du kannst keines bringen und haust dann hier irgendwelche
Blubber-Phrasen raus. Wem soll das was nützen?
> Relevant ist nämlich nur, dass *ich* den Parser nicht schreiben muss,
> wenn ich XML verwenden will.
Ein Glück! Wenn du so gut programmierst wie du argumentierst, dann
gnade uns Gott, falls doch mal eines deiner Werke deinen Rechner
verlassen sollte.
> >>Wie aufwendig eine Semantik ist, kann man außerdem eh nicht allgemein
> >>beantworten.
[Widerlegung]
> Siehst du. Wenn du nur 3 mm nachgedacht hättest, dann hättest du darauf
> kommen können, dass es mir um den Aufwand der Implementierung zum
> Auswerten der Semantik ging.
Aha, deine Aussage ist also, daß die Komplexität eines validierenden
XML-Parsers nicht abschätzbar ist?
Willst du deine Drogen alleine rauchen oder gibst du uns was davon ab?
> >>Man kann nicht um jedes Byte jammern, was man weniger produzieren
> >>könnte.
> >Aha, wie Computer funktionieren, was eine Speicherhierarchie ist, was
> >Caches sind, das weißt du auch alles nicht, ja?
> >
> >Du bist ja wirklich außerordentlich wohlqualifiziert, um dich hier über
> >Programmier-Fragen zu äußern.
> Also: Doch über die Bytes jammern.
Du hast konkrete Stichworte bekommen, mit denen du dich hättest
informieren können. Wieso hast du es nicht getan?
> Auch FTP und SMTP könnte man noch kürzen. Wozu da lange Labertexte
> hinter den Meldungen?
Was für lange Labertexte? Du meinst die Fehlermeldungen?
Klar, da muß man unbedingt sparen!1!! Zukünftige Generationen werden
uns dankbar sein!
> Aber da haben alle (mit Recht) 'drauf geschissen. Bei XML wird das genau
> so sein.
Nein. XML wird entweder in der Bedeutungslosigkeit vergammeln oder von
etwas noch groteskerem abgelöst werden. Ich tippe auf letzteres.
Solange Microsoft 50 Milliarden Dollar Kohle auf der hohen Kante hat,
werden sie uns weiter mit SOAP und ein paar Bloat-Extensions zu SOAP
beglücken.
Felix von Leitner
> Die STL-'Feldersatz'-Typen sind für reale Programmierung (also nicht
> nur als framework jockey) nicht geeignet, weil sie keinerlei Garantien
> über das Speicherlayout machen, dh per se mit nichts interagieren
> können.
man Iterator
Holger Schauer
> Stefan Nobis <ste...@snobis.de> wrote:
> > Nun mach aber mal halblang. Für ihren Bereich, nämlich Textmarkup,
> > klassisches Beispiel Buch, gibt es ja nun wohl keine ernsthafte
> > Alternative.
Das ist in dieser Allgemeinheit, wie Gunnar ja auch richtig ausführt,
sicher Quatsch.
> Wenn man ein Buch produzieren will, will man kein generisches
> Markup. Wer gute Bücher herstellt weiß, daß ein Leser mit
> mehr als vier Schrifttypen überfordert ist. Es ist also gerade
> nötig, da ein visuelles Markup einzuführen. Deshalb macht man
> gute Bücher mit qualifizierten, bewährten Satzprogrammen und
> nicht mit XML.
Du hast recht, solange Du exakt ein Ausgabemedium anvisierst. Das
endet aber genau in dem Augenblick, wo man Inhalt und Design trennen
will, bspw. weil man exakt unterschiedliche Ausgabeziele anvisiert
(und das koennen durchaus unterschiedliche Print-Medien sein). In
genau solchen Fällen macht die Verwendung von SGML/XML Sinn, jedoch
auch wieder nur unter der Massgabe, dass man da dann nicht
irgendwelchen visuellen Murks in die DTDs reinbastelt (von Krankheiten
wie PIs mal ganz zu schweigen).
Das man am Ende doch wieder bei einem visuellen Format landet, mit dem
sich der Setzer rumschlägt, ist eine andere Sache.
> Die Aufgabe eines Setzers besteht gerade darin,
> eine überorganisierte generische Markup-Wichse in etwas Lesbares
> zu verwandeln. Ein Autor, der sich dieser Tatsache bewußt ist,
> kann das auch gleich selbst machen.
Klar, deswegen geben die meisten Autoren in der realen Welt ihren Senf
ja auch in Word und einem anderem Binärmüll-Format ab.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"I don't know what to say, you don't care anyway."
-- New Order, "Crystal"
Felix von Leitner
> versuchen, meine Fehler zu verbessern.
Du würdest staunen.
int foo(char* x) {
int i;
for (i=0; ; ++i)
if (x[i]==0) break;
return i;
}
Und gcc macht daraus:
foo:
movl 4(%esp),%edx
xorl %eax,%eax
cmpb $0,(%edx)
je .L4
.p2align 4,,7
L5:
incl %eax
cmpb $0,(%eax,%edx)
jne .L5
L4:
ret
Die Alternative:
int foo(char* x) {
char* y=x;
while (*x) ++x;
return x-y;
}
Und gcc macht daraus:
.type foo,@function
foo:
movl 4(%esp),%eax
movl %eax,%edx
cmpb $0,(%eax)
je .L4
.p2align 4,,7
L5:
incl %eax
cmpb $0,(%eax)
jne .L5
L4:
subl %edx,%eax
ret
> Eine innere Schleife, die char-weise Daten über Zeiger kopiert, wird
> zu einem unerträglich bloat-monster, wenn man stattdessen
> array-indices verwendet und die auch noch bei jedem Zugriff
> sinnloserweise mit einem irgendwo gespeicherten Maxmialwert
> vergleicht.
Das kostet je nach Architektur einen oder zwei Maschinenbefehle mehr.
Bloat ist was anderes.
> Das immer wieder gerne angeführte Argument, daß die Computer ja heute
> so schnell wären, scheint mir in diesem Zusammenhang unsinnig: Was
> bringt mir ein schneller Computer, wenn dessen erhoehte Leistung dafür
> draufgeht, daß Programme mit weniger Sorgfalt entwickelt werden
> koennen?
Ein Sicherheitsnetz ist schon keine schlechte Idee. Man muß es nur
sorgfältig implementieren ;)
Felix
Rainer Weikusat
Stefans Antwort zu diesem Thema war etwas sinniger.
Rainer Weikusat
> > Ich verwende maschinennahe Sprachen gezielt deswegen, weil sie nicht
> > versuchen, meine Fehler zu verbessern.
>
> Du würdest staunen.
Versuch mal
for (;;) {
*dst = *cur++;
if (!--amount) break;
++dst;
}
vs
while (1) {
*dst = *cur++;
if (!--amount) break;
++dst;
}
'Staunen' war außerdem das falsche Verb. Beide Effekte sind im Übrigen
relativ 'neu'.
> > Eine innere Schleife, die char-weise Daten über Zeiger kopiert, wird
> > zu einem unerträglich bloat-monster, wenn man stattdessen
> > array-indices verwendet und die auch noch bei jedem Zugriff
> > sinnloserweise mit einem irgendwo gespeicherten Maxmialwert
> > vergleicht.
>
> Das kostet je nach Architektur einen oder zwei Maschinenbefehle mehr.
> Bloat ist was anderes.
... und wenn wir schon mal dabei sind, könnte man auch noch das Datum
überprüfen und den Benutzer an den Geburtstag seiner Mutter erinnern,
das kostet auch fast nichts (auf einem schnellen Rechner).
Sicher, partiell ist das eine Gespensterdebatte, weil der Unterschied
sich mittlerweile nicht mehr bemerkbar machen dürfte. Aber ich habe
auch schon Computer programmiert, wo das definitiv anders war und
könnte mich nicht daran erinnern, jemals einen praktischen Nutzen aus
einer solchen Überprüfung gezogen zu haben.
Wenn es mir nichts bringt und ich es einfach lassen kann, lasse ich
es. Das nützt mir evtl nichts, aber schaden tut es ganz sicher auch
nicht.
Friedrich Dominicus
der Messages scheinen Ihren Weg dorthin gefunden zu haben, die
Meinungen zu XML sehen dort ziemlich anders aus.
Felix von Leitner
> > > Die STL-'Feldersatz'-Typen sind für reale Programmierung (also nicht
> > > nur als framework jockey) nicht geeignet, weil sie keinerlei Garantien
> > > über das Speicherlayout machen, dh per se mit nichts interagieren
> > > können.
> > man Iterator
> Stefans Antwort zu diesem Thema war etwas sinniger.
Nein. Das ganze _Konzept_ der STL basiert auf Iteratoren als Mittel zur
Interaktion. "Mit der STL kann man nicht interagieren" ist wie "mit
einem Fahrrad kann man nicht fahren".
Daß ein STL-vector außerdem als Array gespeichert wird ist
nebensächlich. Das steht zwar nicht wörtlich im Standard, aber es folgt
ziemlich direkt aus den Laufzeitbestimmungen im Standard.
Felix
Felix von Leitner
> Versuch mal
[for (;;) vs. while (1)]
Identischer Maschinencode. Was hast du denn erwartet?
> 'Staunen' war außerdem das falsche Verb. Beide Effekte sind im Übrigen
> relativ 'neu'.
Was, daß Compiler das zusammenoptimieren?
Naja, wenn Anfang der 90er bei dir als "neu" durchgeht... vorher habe
ich nicht mit optimierenden Compilern gearbeitet, weil mein Rechner zu
langsam war, um auf Optimizer zu warten.
> > > Eine innere Schleife, die char-weise Daten über Zeiger kopiert, wird
> > > zu einem unerträglich bloat-monster, wenn man stattdessen
> > > array-indices verwendet und die auch noch bei jedem Zugriff
> > > sinnloserweise mit einem irgendwo gespeicherten Maxmialwert
> > > vergleicht.
> > Das kostet je nach Architektur einen oder zwei Maschinenbefehle mehr.
> > Bloat ist was anderes.
> ... und wenn wir schon mal dabei sind, könnte man auch noch das Datum
> überprüfen und den Benutzer an den Geburtstag seiner Mutter erinnern,
> das kostet auch fast nichts (auf einem schnellen Rechner).
Dir ist offenbar entgangen, daß der Optimizer invariante Checks aus der
Schleife rauszieht und diese Prüfung damit im Cache-Rauschen komplett
untergeht.
> Sicher, partiell ist das eine Gespensterdebatte, weil der Unterschied
> sich mittlerweile nicht mehr bemerkbar machen dürfte. Aber ich habe
> auch schon Computer programmiert, wo das definitiv anders war und
> könnte mich nicht daran erinnern, jemals einen praktischen Nutzen aus
> einer solchen Überprüfung gezogen zu haben.
Ich tu sowas gewöhnlich beim Entwickeln rein und #ifdef es dann weg,
damit ich es bei Problemen wieder anschalten kann.
Felix