> > To differentiate from Git Pijul should focus on usability... If Pijul has an easy to use interface like Mercurial did then that will massively help adoption.
> I don't think the goal or differentiation of pijul is to be popular via good UI, though. If the theory of patches is good, it doesn't matter if pijul "wins" or not, as long as whatever does can integrate it. If the theory of patches is bad, I don't want pijul "winning" just because it has a good UI.
Note that usability and UI aren't synonymous. A big part of usability is the mental model that users build up in their heads. With Git, the naive mental model doesn't match what Git is doing behind the scenes at all, which is a big reason Git's command line syntax is considered arcane.
It is possible to stick a Git 'porcelain' on top that does match the naive user's mental model (eg. https://gitless.com/), but very few use them.
If Pijul's Theory of Patches has superior usability, part of that superiority is likely to be how easily users can internalize a mental model of it's operation (learnability). The UI can help or hinder that process with various affordances or lack thereof.
So, from your perspective, a 'good' UI would be one that reveals the Theory of Patches in a useful, learnable, usable way; and ought not be just some superficial gloss hiding away the internals from users. In that sense, surely 'winning' due to 'good UI' is a worthy goal to strive for?
I'm not writing a usability thesis here, I'm just using "good" to abbreviate the GP's "an easy to use interface like Mercurial".
I don't think a good UI would be contingent on it surfacing the theory of patches. It needs to surface productive workflows supported by the theory of patches. One way to do that is to teach it; another way to is build something else on top of it.
What I don't want is for pijul to become something I have to integrate into my toolbox just because the next semi-technical founder I sling for found it "easy" three years ago. I already had to deal with git taking over a) because it was fast, b) because github was easy.
> What I don't want is for pijul to become something I have to integrate into my toolbox just because the next semi-technical founder I sling for found it "easy" three years ago.
If Pijul becomes popular, somebody will inevitably make it easy to use, so on some level it doesn't matter exactly why Pijul becomes popular in the first place.
> If Pijul becomes popular, somebody will inevitably make it easy to use
That's exactly why it shouldn't become popular because it's easy-to-use.
If something becomes popular because it's efficient (git), or has some beautiful core logic (pijul), or because it supports well-integrated workflows (fossil), then it will eventually be that and easy-to-use.
If something becomes popular because it's easy-to-use but sucks in every other way, then we are stuck dealing with it for another 30 years.
My point was that regardless of why something becomes popular, some people will add it as a dependency solely because of the popularity, even when the original reason for that initial popularity ceases to be valid.
> I don't think the goal or differentiation of pijul is to be popular via good UI, though. If the theory of patches is good, it doesn't matter if pijul "wins" or not, as long as whatever does can integrate it. If the theory of patches is bad, I don't want pijul "winning" just because it has a good UI.
Note that usability and UI aren't synonymous. A big part of usability is the mental model that users build up in their heads. With Git, the naive mental model doesn't match what Git is doing behind the scenes at all, which is a big reason Git's command line syntax is considered arcane.
It is possible to stick a Git 'porcelain' on top that does match the naive user's mental model (eg. https://gitless.com/), but very few use them.
If Pijul's Theory of Patches has superior usability, part of that superiority is likely to be how easily users can internalize a mental model of it's operation (learnability). The UI can help or hinder that process with various affordances or lack thereof.
So, from your perspective, a 'good' UI would be one that reveals the Theory of Patches in a useful, learnable, usable way; and ought not be just some superficial gloss hiding away the internals from users. In that sense, surely 'winning' due to 'good UI' is a worthy goal to strive for?