Hacker News new | past | comments | ask | show | jobs | submit login

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: