41–50 of 99 posts
for a real database that works like git, see http://www.datomic.com if git killed svn, datomic kills postgres
Earlier quoted context omitted.
That's an interesting way to describe it. I've talked a lot about immutability at conferences, but I've never thought about it in those terms. Thanks.
That realisation has been used by environments like Elm's Reactor[0] or its (sadly defunct) Time Traveling debugger. I think Om also had something like that. Basically, if you use persistent data structures and a unified application state, you can keep a list of all previous application states and you can browse it or ship it for debugging, it's not that expensive. [0] in debug mode, you get a list of all events havi…
Library: https://github.com/arximboldi/lager
Ncurses example (full text-editor): https://github.com/arximboldi/ewig
SDL example: https://twitter.com/sinusoidalen/status/939539173584916480
Immutable data: https://github.com/arximboldi/immer
(There was a talk about Lager at MeetingCpp this year, still waiting for it to be published online...)
Is git a blockchain?
Short answer, yes. The current commit includes the hash of its parent(s), so its own hash reflects the whole history, and one can not change the history without also changing the current hash. Just like a block contains the hash of the previous block.
Git also uses a Merkle-DAG, but it is not a blockchain.
Is git a blockchain?
A Git history is a DAG[0] (each commit can have multiple parents) and beyond that a polytree (it can have multiple roots); while a blockchain is an arborescence[2] (there's a single root — the "genesis block"; and each block can only have a single parent).
Further, beyond the technicalities blockchains are generally very linear (the side-chains tend to be pretty short, forks aside) while Git repositories can be extremely broad (have lots of concurrent branches).
[0] https://en.wikipedia.org/wiki/Directed_acyclic_graph
[1] https://en.wikipedia.org/wiki/Polytree
[2] https://en.wikipedia.org/wiki/Arborescence_(graph_theory)
Is git a blockchain?
The answer depends entirely on definition. What properties of bitcoin are essential to a blockchan vs which properties are simply how bitcoin happens to use a blockchain?
If blockchain just means the Merkle tree, then yes.
If it means Merkle tree + a computational consensus system for adding nodes, then no.
Earlier quoted context omitted.
This suggests a poor abstraction.
"Internals" is a poor choice of term. "Data structure" is a better term. Git is "plumbing and porcelain". The plumbing is the core of git. Porcelain are shortcuts. In general, Torvalds projects (Linux, Git) aren't big on abstractions that maximize simplicity-of-use, they focus on doing complex things correctly and quickly. Adding abstraction makes it hard to get details correct and run quickly.
for a real database that works like git, see http://www.datomic.com if git killed svn, datomic kills postgres
if it were open source maybe, but i'm definitely not going to switch (even though i might want to) for licensing reasons. in fact, i have more motivation to write an libre datomic clone than to pay cognitect anything for their proprietary db.
for a real database that works like git, see http://www.datomic.com if git killed svn, datomic kills postgres
As much as I appreciate datomic, that's a poor conclusion to draw. git is objectively better than svn. Postgres is not objectively worse than datomic; there are things that datomic simply can't do efficiently.
Earlier quoted context omitted.
That realisation has been used by environments like Elm's Reactor[0] or its (sadly defunct) Time Traveling debugger. I think Om also had something like that. Basically, if you use persistent data structures and a unified application state, you can keep a list of all previous application states and you can browse it or ship it for debugging, it's not that expensive. [0] in debug mode, you get a list of all events havi…
I am working on something like that for C++, a library + debugger called Lager. Quite experimental yet, but been using it to write apps with SDL and Ncurses and I am happy with how it is going... In the end it is a very simple architecture, implementable in any language. Good immutable data-structures are important for big programs though. Library: https://github.com/arximboldi/lager Ncurses example (full text-editor…
I'm guessing you mean good in the sense of well-implemented (performant), but I think good in terms of interface is also very important
For instance in my experience & opinion Immutable.JS is not very fun to use regardless of its implementation, because the interface does not feel natural for the language (not that the designers can really be faulted, the user-accessible part of the language simply limits what they can do). I think a similar library for Python would have similar issues (due to Python being very statements-oriented which is antithetical to persistent data structures).
Earlier quoted context omitted.
If Git were purely functional, you would expect rebase not to modify the existing data in any way, and indeed that is exactly what happens. You can create, delete, or modify only the top-level pointers: branch names, reflog, etc. Instead, rebase creates a completely new set of commits, and points the current branch at a new one. This is exactly how functional data structures work in e.g. Haskell, where "inserting" an…
Git rebase alters the structures that are relevant for me, like heads of named branches. In Haskell let bindings are immutable. To reference to the results one has to put them into new bindings. I.e. if Git was purely functional, the rebase would create new names for branches.
Haskell has mutable refs. That's what Git branches are.