Hacker News Reader

Comment by macintux | Hacker News Reader

There are at least two problems with proprietary file formats.

First is the app lock-in, which perhaps hasn’t bitten you but not everyone is so fortunate, especially in a scenario the article describes, corporate environments where you can’t install arbitrary software onto the machine you use.

The other problem is corruption. I haven’t experienced this in a few years, but it’s certainly not unheard-of for a binary data file to experience corruption; often the only way to recover it is to perform surgery on it, which not everyone will have the tools and skills to do.

Plain text files are much safer in that regard.

View on HN

This argument always sounds superficial to me.

1) You can have corruption in files of any type. Text is no more robust to random bit flips. Pick a file format and there are often tools that can isolate the corruption to a small portion to recover everything else.

2) The solution to lock-in is not "let's make everything text", but "let's have open file formats". Many types of data, especially for project-management-like tools, aren't particularly well suited as plain text (or a markdown format). So many extra unnecessary parsing/regex steps have to be jumped through for the program to use it, and the sanitizing functions now have to be moved from code to the user's brain to not break things.

By all means, support open file formats and exporting functionality. But shoehorning -everything- into text sounds like some crazy mix of bikeshedding and worldbuilding. Why waste your time? Especially knowing MD will fall out of favor eventually, and a new format du jour will rise. What will you do then?

> Text is no more robust to random bit flips

Erm, a single bitflip will ruin, at maximum, a single character, which probably has enough context around it to be easily manually repaired.

Not so pretty much any compressed, encrypted or binary format... either a large chunk of it gets undecodable or the whole thing is lost.

Not universally true. But, regardless, most files are not text.

> But, regardless, most files are not text

Hence the initial post. (Are we running in circles now?)

I'm pointing out that everyone is comfortable with most files not being human-readable. And that it's a red herring to suggest that text is the longest-lived format. I'm sure my data could outlive text files if I "stored" it on granite blocks, but it's not very useful in that format. Same with plain text; it just isn't a very useful format.

I think this web is quite revealing:

https://plain-text.co/#the-office-model-and-the-engineering-... https://plain-text.co/#two-revolutions-in-computing

It boils down to a tradeoff of learning your tools while retaining full control vs use apps that abstract away complexity by giving up control.

If your work needs some strict technical requisite (reproducibility for example, or any other of the -ilities in software engineering), you need to have the control to tweak your tools so that you ensure it (Engineering Model, plain text files), but mostly is not needed so you can get away with working in the Office Model (binary files)

The app lock-in doesn't make me lose access to my content. Many proprietary formats are supported by import/export in major apps. There are converter tools. Also, I do not need to switch apps.

The problem with corruption is solved by backups. It's a solved problem.

> The problem with corruption is solved by backups

well, and checksums. otherwise you might not be aware of that bitrot. FEC would be ideal.

Yes, I can do all that, with a lot more effort, or just use plain text for content that doesn't need more and be happy with a simpler solution

Reply on news.ycombinator.com