But one issue: it's not actually the case that "all CRDTs are OTs".
OT is the feature of Transforming and Operation. This requires two things: (1) Operations, and (2) Transforming them so that they do the same thing when applied from one place in distributed time vs. another place in distributed time.
However, there are plenty of CRDTs that (a) do not have operations, and also plenty of CRDTs that (b) do not transform operations.
Consider a typical state-based CRDT like LWW register. It does not have operations; it just has a current state: the value of the register. And it does not transform operations. It just always computes the current value of the register.
(For more on the relationship between OT and CRDT, see my notes at braid.org/meeting-111.)
I think it's debatable what constitutes an "operation". In a CvRDT, a delta or diff can be considered an operation. In an ID-based OT, it can be considered that there is a transformation of operations, only instead of transforming with respect to other operations, they are transformed with respect to the current document (if there were conflicts, they cannot always be applied in their original form).
> Abstractions can be costly, and it is often in a programmer’s best interest to leave code duplicated instead. Specifically, we have identified the following general costs of abstraction that lead programmers to duplicate code (supported by a literature survey, programmer interviews, and our own analysis). These costs apply to any abstraction mechanism based on named, parameterized definitions and uses, regardless of the language.
> 1. *Too much work to create.* In order to create a new programming abstraction from duplicated code, the programmer has to analyze the clones’ similarities and differences, research their uses in the context of the program, and design a name and sequence of named parameters that account for present and future instantiations and represent a meaningful “design concept” in the system. This research and reasoning is thought-intensive and time-consuming.
> 2. *Too much overhead after creation.* Each new programming abstraction adds textual and cognitive overhead: the abstraction’s interface must be declared, maintained, and kept consistent, and the program logic (now decoupled) must be traced through additional interfaces and locations to be understood and managed. In a case study, Balazinska et. al reported that the removal of clones from the JDK source code actually increased its overall size [4].
> 3. *Too hard to change.* It is hard to modify the structure of highly-abstracted code. Doing so requires changing abstraction definitions and all of their uses, and often necessitates re-ordering inheritance hierarchies and other restructuring, requiring a new round of testing to ensure correctness. Programmers may duplicate code instead of restructuring existing abstractions, or in order to reduce the risk of restructuring in the future.
> 4. *Too hard to understand.* Some instances of duplicated code are particularly difficult to abstract cleanly, e.g. because they have a complex set of differences to parameterize or do not represent a clear design concept in the system. Furthermore, abstractions themselves are cognitively difficult. To quote Green & Blackwell: “Thinking in abstract terms is difficult: it comes late in children, it comes late to adults as they learn a new domain of knowledge, and it comes late within any given discipline.” [20]
> 5. *Impossible to express.* A language might not support direct abstraction of some types of clones: for instance those differing only by types (float vs. double) or keywords (if vs. while) in Java. Or, organizational issues may prevent refactoring: the code may be fragile, “frozen”, private, performance-critical, affect a standardized interface, or introduce illegal binary couplings between modules [41].
> Programmers are stuck between a rock and hard place. Traditional abstractions can be too costly, causing rational programmers to duplicate code instead—but such code is viscous and prone to inconsistencies. Programmers need a flexible, lightweight tool to complement their other options.
Brendan Eich was the Director of Mozilla. This is the guy who invented Javascript in 10 days, at Netscape, and then co-founded Mozilla, and became the technical lead. He was Chief Architect of Mozilla, then CTO of Mozilla Corporation, then CEO. He made Firefox great. This was when Mozilla was in its heyday, and passed IE in marketshare.
Then he was fired in 2014 because a bunch of people went crazy that he made a $1,000 political donation for a California ballot proposition that had nothing to do with computers.
This sent a signal that Mozilla doesn't reward technical improvements to its software — it rewards following political trends.
Brendan was in charge of a company built on LGBT people. For him to turn around and donate to anti-LGBT political causes was not appropriate. The company fairly lost faith in him. How can you work somewhere your boss hates you so badly he campaigns against your basic human rights?
However, Brendan also did not increase his own pay by hundreds of percent while laying off over a quarter of the staff, which is what the executive teams since Brendan have done.
The bad stuff in Firefox started when the C-suite, now lead by an ex-McKinsey CEO, started lining their own pockets instead of running a technology company.
> Is there really any new-ish binary protocol these days?
HTTP/2 and HTTP/3 are binary protocols. And if you replace the JSON with CBOR, then even the payload becomes binary.
The reason for using HTTP is that the semantics are right. HTTP is a state transfer protocol, and ultimately, that's 90% of what you need for sync.
The other 10% is for subscriptions, updates, with versioning, and patches. You can get these by adding the Braid extensions (see braid.org) which upgrade HTTP from a state transfer to a state synchronization protocol. (I work on Braid.)
reply