[PRL] Martian Headsets

[Mitchell Wand]

On the same theme, Joel published a piece last month titled
Why are the Microsoft Office file formats so
complicated?<http://www.joelonsoftware.com/items/2008/02/19.html>in
which he talks about the backward compatibility issues there.  Fascinating
stuff.

--Mitch

> Last week, *Microsoft* published the binary file formats for Office<http://www.microsoft.com/interop/docs/OfficeBinaryFormats.mspx>.
> These formats appear to be almost completely insane...
> If you started reading these documents with the hope of spending a weekend
> writing some spiffy code that imports *Word* documents into your blog
> system, or creates Excel-formatted spreadsheets with your personal finance
> data, the complexity and length of the spec probably cured you of that
> desire pretty darn quickly. A normal programmer would conclude that Office's
> binary file formats:
>
>    - are deliberately obfuscated
>    - are the product of a demented Borg mind
>    - were created by insanely bad programmers
>    - and are impossible to read or create correctly.
>
> You'd be wrong on all four counts.
>


On Mon, Mar 17, 2008 at 11:12 PM, Dave Herman <dherman at ccs.neu.edu> wrote:

> > The robustness principle was actually the right thing,
> > but you also need a Spanky mode.
>
> I think I agree, although there are still hard questions of a) default
> behavior and b) the nature of the agreement between the
> platform/language/browser and the client/programmer/web developer.
>
> The robustness principle was a big part of the success of the
> web--anyone, no matter how sloppy, could create a web page. But it's
> impossible to support both progress in browser implementations and
> continuity of behavior; as Joel alludes, there are multiple instances
> where people have discovered ways to exploit one IE bug to circumvent
> another. Now MS has to choose between continuity and progress. From what
> I can tell, the pragmatic answer almost always seems to be: keep the
> quirky, old behavior the default, but allow people to opt into a new
> mode. It's not clear to me how many times you can get away with this
> before your code base sinks under the complexity of countless modes,
> emulated bugs, etc.
>
> So you could also try to set things up where the browser vendor makes no
> guarantees (beyond, say, a best effort) to provide continuity in
> behavior for default mode, but offers stricter modes with stricter
> guarantees. Back 8 or 9 years ago, XHTML kinda looked like it was trying
> to do that... except XHTML is a joke. (From what I hear, it's a pretty
> textbook case of the perfect being the enemy of the good.) I think one
> of the most impractical aspects of XHTML was that it was a parallel
> standard, and parallel standards just can't keep pace with the real
> standard. Especially when you're talking about big multi-party standards
> sloths (W3C) competing with the ultra-competitive market.
>
> But I think human nature is another problem with XHTML: offer the world
> a strict version and a sloppy version, and they use the sloppy one.
> Almost no one uses XHTML. And the browser vendor doesn't have the luxury
> of an explicit contract with the world: browsers are free, they have
> billions of clients, and if they don't do exactly what the clients want,
> they lose in the court of public opinion. It's like an unwritten
> contract where the client gets to dictate all the terms, except the
> service provider has to guess what they are.
>
> As for Spanky mode, this was the thing in Joel's post that made me slap
> my forehead, because it's been staring me in the face for years now. I
> never really appreciated Spanky's potential for compatibility testing. I
> hope our reference implementation of ECMAScript 4 becomes useful for
> that. Unfortunately, the Achilles heel of the Spanky approach is that it
> relies on MS being relatively faithful to the spec.
>
> As an aside, it's kind of hilarious that for years the W3C have treated
> XHTML and CSS validators ("yep-- I think that's a web page!") as somehow
> helping people create portable web apps.
>
> > One of the nice things
> > about a Spanky mode is that it reveals as much about the
> > errors made in the standard itself as in the individual
> > artifacts that attempt to conform to the standard.
>
> Indeed. In our SML implementation of ES4, we've gotten a lot of mileage
> out of using the MLton compiler as a pedantically standards-compliant
> implementation of SML. One thing I've learned from using it is that SML
> totally screwed the pooch on the definition of `withtype'. It has
> non-nesting binding semantics (let instead of let*), which pointlessly
> restricts its usefulness. I never even knew that SML/NJ violated the
> standard, preferring the better semantics over compliance, until I tried
> compiling our code with MLton.
>
> > It should also be noted that IE was notorious for its
> > poor adherence to standards.  Microsoft created its own
> > dilemma.  That's the real moral of Joel's story.
>
> Joel is one of MS's biggest critics, so I doubt he'd disagree with you.
> But still, there's no denying that when it comes to software evolution,
> success is its own worst enemy.
>
> Dave
>
>
-------------- next part --------------
HTML attachment scrubbed and removed