[reubenmorais]

Seeing the world as mutable is a matter of perspective, if you explicitly model time as a dimension it can instead be seen as a sequence of transitions from immutable state to immutable state, an accumulation of events over time, which fits the log abstraction perfectly.

[Swizec]

> if you explicitly model time as a dimension it can instead be seen as a sequence of transitions from immutable state to immutable state, an accumulation of events over time, which fits the log abstraction perfectly

I worked with a feature that used this approach once. It even made sense for the feature (an immutable history log of patient chart data). It was absolute hell to work with. Querying current state, which was 99% of the usecases, was cumbersome and extremely slow.

Turns out doctors rarely care about any of that immutable history. They just wanna know what’s up right now. In their ideal world, you’d re-answer all the same questions 30 seconds before walking in the door.

Turns out a combination mutable table of current state + derived immutable log/snapshot/audit table works much better for most things.

[mrkeen]

> I worked with a feature that used this approach once.

You work with many features that use this approach.

  https://www.dbi-services.com/blog/oracle-log-writer-and-write-ahead-logging/
  https://git-scm.com/docs/git-reflog
  https://dev.mysql.com/blog-archive/mysql-8-0-new-lock-free-scalable-wal-design/
  https://www.postgresql.org/docs/current/wal-intro.html
  https://www.sqlite.org/wal.html
  https://www.amazon.science/blog/lessons-learned-from-10-years-of-dynamodb

[Izkata]

From this:

> was cumbersome and extremely slow.

I'm pretty sure those sit somewhere in between the two sides GP was describing: All of your links have "current state" as the interface and changes are logged as they're applied. The system they worked with apparently has the log as a first-class citizen and no "current state" interface, while what they wanted was a "current state" interface with snapshots.

[mrkeen]

Understood, but when we look at all the databases and source-control products, we're standing on the customer side. We get to experience stuff that just works, because the people on the development side opted for write-AHEAD-log and/or copy-on-write, as opposed to write-afterward-log or write-but-store-backups-in-case-something-goes-wrong.

When we're on the developer side of things, we get to choose whether to CRUD or to go eventy. If we want to build systems as good as those DBs, we should do what they did (events) rather than what they say (insert/update/delete). It's unfortunate that there's not much upstream tech to help us with this (it's pretty much just kafka) and that people who choose to use kafka get accused of 'resume-driven-development', etc.

>> Querying current state, which was 99% of the usecases, was cumbersome and extremely slow.

It's an easy fix if the events are there. Just cache the current state. It sounds glib but it's one of the first-principles of event-sourcing that makes me choose it over CRUD. If your events are immutable, they can be shared. If they can be shared, they can be folded into a fast-current-state-view. If they are instead mutable (or non-existent)), you can't share them unless you also have a plan on how to sync them (which no-one gets around to and probably overlaps on some classical impossibility result like two-generals.)

[robertlagrant]

You can use snapshotting to increase performance of the sequence of transitions approach.

[crabbone]

> perfectly

That's a joke, right? If you tried to live in this world, as a human being, not in some abstract database-building sense, you'd be completely lost in the first second of your existence, and would probably die in minutes because your body parts would "forget" how to function properly.

We make sense of the world because we have "object permanence", which requires the concept of larger things made up of components, with multiple possible configurations. This object identity is what allows to understand that you can do things like "type on a keyboard" (a keypress that changes the physical configuration of the keyboard doesn't destroy it, it's still a keyboard, just slightly different, but functionally equivalent to the one you had a moment ago).

If all you can do is transitions, you don't know upon transitioning if you still have a keyboard you are typing on or not. This also means that if you want to be able to function somehow in this world, then after each transition, you'd have to reassess all properties of all interesting aspects of the world just to make sure they are still there.

Only in very restricted number of cases can you use append-only log as a useful model. And you'd be bending over backwards with this approach when modeling trivial things, like a realtor business or an online book store.

[reubenmorais]

> If all you can do is transitions, you don't know upon transitioning if you still have a keyboard you are typing on or not. This also means that if you want to be able to function somehow in this world, then after each transition, you'd have to reassess all properties of all interesting aspects of the world just to make sure they are still there.

You're assuming that at every timestep all transitions are equally valid or equally likely. That's not a given, you can and of course should carefully model which transitions your system allows or not. In real life this model is Schrödinger's equation, as best as we know it. In your information system it can be whatever you design it to be.

[crabbone]

If you want to build a stateless system with transitions, you are limited to regular expressions (finite automata).

I don't think you'd like to write real-life applications using a regular language. It might be interesting as an experiment, but life without recursion or potentially infinite loops sounds bleak... Just imagine the struggle of creating some generic containers like trees / hash-tables.

I don't think it's impossible, and may be even interesting to see how far one can take such a language to make it useful, but enjoyable this is not...

[hahn-kev]

Except lots of applications need to be able to forget things, similar to how things can be destroyed in the real world

[fnordsensei]

Forgetting what you had for lunch last Friday is not necessarily the same as changing what you had for lunch last Friday.

You could, for example, throw away the encryption key for that fact. What you had for lunch is now inaccessible, but the fact remains unchanged.