Live data from Hacker News

Why are the Microsoft Office file formats so complicated? (And some workarounds)

joelonsoftware.com

11–20 of 22 posts

Re: Why are the Microsoft Office file formats so complicated? (And some workarounds)

#11
post #7
post #4

"If you simply have to produce tabular data for use in Excel, consider CSV." That's what most of us have been doing for years, simply to avoid the mess discussed in this article. After reading the article, I, for one, will keep on doing it.

I ran into a nasty bug(?) recently in the way Excel processes CSVs. I create a well formed CSV from a Java Web app which the user downloads. They open the CSV up in Excel and modify the data for an eventual upload. However, during the save process, Excel truncates trailing commas. Which causes my well formed CSV to be a poorly formed CSV during upload and parsing. Not fun.

Never knew that. Once I cut a CSV for someone else, I never wanted to see it again. Now I know why.

Re: Why are the Microsoft Office file formats so complicated? (And some workarounds)

#13
post #5

I call bullshit. A lot of his arguments perhaps make sense for early versions of Office, but for '97 and later? It didn't occur to anyone on the Word or Excel teams in 1997 that maybe interoperability would be an issue? I really enjoy Joel's blog, but sometimes I can't stand the clubbish-ness of the old-school Microsoft brigade. "We were a bunch of geniuses, doing the best we could..." Yeah, well, the software is usa…

Sure, they realized interoperability would be important. But by 1995 customers were already whining about how often the file format changed. Nobody would buy Office (n+1) if it would start writing documents in a format that Office (n) didn't understand, because interoperability means precisely that you can't get everyone to upgrade at the same time. So they did a remarkably good job of holding the file formats stable…

Interoperability does not mean forward/backward compatibility for releases of a single vendor's software.

Forward/backward compatibility does not require a lot of work or intellect, unless you're deliberately obfuscating your format.

Re: Why are the Microsoft Office file formats so complicated? (And some workarounds)

#15
Normally I agree Joel's articles, but having dealt with the new garbage that Microsoft calls a standard, Office Open XML, I can tell you that none of this applies. Yet the Open XML spec is over 6000 pages long (compared to these binary specs which are a measly 100-300 pages each).

Open XML is not designed for performance... it's XML, and today's computers are fast enough. It IS [supposed to be] designed for interoperability (somehow they managed to get ECMA to put their stamp of approval on it), but in reality it feels like it's a half-assed attempt to wrap all of Office's legacy formats in XML. For example, to import you still need WMF importing, because a lot of the graphics (including all clip art) are WMF.

Re: Why are the Microsoft Office file formats so complicated? (And some workarounds)

#16
You can't blame Microsoft for awful Office file formats. Remember, they wrote this stuff before the web came along, and before they generally started sucking really bad. It's just the accumulation of decades of feature creep, add-ons, re-dos, compatibility hacks, bug fixes, and workarounds.

Eventually, all software needs a rewrite. Not just MS's.

Re: Why are the Microsoft Office file formats so complicated? (And some workarounds)

#17
It seems to me like Joel has a rather warped view of how software should be built. He claims

It means you have to rewrite all of your date display and parsing code to handle both epochs. That would take several days to implement, I think.

That's just ridiculous. In my mind, you need a piece of code that reads the 1904 record and sets a flag in the code. Then, your date display and parsing code should all call one, or maybe two, functions which handle the conversion for you based on this flag. Thus, supporting two different epochs requires at most three components: one to read it and set a flag, one to convert a numerical argument to a date based on that flag, and one to convert a date back to a numerical argument (again, based on the flag). Should this really take "several days to implement"? It seems to me that an hour should be plenty of time.

It's going to be hard for me to continue to take him seriously if this is his view of how software should be built.

Re: Why are the Microsoft Office file formats so complicated? (And some workarounds)

#18
One option Joel doesn't mention is to use OpenOffice. It has its own object model (called UNO), which has bindings in many languages.

It's not a perfect implementation of the formats, but it's good enough for most things. And has the rather large advantage that you can run it under your favorite *nix.

Re: Why are the Microsoft Office file formats so complicated? (And some workarounds)

#19

I call bullshit. A lot of his arguments perhaps make sense for early versions of Office, but for '97 and later? It didn't occur to anyone on the Word or Excel teams in 1997 that maybe interoperability would be an issue? I really enjoy Joel's blog, but sometimes I can't stand the clubbish-ness of the old-school Microsoft brigade. "We were a bunch of geniuses, doing the best we could..." Yeah, well, the software is usa…

I agree. This is bullshit. Xerox PARC solved a superset of these compatability problems by 1985. It was called InterScript ( http://hopl.murdoch.edu.au/showlanguage.prx?exp=5455 ) and it allows editors to preserve unknown elements within compound documents. This makes downward compatability quite trivial.

Re: Why are the Microsoft Office file formats so complicated? (And some workarounds)

#20
What is the motivation for Joel Spolsky's post? Sympathy for MS Office file formats? Reads like a manifesto for never ever changing/cleaning up the file formats because it took a thousand man-years to come up with the current incarnation. He is even going so far as to defend the office file formats' complexity and resulting maintainability hell by saying that portability was not an issue fifteen+ years ago - well, it is now. His suggestions for file format conversion solutions are OK, but doesn't it occur to him, that developers don't want to be locked-in to having to shell out money for MS APIs forever? Ties in well with Bruce Schneier's latest post on vendor lock-in http://www.schneier.com/blog/archives/2008/02/lockin.html
Post reply on HN