Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"I think you will all appreciate this person's commenting style"

jwz.livejournal.com

Post reply on HN
Print view View original

51–60 of 91 posts

Re: "I think you will all appreciate this person's commenting style"

#51

Post by lmm »

TeMPOraL wrote: post #46
SideburnsOfDoom wrote: post #44

Earlier quoted context omitted.

> PSD was never intended to be a data interchange format And that's the basic design flaw - it is a data interchange format despite not being designed as one, and the terrible job that it apparently does at it. The people who wrote it didn't recognise that they were going to be filling that need. There's a lesson in there somewhere.

> There's a lessen in there somewhere. Greetings. I have arrived from the future to spare mankind more years of pain by stating it clear here that the lesson is not "serialize your data to XML".

No? It seems to be working up well enough so far for e.g. ODT, or indeed the web. A file format that might need to be read in 20 years seems like one of the few cases where the super-verbose XML style is actually appropriate.

Re: "I think you will all appreciate this person's commenting style"

#52

Post by SideburnsOfDoom »

TeMPOraL wrote: post #46
SideburnsOfDoom wrote: post #44

Earlier quoted context omitted.

> PSD was never intended to be a data interchange format And that's the basic design flaw - it is a data interchange format despite not being designed as one, and the terrible job that it apparently does at it. The people who wrote it didn't recognise that they were going to be filling that need. There's a lesson in there somewhere.

> There's a lessen in there somewhere. Greetings. I have arrived from the future to spare mankind more years of pain by stating it clear here that the lesson is not "serialize your data to XML".

Hm, interesting. Could you explain why the decision to use (zipped) XML in the current MS Office document formats was a mistake? Those document formats are huge hideous beasts, but that's due to backward compatibility with large feature sets, and I don't think that moving off XML would help.

PS: I fixed the typo in "lesson"

Re: "I think you will all appreciate this person's commenting style"

#53

Post by TeMPOraL »

lmm wrote: post #51
TeMPOraL wrote: post #46

Earlier quoted context omitted.

> There's a lessen in there somewhere. Greetings. I have arrived from the future to spare mankind more years of pain by stating it clear here that the lesson is not "serialize your data to XML".

No? It seems to be working up well enough so far for e.g. ODT, or indeed the web. A file format that might need to be read in 20 years seems like one of the few cases where the super-verbose XML style is actually appropriate.

I'm all for super-verbosity in useful information and flexible structure, but XML is also super-verbose in terms of redundant markup. Compression helps a bit, but it still costs processing power for no real reason. See the good ol' S-expressions vs. XML discussion, recently reincarnated as JSON vs. XML.

Re: "I think you will all appreciate this person's commenting style"

#54

Post by vidarh »

CoolGuySteve wrote: post #16
matt4711 wrote: post #13

Earlier quoted context omitted.

do you have a description of the ".mov tree of structs format"

Here you go: http://atomicparsley.sourceforge.net/mpeg-4files.html Nearly everything inherits from a basic struct that is 8 bytes per atom: { length of self + children, quasi-human readable 4 char code describing contents } Practically speaking, in C/C++, you can stride by length and switch() on the ftype, using it to cast the read-in data to whatever class/struct you desire. All of this while being so brutally dumb…

This is pretty much IFF: http://en.wikipedia.org/wiki/Interchange_File_Format

I suspect that's where it originated.

Re: "I think you will all appreciate this person's commenting style"

#55

Post by TeMPOraL »

SideburnsOfDoom wrote: post #52
TeMPOraL wrote: post #46

Earlier quoted context omitted.

> There's a lessen in there somewhere. Greetings. I have arrived from the future to spare mankind more years of pain by stating it clear here that the lesson is not "serialize your data to XML".

Hm, interesting. Could you explain why the decision to use (zipped) XML in the current MS Office document formats was a mistake? Those document formats are huge hideous beasts, but that's due to backward compatibility with large feature sets, and I don't think that moving off XML would help. PS: I fixed the typo in "lesson"

The deicision was a big step forward; however, moving off XML to an equivalent but less verbose (in number of meaningless bytes) format wouldn't hurt. All else being equal, it would be less electricity wasted on reading and sending things over the wire, and also more human-readable format. See also: SEXP vs. XML.

This argument applies the more, the bigger markup-to-data ratio is.

Re: "I think you will all appreciate this person's commenting style"

#56

Post by vidarh »

daeken wrote: post #34
sltkr wrote: post #33

Earlier quoted context omitted.

So basically just IFF/RIFF with fields exchanged? See: http://en.wikipedia.org/wiki/Interchange_File_Format http://en.wikipedia.org/wiki/Resource_Interchange_File_Format

The big difference between the QT Atom structure and RIFF is that RIFF is a series of independent chunks (IIRC), whereas Atoms are a big tree. Structurally nearly identical, though.

Don't know about RIFF, but IFF files are/can be a big tree - the outer chunk must be one of FORM, LIST or CAT, and many chunk types contain additional chunks, so depending on the file you might get structures of arbitrary depth.

Re: "I think you will all appreciate this person's commenting style"

#57

Post by mmariani »

simula67 wrote: post #24

Many more for your viewing pleasure : http://stackoverflow.com/questions/184618/what-is-the-best-c...

Thanks for this link! It's filled great laughs. Like this one:

  #define TRUE FALSE //Happy debugging suckers
I imagine what the guy who wrote it must've been through... :-P

PS: I wish Jeff hadn't shut down the thread.

Re: "I think you will all appreciate this person's commenting style"

#59

Post by lucian1900 »

SideburnsOfDoom wrote: post #50
yason wrote: post #37

Earlier quoted context omitted.

If a wise programmer decided he needs a serialization format, would he deliberately include in that format all the crap so vividly pointed to by the article? No. He will think of the "serialization format" as an interchange format between two different instances of his program. One process first writes the data file and another process later will read it. He also knows that sooner or later the "serialization format"…

> AFAIK, the Word .doc also started (and unfortunately continued) as basically a not-so-designed memory dump This may be true but not the whole story. It's the reason why the MS office team bit the bullet and replaced .doc with .docx about 5 years ago http://en.wikipedia.org/wiki/Office_Open_XML Docx is basically XML in a zip file. It's a beast and has lots of compromises for backward compatibility, but as a design s…

It's still worse than ODT (which itself isn't exactly pretty), for no good reason. That's sad.
Post reply on HN