4 ms·

To differentiate from git, pijul should focus on its core features, not on arcane command line functionality. After all, you do not know how pijul will find it

To differentiate from git, pijul should focus on its core features, not on arcane command line functionality. After all, you do not know how pijul will find its success. Maybe command line will end up not being used at all one day. Remember Java? It was touted as a language for web applets first.

chriswarbo 5y ago
Java was designed for set-top boxes. It later transitioned to web applets. Then to web servers.
IshKebab 5y ago
To differentiate from Git Pijul should focus on usability. Thats by far the main complaint people have about Git. Not many people care whether it is patch based or snapshot based. It's super hard to explain what the advantages of that are. If Pijul has an easy to use interface like Mercurial did then that will massively help adoption.
- morelisp 5y ago
  > 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. Mercurial is effectively dead (outside of Facebook?) now. If the goal is simply to grow a project, repeating the same mistake doesn't seem like a good idea. 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.
  - webmaven 5y ago
    > > 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/ 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?
    - morelisp 5y ago
      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.
      - webmaven 5y ago
        > 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.
        morelisp 5y ago
        > 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.
        webmaven 5y ago
        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.
  - IshKebab 5y ago
    Are you saying that it was a mistake for Mercurial to make their software easy to use? That's a strange thought! Mercurial didn't lose because it was too easy to use. It lost because it was too slow and because GitHub became too popular. Those are orthogonal issues.

chriswarbo 5y ago

Java was designed for set-top boxes. It later transitioned to web applets. Then to web servers.

IshKebab 5y ago

To differentiate from Git Pijul should focus on usability. Thats by far the main complaint people have about Git. Not many people care whether it is patch based or snapshot based. It's super hard to explain what the advantages of that are. If Pijul has an easy to use interface like Mercurial did then that will massively help adoption.

morelisp 5y ago
> 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. Mercurial is effectively dead (outside of Facebook?) now. If the goal is simply to grow a project, repeating the same mistake doesn't seem like a good idea. 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.
- webmaven 5y ago
  > > 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/ 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?
  - morelisp 5y ago
    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.
    - webmaven 5y ago
      > 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.
      - morelisp 5y ago
        > 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.
        webmaven 5y ago
        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.
- IshKebab 5y ago
  Are you saying that it was a mistake for Mercurial to make their software easy to use? That's a strange thought! Mercurial didn't lose because it was too easy to use. It lost because it was too slow and because GitHub became too popular. Those are orthogonal issues.