4 ms·

The biggest evidence against collaborative editing working and being useful is that programmers don't use it. We go through the pain of having git branches and

The biggest evidence against collaborative editing working and being useful is that programmers don't use it. We go through the pain of having git branches and manual merges. We're the nerdiest bunch in the world, absolutely willing to learn and adapt the most arcane stuff if it gives us a real of percieved advantage, yet the fact that Google Docs style CRDTs have completely elided the profession speaks volumes about their actual usefulness.

ansc 7mo ago
>Google Docs style CRDTs Google Docs is OT though.
zamfi 7mo ago
> The biggest evidence against collaborative editing working and being useful is that programmers don't use it. We go through the pain of having git branches and manual merges. Hmm -- this seems a bit apples and oranges to me: collaborative editing is sync; git branches, PRs, etc. are all async. This is by design! You want someone's eyes on a merge, that's the whole rationale behind PRs. Collab editing tries to make merges invisible. Totally different use case, no?
- catlifeonmars 7mo ago
  Collaborative coding is a niche but possibly interesting use case. I’m thinking of notebook cells with reactive inputs and outputs. Actually not dissimilar to a spreadsheet in many ways.
josephg 7mo ago
> The biggest evidence against collaborative editing working and being useful is that programmers don't use it. We go through the pain of having git branches and manual merges. But git branches are collaborative editing! They're just asynchronous collaborative editing. It would be possible to build a git clone on top of CRDTs, which had the same merge conflict behaviour. The advantage of a system like that would be that you could use the same system for both kinds of collab. editing - realtime collab editing and offline / async collab editing. Its just, nobody has built that yet. > the fact that Google Docs style CRDTs have completely elided the profession speaks volumes about their actual usefulness. Software engineers still rely on POSIX files for local cross-app interoperability. Eg, I save a file in my text editor, then my compiler reads it back and emits another file, and I run that. IMO the real problem is that this form of IPC is kind of crappy. There's no good way to get a high fidelity change feed from a POSIX file. To really use CRDTs we'd need a different filesystem API. And we'd need to rewrite all our software to use it. That isn't happening. So we're stuck with hacks like git, which have to detect and reconstruct all your editing changes using diffs every time you run it. This is why we don't have nice things.
- catlifeonmars 7mo ago
  > There's no good way to get a high fidelity change feed from a POSIX file. Personally, my main point of frustration with git is the lack of a well-supported ast-based diff. Most text in programming are actually just representations of graphs. I’m sure there is a good reason why it hasn’t caught on, but I find that line-based diffs diverging from what could be a useful semantic diff is the main reason merge conflicts happen and the main reason why I need to stare hard at a pull request to figured out what actually changed.
stephbook 7mo ago
Also note that our use case is much simpler. The programming language tells you whether your merge created a valid document.
- torginus 7mo ago
  I've never seen that information actually being used in any merge tool, with the notable exception of Visual Studio/C# (where you get symbol resolution for the merged doc, but even there the autogenerated result is a bit hit and miss)
  - stephbook 7mo ago
    I think the reason is that the algorithms want to be content-agnostic. But it's of course weird — as a user — to see a conflict resolution tool confidently return something that's not even syntactically valid.
GermanJablo 7mo ago
The biggest evidence for collaborative editing is the immense popularity of Google Docs, Notion and Figma. Just because programming code isn't a good use case for automated conflict resolution doesn't mean everything else isn't. Just imagine non-technical people using git to collaborate on a report, essay, or blog post. It's never going to happen.
koolala 7mo ago
Normal documents don't have broken builds when lines are incomplete. It's a completely different situation and makes sense why manually controlling it in chunks is better.

ansc 7mo ago

>Google Docs style CRDTs Google Docs is OT though.

zamfi 7mo ago

> The biggest evidence against collaborative editing working and being useful is that programmers don't use it. We go through the pain of having git branches and manual merges. Hmm -- this seems a bit apples and oranges to me: collaborative editing is sync; git branches, PRs, etc. are all async. This is by design! You want someone's eyes on a merge, that's the whole rationale behind PRs. Collab editing tries to make merges invisible. Totally different use case, no?

catlifeonmars 7mo ago
Collaborative coding is a niche but possibly interesting use case. I’m thinking of notebook cells with reactive inputs and outputs. Actually not dissimilar to a spreadsheet in many ways.

josephg 7mo ago

> The biggest evidence against collaborative editing working and being useful is that programmers don't use it. We go through the pain of having git branches and manual merges. But git branches are collaborative editing! They're just asynchronous collaborative editing. It would be possible to build a git clone on top of CRDTs, which had the same merge conflict behaviour. The advantage of a system like that would be that you could use the same system for both kinds of collab. editing - realtime collab editing and offline / async collab editing. Its just, nobody has built that yet. > the fact that Google Docs style CRDTs have completely elided the profession speaks volumes about their actual usefulness. Software engineers still rely on POSIX files for local cross-app interoperability. Eg, I save a file in my text editor, then my compiler reads it back and emits another file, and I run that. IMO the real problem is that this form of IPC is kind of crappy. There's no good way to get a high fidelity change feed from a POSIX file. To really use CRDTs we'd need a different filesystem API. And we'd need to rewrite all our software to use it. That isn't happening. So we're stuck with hacks like git, which have to detect and reconstruct all your editing changes using diffs every time you run it. This is why we don't have nice things.

catlifeonmars 7mo ago
> There's no good way to get a high fidelity change feed from a POSIX file. Personally, my main point of frustration with git is the lack of a well-supported ast-based diff. Most text in programming are actually just representations of graphs. I’m sure there is a good reason why it hasn’t caught on, but I find that line-based diffs diverging from what could be a useful semantic diff is the main reason merge conflicts happen and the main reason why I need to stare hard at a pull request to figured out what actually changed.

stephbook 7mo ago

Also note that our use case is much simpler. The programming language tells you whether your merge created a valid document.

torginus 7mo ago
I've never seen that information actually being used in any merge tool, with the notable exception of Visual Studio/C# (where you get symbol resolution for the merged doc, but even there the autogenerated result is a bit hit and miss)
- stephbook 7mo ago
  I think the reason is that the algorithms want to be content-agnostic. But it's of course weird — as a user — to see a conflict resolution tool confidently return something that's not even syntactically valid.

GermanJablo 7mo ago

The biggest evidence for collaborative editing is the immense popularity of Google Docs, Notion and Figma. Just because programming code isn't a good use case for automated conflict resolution doesn't mean everything else isn't. Just imagine non-technical people using git to collaborate on a report, essay, or blog post. It's never going to happen.

koolala 7mo ago

Normal documents don't have broken builds when lines are incomplete. It's a completely different situation and makes sense why manually controlling it in chunks is better.