lmao nice site.
Hey, fair enough. I do really enjoy the fact that I can and have read the full Go and Lua specs, for example. Being able to hold the entire model of something in your head is a definite plus. To extend the analogy: that didn’t require me to know the fine minutia of their garbage collectors, just like with pijul, you shouldn’t need to know the implementation details of sanakirja.
On the other hand, if I do want to some of the finer details of the Go memory model, or read further about Lua coroutines (pdf), I can find it, and that’s good. So really it’s just a matter of “how much separation is enough”. Should it be a different binary, or is it OK to just corral it’s documentation? “For experts only.” I think at the very least we can agree that git does not separate enough, and that pijul would benefit from separating more. I think we are in the same page there.
To draw another comparison, have you not mastered Go unless you have: read the spec, read all extra documents on Go’s memory and concurrency management, know every single package in the stdlib by heart, know how to write functions for its assembler, etc.? I think not. Or at least I don’t think that hidden breadth of knowledge makes Go “a complicated language.” It just makes it rich because the only thing you need to understand the semantics of any program should be the spec. However, the spec wouldn’t be enough to be a master either. That kind of knowledge is more along the lines of what can be found in Effective Go and is only really found through experience and community. So I think having a simple and powerful core is more important than the total size of the project. git doesn’t make enough distinction about what is the core, and what is extraneous. To master git is more a matter of workflow than knowing how to use git-symbolic-ref. I think if pijul makes this distinction properly, it won’t actually matter if you can eventually do direct graph manipulation in the command line or crazy things like that.
There is a model for pijul, which I hope you have in your head or on paper somewhere, that tells a story about how pijul “works”. By “works” I mean, for example, a “function call” “works” by “transferring data and control” to a “function”. This level of abstraction. (I wanted to do my homework here about the “theoretical model of patches”, but links about it in the blog are broken.) I think that’s very very important for the project. Of course, it also matters that’s it is actually implementable. They are equally important. One is displacement, the other is force, and together they make work.
For example, what would be the definition of a “change”? Perhaps it’s a function of a diff between a subset of the current working directory, and the snapshot created from all patches in a channel? Perhaps more accurately, it’s that diff plus it’s set of dependencies on objects in the graph that snapshot was made form? What is the well defined finite set of operations that user can perform on changes and their well defined output? In other words, what is their interface. Whatever the answer to these questions, I think these basic things need to be clear, and the UI will probably just fall straight out of that. Other things like the concept of “alive” and “dead” edges are probably (hopefully) not relevant to this model, (although they are interesting) as much as they are relevant to implementation.
I think if we can have this, not only can pijul be ready for 1.0, but will have a very real possibility of easily surpassing git, who doesn’t answer these questions that well, but answers them enough and is flexible enough that it mostly doesn’t matter. The possibility of pijul answering these questions comprehensibly is I think a big reason of why people like the darcs developers were looking intently at pijul.
I also want to say that we shouldn’t be to surprised or worried if as we go on we realize many of the reasons that git is the way that it is and end up making the same choice. I predict we will still end up with a lot less (in a good way), and I don’t think pijul’s power come from being that different to git, but making some concepts that we already see in Git behave properly. For example, better merges, better branching, safe cherry-picking, etc. Pijul is not here to revolutionize the add/commit loop. (Is it?)
Dunno how I got into all that, but there it is.
