This is a note of the Rich Hickey’s two talks:

The two talks are about the design concept behind Datomic: a functional database.

Motivation

Try to distinguish the parts of our programs that are computationally oriented, and the parts of our programs that are machine oriented.

We want to isolate the machine part, and the amount of time we spend doing that kind of work, to the corners of our applications where that is necessary

FP allows us to use values and functions, not machines, as a computation model.

  • A Functional DB must provide database as a value. It must support writing functions that can take db values as args and return db values.
  • A Functional DB value must be immutable and accretive.
  • A DB has DBMS (machine) and values.

Regular db: durable, consistent, leverage (tools), and shared across processes.

  • The database is as a process.
  • It does not disentangle the state from the identity and you do not get the same answers over and over again.
  • It is hard to query multiple databases.

Functional DB Process

The computation is not part of the process. It gives immutable values. Functional db computation is orthogonal to functional db process.

There is a database value. We are going to pass it to a function. And we are going to get a result out. The cool thing about having separated this is that there is no problem having a function that manipulates more than one database value, so it is a function of two databases.

Value propositions

  • Just data: language-independent, aggregate, compose
  • Persistent data structures: alias freedom, efficient incremental changes
  • One structure, many functions: datalog queries, direct index access, entity navigation
  • Speculation
    • just drop to backtrack
    • try before buy
    • tree propagation
  • Time travel
  • Easy testing and fabricating

Conclusion

  • Functional DB has the same FP benefits
  • Many new capabilities
  • Dramatic simlification

Datomic

It is

  • A new database
  • A sound model of information, with time
  • Provides database as a value to applications
  • Bring declarative programming to applications
  • Focus on reducing complexity

Update

If you update someone’s email address, you do not actually change one email address into another email address. There is a new piece of information, which is that someone has changed their email address. we stop doing place-oriented programming, and move to a notion of programming that is about information accretion.

Terms:

Value: An immutable magnitude, quantity, number … or immutable composite thereof State: Value of an identity at a moment in time Identity: A putative entity we associate with a series of causally related values (states) over time Time: Relative before/after ordering of causal values

Implementation

Process, which is a term I will use to say “the acquisition of novelty”, of novel information, is something that requires coordination. In the end, I do not care if it is transactional or eventual consistency. That thing at the end that is going to merge together your stuff, that is a form of coordination. There have to be rules to govern what is allowed, and what is not. Somebody has to be responsible for doing it. We cannot all do it. One person has to eventually say, “I am taking these two things, and turning it into this merged result.”

persistent data structure, trees, structural sharing. Information model: accretion of atomic facts Split process and perception: Process is the transactional part, the coordination required to do that. Perception is the query side (leverage). Immutable basis in storage and novelty in memory: You accumulate novelty in memory. Occasionally you put it in storage, and you use persistent tree merge to do it. The transactor has no storage at all. It is strictly a coordination thing. It will take the novelty, integrate it into the live view, and put it into storage. When it puts it into storage directly, that is a logging, append-y kind of process. It is the indexing that is going to build the sorted view that gives us the leverage.