4 ms·

If this is the "correct" way to learn, the problems are not with the user. A well designed ui should be learnable while being used - creating a fresh learning

If this is the "correct" way to learn, the problems are not with the user. A well designed ui should be learnable while being used - creating a fresh learning repo for dedicated learning for fear of losing data while using the tool in your "real" repo is the ultimate red flag in terms of usability.

popopopo 9y ago
a still, while people cry about UI (which is irrelevant part), other people just take time and learn git. by whatever measures. PS. throwing out things you test on. isn't that how every programming tutorial works? write code NOT in your main repository, test things out, throw it away (or keep it, whatever)?
- majewsky 9y ago
  With a programming language, if you open a new file A in the same repo and try out some stuff, and it doesn't turn out well, you can just delete the file and be reasonably sure that it doesn't fuck up files B, C and D in the same directory.
- lucideer 9y ago
  > UI (which is irrelevant part) UI usability is irrelevant... ?!?? > isn't that how every programming tutorial works Firstly, learning programming and learning to use a tool that is a component of your workflow are two independent things. The latter should generally (ideally) have a much lower (aiming towards zero) learning curve. Yes, this is possible, with good UI design. Secondly, even programming language designers strive towards lowering this learning curve. There is, imo, a necessary complexity, or "table stakes" for any reasonably useful language, but its still very evident to any language designer that this is a trade-off. Usability is desirable. For a tool as popular and essential as Git, usability should be a much more central goal than it seems to have been in the past.
  - nine_k 9y ago
    Is writing programs and building them a part of your workflow? Do you even spend time on setting up your build? On acquiring an actual understanding of how it works? Other tools are no different. If it's an important tool, it pays to actually study it. Do not expect tools to do what you mean before you know well what you mean.
    - lucideer 9y ago
      I think you're misinterpreting my post. I completely agree, you're absolutely right, but there's a huge different between what you're saying and what the gp was: that usability should not be a consideration for these tools. I do understand, in quite a bit of depth (which I'm sure is still far from complete), how Git works. I still prefer to use Mercurial because it doesn't require me to be continuously aware of the dangers of those internals on a day-to-day basis - it doesn't supply me with a loaded foot gun. Sadly, I use Git every day, and rarely Mercurial, because that's what the masses have chosen and I've found using in-between compat tools not to be worth the extra hassle for me.
      - nine_k 9y ago
        OK, I can agree: git is not as safe, mistake-proof, or consistent as it could be. What I like about git is that it gives a simple algebra of patches (diffs), and allows almost any sensible operation over them. It would be great to build a different CLI on top of the same data structures (and maybe the same plumbing) that would expose a more consistent and usable interface, while allowing for [most of] the same capabilities, and preserving interoperability. I suppose git-hg tries to achieve something similar, too. For me, much of the pain of git CLI was alleviated first by a set of aliases, and then by using magit from within emacs.
notzorbo3 9y ago
> A well designed ui should be learnable while being used Strongly disagree with that one. A UI that lets you work in the most efficient way (e.g. vi) can also be well designed, even if it's incredibly difficult to learn. > creating a fresh learning repo for dedicated learning for fear of losing data while using the tool in your "real" repo is the ultimate red flag in terms of usability. Again, strongly disagree. Git is a powertool. You don't let loose a powertool if you don't understand how it works. Creating a fresh learning repo is merely acknowledging that you don't know the tool well enough yet. There's nothing wrong with that. There's a big difference between being noob-friendly and being user-friendly. Personally, I hate noob-friendly tools, because they tend to just get in the way.
- lucideer 9y ago
  > Strongly disagree with that one. A UI that lets you work in the most efficient way (e.g. vi) can also be well designed, even if it's incredibly difficult to learn. See, I don't think you do disagree. I said a UI should be learnable while being used - vi is. I said nothing about it that learning needing to happen quickly. I use vim every day; it's not my primary editor, but I'm incredibly comfortable with it, which I wasn't for years after I started using it. But during those years of learning, I never got stuck with an unusable dev environment, I never lost data, I never had to Google how to proceed in order to get my work done. If I ran into a problem, I had the option of opening an alternative editor and continuing with my nice non-corrupted dev env, or I could choose to spend some time figuring out the vim way (and learn something). vi/vim have no foot guns. Perhaps this comparison is slightly unfair to git - vi is much simpler insofar as a modal interface is a simpler concept to grok than directed acyclic graphs. So they're not directly comparable, since vi's main barrier to learning is memorising commands and git's is conceptual. However - as has been mentioned elsehwere - hg makes a fine candidate in that regard.
geezerjay 9y ago
> If this is the "correct" way to learn, the problems are not with the user. OP's advice was essentially to first learn how to use a tool in a sandbox before screwing up mission-critical services. I really don't understand why you perceived the need to learn how to use a tool in a sandbox as problem that lies somewhere else other than the clueless newbie who's taking his first steps. Letting toddlers learn how to ride a bike by installing training wheels doesn't mean that bicycles are flawed or poorly designed.

popopopo 9y ago

a still, while people cry about UI (which is irrelevant part), other people just take time and learn git. by whatever measures. PS. throwing out things you test on. isn't that how every programming tutorial works? write code NOT in your main repository, test things out, throw it away (or keep it, whatever)?

majewsky 9y ago
With a programming language, if you open a new file A in the same repo and try out some stuff, and it doesn't turn out well, you can just delete the file and be reasonably sure that it doesn't fuck up files B, C and D in the same directory.
lucideer 9y ago
> UI (which is irrelevant part) UI usability is irrelevant... ?!?? > isn't that how every programming tutorial works Firstly, learning programming and learning to use a tool that is a component of your workflow are two independent things. The latter should generally (ideally) have a much lower (aiming towards zero) learning curve. Yes, this is possible, with good UI design. Secondly, even programming language designers strive towards lowering this learning curve. There is, imo, a necessary complexity, or "table stakes" for any reasonably useful language, but its still very evident to any language designer that this is a trade-off. Usability is desirable. For a tool as popular and essential as Git, usability should be a much more central goal than it seems to have been in the past.
- nine_k 9y ago
  Is writing programs and building them a part of your workflow? Do you even spend time on setting up your build? On acquiring an actual understanding of how it works? Other tools are no different. If it's an important tool, it pays to actually study it. Do not expect tools to do what you mean before you know well what you mean.
  - lucideer 9y ago
    I think you're misinterpreting my post. I completely agree, you're absolutely right, but there's a huge different between what you're saying and what the gp was: that usability should not be a consideration for these tools. I do understand, in quite a bit of depth (which I'm sure is still far from complete), how Git works. I still prefer to use Mercurial because it doesn't require me to be continuously aware of the dangers of those internals on a day-to-day basis - it doesn't supply me with a loaded foot gun. Sadly, I use Git every day, and rarely Mercurial, because that's what the masses have chosen and I've found using in-between compat tools not to be worth the extra hassle for me.
    - nine_k 9y ago
      OK, I can agree: git is not as safe, mistake-proof, or consistent as it could be. What I like about git is that it gives a simple algebra of patches (diffs), and allows almost any sensible operation over them. It would be great to build a different CLI on top of the same data structures (and maybe the same plumbing) that would expose a more consistent and usable interface, while allowing for [most of] the same capabilities, and preserving interoperability. I suppose git-hg tries to achieve something similar, too. For me, much of the pain of git CLI was alleviated first by a set of aliases, and then by using magit from within emacs.

notzorbo3 9y ago

> A well designed ui should be learnable while being used Strongly disagree with that one. A UI that lets you work in the most efficient way (e.g. vi) can also be well designed, even if it's incredibly difficult to learn. > creating a fresh learning repo for dedicated learning for fear of losing data while using the tool in your "real" repo is the ultimate red flag in terms of usability. Again, strongly disagree. Git is a powertool. You don't let loose a powertool if you don't understand how it works. Creating a fresh learning repo is merely acknowledging that you don't know the tool well enough yet. There's nothing wrong with that. There's a big difference between being noob-friendly and being user-friendly. Personally, I hate noob-friendly tools, because they tend to just get in the way.

lucideer 9y ago
> Strongly disagree with that one. A UI that lets you work in the most efficient way (e.g. vi) can also be well designed, even if it's incredibly difficult to learn. See, I don't think you do disagree. I said a UI should be learnable while being used - vi is. I said nothing about it that learning needing to happen quickly. I use vim every day; it's not my primary editor, but I'm incredibly comfortable with it, which I wasn't for years after I started using it. But during those years of learning, I never got stuck with an unusable dev environment, I never lost data, I never had to Google how to proceed in order to get my work done. If I ran into a problem, I had the option of opening an alternative editor and continuing with my nice non-corrupted dev env, or I could choose to spend some time figuring out the vim way (and learn something). vi/vim have no foot guns. Perhaps this comparison is slightly unfair to git - vi is much simpler insofar as a modal interface is a simpler concept to grok than directed acyclic graphs. So they're not directly comparable, since vi's main barrier to learning is memorising commands and git's is conceptual. However - as has been mentioned elsehwere - hg makes a fine candidate in that regard.

geezerjay 9y ago

> If this is the "correct" way to learn, the problems are not with the user. OP's advice was essentially to first learn how to use a tool in a sandbox before screwing up mission-critical services. I really don't understand why you perceived the need to learn how to use a tool in a sandbox as problem that lies somewhere else other than the clueless newbie who's taking his first steps. Letting toddlers learn how to ride a bike by installing training wheels doesn't mean that bicycles are flawed or poorly designed.