[Touche]

Files are data. Data should be eternal. You should be able to convert a presentation you make today 30 years from now to a newer format. Making software not-backwards compatible is fine and normal but if files expire in a few years Apple is saying that the things you do on their computers are disposable.

[teej]

The world isn't so black and white. Document serialization is a rocky landscape that is rife with compromise. You have to balance document open time, document save time, file size, backwards compatibility, forwards compatibility, recovery modes, interoperability, size in memory, parsing time, time to save to disk, proprietary embedded file formats, metadata support, and more. And those are just the development considerations. You also have to think about upgrade cycle, time-to-market, third party integrations, and what will help you win marketshare and sell copies.

Software is hard. I think it's pragmatic for software vendors to have a strong, transparent philosophy about the trade-offs so that consumers can make the right choice. As the grandparent points out, Microsoft values backwards compatibility. If you value that too, buy Microsoft.

[Touche]

> Software is hard. I think it's pragmatic for software vendors to have a strong, transparent philosophy about the trade-offs so that consumers can make the right choice.

I'm not talking about software, I'm talking about information. Information shouldn't have an expiration date. Here's a webpage from 1994: http://www.lysator.liu.se/pinball/expo/ Surely you wouldn't prefer a world where the blog you wrote 4 years ago can't be viewed on a new computer?

[Timmmmbob]

Yeah but "information" generally requires software to view it. The only reason that web page still works in modern browsers is because they've gone to all the effort to account for quirks in ancient HTML. Apple clearly didn't think it was worth the effort in this case.

Also worth pointing out it's much easier to display old formats than it is to make them editable.

[upofadown]

I don't think ancient HTML was complicated enough to have quirks.

[richardwhiuk]

Really? Looking at the source of that page:

IMG tags with unquoted SRC attributes, and unquoted ALIGN attribute

BASE tag with default attribute - tag is: <base="http://www.lysator.liu.se/pinball/expo/"> but should be <base href="http://www.lysator.liu.se/pinball/expo/">

UL tags with no LI tags

[pgeorgi]

That was one of the main reasons IE6 survived for so long.

So yes, under some circumstances, old formats are deprecated - even on the web. The world is better for it, but it still sucks for those who need that old stuff and are unable to move it forward.

[mseebach]

> Here's a webpage from 1994

It's a good thing that webpage didn't use the <blink> element.

[nemothekid]

>Surely you wouldn't prefer a world where the blog you wrote 4 years ago can't be viewed on a new computer?

A counter argument to that, is I'm not sure if I want to live in a world where parsing an HTML document takes over 1,000,000 lines of unparallelizable C. You are sweeping a huge requirement that makes the rendering of that page possible in 2014. Ultimately it takes software to render that information, and the software that does render that, may have an expiration date.

[sliverstorm]

Surely you wouldn't prefer...

How about if we're talking a blog I wrote 20 years ago, vs. some really nice improvement in modern software?

Backwards compatibility is great, and ideally no data would ever be lost to bitrot, but backwards compatibility always has a cost. I'm not unilaterally willing to pay that cost.

[michaelt]

Assume you work on Keynote, so you have access to all the code and documentation for the 09 format. On average computers are now faster and have more RAM. You don't need to write the format, only read it. Your users will tolerate 15 minute format conversion times and the loss some things like formatting and videos.

Is it really so difficult to just not break a feature that was present in the last version of the software?

[TillE]

Yeah, assuming your software is reasonably modular and you haven't completely rewritten everything from scratch in the new version, retaining support for old file formats shouldn't be a very big deal.

At worst (like in the case of iWork 13 which probably is completely new code), you get one programmer to spend a few days writing a converter which reuses most of the old code.

[XorNot]

More importantly, provided you don't do it too often, users will tolerate some loss of formarting fidelity from version to version.

[jperks]

Yeah, Microsoft is all that not too super cool and buggy but it's right in persevering the path. Not being able to open and work with old documents is frustrating. In a way it's like forgeting grandparents and parents. Not a good thing to do. Apple PR should hear our voices and make a move. They'll lose too much if they don't.

[mturmon]

"Data should be eternal."

This is not a useful statement. If you convert the "should" to a "shall", and try to design a system around that requirement alone, it would prove very hard. Even designing a clock around that requirement is very hard (http://longnow.org/clock/).

If you back off from the "shall", then you are in the standard world of engineering tradeoffs, which is where you started.

What features do you want to give up for "eternal"?

[wpietri]

Designing a clock around that is very hard because the clock is a physical machine that needs to physically last. Software is easier, because it's, well, soft.

I'm the developer who build their related Long Bets project (http://longbets.org/) and I think "data should be eternal" is a perfectly reasonable standard. That was certainly my goal in designing Long Bets.

If you start with that as a principle, I don't think it imposes particularly large engineering burdens, especially if you accept some potential degradation as a consequence.

For example here, instead of a "fuck you" dialog box, they could have imported the core of a presentation: text and images positioned on a sequence of frames.

An analogy is HTML. It's basically zero engineering effort to just suck the text out of a page. It is only modestly more effort to pull out some of the semantic markup, like headings, lists, and emphasis. And that's the part that really hurts to lose, not which precise shade of blue you used in your footer text.

[niels_olson]

Perhaps the ideas should be eternal, but the byzantine markup system? This is a major reason why the older I get, the more I prefer plain text wherever I can get it and open standards when I can't. Fancy rendering is just a variation on the drug dealer's bargain "the first hit is always free".

[345723]

It is eternal, as long as you have the system and the software that it was created with.

This can be said for all sorts of things, from the Commodore 64 to Keynote. If you want to be able to access the data on an NES cartridge you are going to need special hardware and software. Yes the ROMS are available now online, but that's only because someone with the hardware and software made it available to others.

This is the nature of proprietary formats.

[pif]

> This is the nature of proprietary formats.

Indeed. When you choose to save your work in a not-public format, you are decidîng not to care about its lifespan: complaining later is just useless, unfortunately.

[keithpeter]

My approach: Export every presentation as PDF. I'm guessing LibreOffice will be around for a bit (files from 2003 and later working ok) and the PDFs provide a second line of access, but, I accept, they are not convenient for editing.

[chris_wot]

Use ODF.

[keithpeter]

I do. LibreOffice saves in that format by default.

[reeses]

Assuming arguendo that data = information, a printout will suffice. Your conversion will be manual, but you should not expect a complicated, performant, object serialization format to last through several generations of computer architecture.

[jmcqk6]

All of this reminds me of _why

http://www.scribd.com/doc/136918361/Collected-PDFs-of-why