Advice on what to do is easy to find. More rare is what not to do. They’ll often say “don’t use X, because of Y,” but that’s not so much advice as it is a specific criticism.
The topic interests me because significant feats of software engineering often don’t seem to revolve around new ways of doing things. Rather, they involve old ways of not doing things. Constraining your options as a software developer often enables you to reach higher than if you hadn’t.
Usually data is the ugly duckling, relegated to the role of an unlabeled arrow on a diagram. The main star is all the code that we will write, which we draw boxes around. But I prefer to give data top billing, both here and in general.
Instead of thinking of mutable data as the default, I prefer to think of it as data that destroys its own paper trail. It shreds any evidence of the change and adjusts the scene of the crime so the past never happened. All edits are applied atomically, with zero allowances for delay, consideration, error or ambiguity. This transactional view of interacting with data is certainly appealing to systems administrators and high-performance fetishists, but it is a poor match for how people work with data in real life. We enter and update it incrementally, make adjustments and mistakes, and need to keep the drafts safe too. We need to sync between devices and across a night of sleep.
[Apple’s Time Machine is] a significant feat of engineering, supported by a clever reinterpretation of what “free disk space” actually means. It allows you to Think Different™ about how data works on your computer. It doesn’t just give you the peace of mind of short-term OS-wide undo. It means you can still go fish a crumpled piece of data out of the trash long after throwing banana peels and coke cans on top. And you can do it inline, inside the app you’re using, using a UI that is only slightly over the top for what it does.
That is what immutable data gets you as an end-user, and it’s the result of deciding not to mutate everything in place as if empty disk space is a precious commodity. The benefits can be enormous, for example that synchronization problems get turned into fetching problems. This is called a Git.
It’s so good most developers would riot if they were forced to work without it, but almost none grant their own creations the same abilities.
Which is where WNFS comes in.
As for handing your data to others, there is already a solution for that. They’re called file formats, and they’re a thing we used to have. Software used to be able to read many of them, and you could just combine any two tools that had the same ones. Without having to pay a subscription fee for the privilege, or use a bespoke one-time-use convertor. Obviously this was crazy.
We do need optimized code in our critical paths, but developer time is worth more than CPU time most everywhere else. Most of all, we need the ambition to build complete tools and the humility to grant our users access on an equal footing, instead of hoarding the goods.