What is a database, really?

Sign in to queue

Description

Alice wanders down a rabbit hole one day and finds Erik Meijer and Brian Beckman in the C9 studio. What's going to happen? What does she find? There's a plastic mouse, a hard drive, a hammer, database acid, a whiteboard and a couple geniuses in very rare form.

Erikand Brian explain what a database really is... Erik drinks hard drive acid, takes a hammer to a mouse in search of the database it hides (Brian's brawn is also employed in this endeavor), and Brian paints category theoretic expressions on the whiteboard. This isn't what you think it is, Alice. It's much, much more.

Enjoy. You don't want to miss this one. Smiley

Embed

Download

Download this episode

The Discussion

  • User profile image
    tomkirbygre​en

    Loads of fun! Smiley Also worth seeking out is Erik's article 'Your Mouse is a Datebase' in the May 2012 issue of 'Communications of the ACM' - gets you really thinking about async and data velocity.

  • User profile image
    Charles
  • User profile image
    dpratt71

    I'm very happy to see this video. I've been struggling to explain these concepts (among others) to my kids. This video is definitely the best explanation I have seen to date.

  • User profile image
    exoteric

    Watching and loving it. It's like the Mythbusters of monadic database programming. Smiley

    I've never been a fan of the name return; I think of it as enter - enter the monad Smiley

    Watching...

  • User profile image
    Maddus Mattus

    epic

  • User profile image
    AceHack

    Erik and Brian together are the best!!!

  • User profile image
    felix9
  • User profile image
    Charles

    Because this was made for ACMQ ... The next episode of BMO will air next week.

    C

  • User profile image
    Lars Kemmann

    Meijer + Beckman = rate as "5 stars" before even finishing the download. Smiley

  • User profile image
    eddwo

    Two by two, hands of blue!

  • User profile image
    Lars Kemmann

    My my, they keep adding more dimensions to that diagram.  (Not shown in the ACM article is the "homoiconicity" dimension (IQueryable & IQbservable) - I guess 4D is just too hard to print.)

    Wonder what'll show up next...?

  • User profile image
    eddwo

    It's fascinating how these concepts seem to be converging, I get the feeling I'm on the edge of being able to put it all together nicely, but I've not quite got there.

    I've been trying to put together a set of patterns for building our GUI applications data models using immutable data types with functional updates and structural sharing, as a way of getting Undo capabilities for 'free'. (Treat the data structure as a tree, and just keep hold of a stack of pointers to the root node, so 'Undo' is just switching back to the previous states root node)

    This seems much more straight forward than using a command pattern and having to  implement both the 'forward' and 'reverse' versions of each state change, or using a memento pattern and capturing/replacing the state within a set of mutable model objects. It also makes it straight forward to manage updates to a number of entity objects as a single 'user action', (do whatever updates to the data structure are required, but don't replace the root node until the end of the 'transaction').

    Of course with that in place it makes updating a value 3 levels down in the tree more complex than before since you must rebuild all the nodes above the updated node back up to the root node. The solution to this would appear to be using some composable 'lenses' to encapsulate the path down to the node to be modified, so that the rebuilding steps are automatically the reverse.

    The next stage is to work out how to translate the UI actions (clicks,drags,keypresses) into logical User Actions and hence model updates. This is where Rx would come in, if the output an Rx pipeline could be a delegate that could be invoked on the old root node to return the transformed tree. 

    I'm finding that I could do with something like Scala case classes in C#, I only want to have to define the properties for a tree node, and have some code-gen or framework turn that into a properly implemented immutable ADT type with ToString(), GetHashCode(), Equals() etc, and possibly construct the update lens types to go along with it. The case class 'copy' concept seems quite hard to replicate in C#, perhaps solvable by creating a constructor with an optional parameter for each property, (except optional parameter defaults must be constants!). This may require breaking out a T4 template or similar.

    There are so many other interesting ideas floating around at the moment, like EventSourcing/CQRS and data models like Datomic that include the temporal dimension cleanly, it seems like a way to combine those approaches would provide a very powerful alternative to what seems like the current messy state of RDBMs->ORM->Repository->UnitOfWork->Model->ViewModel->View etc. 

    Rich Hickey and Erik Meijer are my hereos at the moment. I seem to be stuck in a world of 'it doesn't matter if it's a terrible mess, just make it work', and it's great to see people actually taking the time to think about the actual core issues and come up with plausible alternative approaches.

  • User profile image
    eddwo

    @exoteric: The 'return' one seems to be missing from Linq.

    I've used a variety of ways of getting a single item into an IEnumerable

    IEnumerable<T> single = Enumerable.Repeat(value,1);

    IEnumerable<T> single = new T[] { value };

    and 

    IEnumerable<T> single = value.Once();

    where once is an extension method

    public static IEnumerable<T> Once<T>(this T value ) { yield return value; }

    Not sure which approach is really to be recommended, or is there something I'm missing?

     

  • User profile image
    Bas

    @eddwo: take a look at F# records, immutable data structures similar to Scala case classes, I think they will provide exactly what you need.

  • User profile image
    Charles

    @Charles: Felix is right. This is now a BMO episode. Come on, Charles... Smiley
    C

  • User profile image
    Thorium

    "Bind is the mother of all operators"...? How about fold (=aggregate)? Can you do bind with aggregate if your accumulator is type of M(v)?

    I'll try to explain here.

Add Your 2 Cents