5 ms·
The Theory of patches-vector
- rawnlq 11y agoOther than formalism what new stuff does this introduce that text OT libraries (such as google wave(?), etherpad, etc) haven't done?
- deleted 11y ago[deleted]
- lumpypua 11y ago"All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, the fresh-water system, and public health, what have the Romans ever done for us?" Also, the writer of the article worked on google wave.
- rawnlq 11y agoI am not attacking formalism by the way. All of OT is basically "if these have x properties then we can do y" so I understand it is necessary. But author claims he invented a new flavor of "patch theory" but I can't see anything new here. Most of it is a standard intro on how operational transformations work except using category theory terminology. Would like to know for example how his choice of edit operations and requirement of properties compare with let's say share.js's: http//github.com/ottypes/docs (which was also written by an ex-google wave intern). Explaining the subtle differences between OT implementations and what new advantages his theory brings is more interesting IMO.
- fakedrake 11y agoI don't think the author claims they found something groundbreakingly new. In fact just the references contain all the points Liam makes. Patches-vector seems to be different to ottypes for example in that ottypes have predicted what types you would want to synchronize and provides you a correspondig OT type for each of them. What if I want to synchronize binary data or javascript objects or some other weird thing? If equality is defined for my object the library shouldn't need to make any other assumptions. Besides this practicality though, I think the whole point of the article is that one can mathematically reason about patches-vector.
- gosub 11y agoWould it not be sufficient to define Edit a minimally as: data Edit a = Insert Int a | Delete Int given that a Delete only needs the place of deletion and a Replace is a Delete followed by an Insert?
- fakedrake 11y agoI assumed that `Int` was the sequence index of the Edit, not the line number. The line position, which is not necessarily the line number, it might be contextual, is encoded in `a`. In fact the way I read the article was that `a` was a file, so you can have operations: - Insert Int File == "create file" - Delete Int File == "delete file" - Replace Int File == "patch file" Removing and Inserting a file each time it changes, while technically correct is probably not what you want. The nice thing about what Liam proposes (and type classes in general) is that it doesn't matter what we each interpret `a` to be.
- gosub 11y agoWell, a patch is defined as Patch [Edit a], so I presume the sequence of the edit is implicit in the list position. The article says that an edit is the modification of an element of a Vector. I think the parameter a is the type of the elements of the Vector. In your example, a Patch File would be something to apply to a Vector File, and the Int in the edit should be the index of the file in the vector.
- nn3 11y agoA better title would be "how to make simple things complicated"
- pzone 11y agoAbsolutely agree. I find the phrase "simple, but theoretically-sound manipulation of diffs" physically disgusting.
- Schiphol 11y agoIs there a 'category theory for programmers' text anyone could recommend?
- merijnv 11y agoYes! http://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-preface/ http://bartoszmilewski.com/2014/10/28/category-theory-for-pr... It uses both Haskell and C++ for examples, although for best effect it'd help if you could read (basic) haskell types. Or maybe not, I read it after learning haskell so I find it hard to just how it is from a just C++ perspective.
- Schiphol 11y agoThat's perfect :) Thanks a lot
- deleted 11y ago[deleted]