3 ms·

Seems pretty similar to KiSS (Keep it Simple Stupid)

SAI_Peregrinus 6y ago
The big difference is that sometimes users will expect a certain complexity or some unnecessary steps, so providing a way to do that will keep them from being surprised and make their existing training work.
MaxBarraclough 6y ago
I don't think so. It's about consistency, not about limiting complexity. The creator of Ruby, Yukihiro Matsumoto, was clear about his placing value in the 'principle of least surprise', presumably referring to the same idea. Few modern languages are truly simple - in practice that's likely to mean making the language anaemic - but consistency in languages is still something to aim for.
kmill 6y ago
I can see the similarity, though Git seems like an interesting differentiating example. Technically, it is extremely simple. A commit is a file tree with content stored in blobs along with a reference to the previous commit. A branch is the id of the blob containing the commit. Yet, it is frequently astonishing. The layers of porcelain over the plumbing are testament to the fact that the underlying model does not map to how you expect to work with a version control system, whether that's due to previous experience to due to an "impedance mismatch" with the way people actually work. Don't get me wrong, I happily use Git since I'm willing to bend my will to the machine in this way. It does realize its promise. A great example that's in the intersection of both is copy/cut/paste. That was the result of a user study for the Alto, I believe, watching real copyeditors doing their work. And it's technically straightforward. In contrast, the Emacs kill ring and undo system, together, trip me up even after years of use. They are technically elegant, but together create some astonishing situations. Like Git, all are easily fixable, yet still there is some friction. The PoLA, in its best form, seems to me to be about whether a user's will can be realized in as direct a way as possible. This might, potentially, have a very complicated implementation.
- loopz 6y ago
  Git, when explained properly, should be intuitive. This follows the Principle. The lack of explanation, or the complexity that arise in real life, may be problematic. If git has problems in this area, it is because of lack of proper communication.

The big difference is that sometimes users will expect a certain complexity or some unnecessary steps, so providing a way to do that will keep them from being surprised and make their existing training work.

MaxBarraclough 6y ago

I don't think so. It's about consistency, not about limiting complexity. The creator of Ruby, Yukihiro Matsumoto, was clear about his placing value in the 'principle of least surprise', presumably referring to the same idea. Few modern languages are truly simple - in practice that's likely to mean making the language anaemic - but consistency in languages is still something to aim for.

kmill 6y ago

I can see the similarity, though Git seems like an interesting differentiating example. Technically, it is extremely simple. A commit is a file tree with content stored in blobs along with a reference to the previous commit. A branch is the id of the blob containing the commit. Yet, it is frequently astonishing. The layers of porcelain over the plumbing are testament to the fact that the underlying model does not map to how you expect to work with a version control system, whether that's due to previous experience to due to an "impedance mismatch" with the way people actually work. Don't get me wrong, I happily use Git since I'm willing to bend my will to the machine in this way. It does realize its promise. A great example that's in the intersection of both is copy/cut/paste. That was the result of a user study for the Alto, I believe, watching real copyeditors doing their work. And it's technically straightforward. In contrast, the Emacs kill ring and undo system, together, trip me up even after years of use. They are technically elegant, but together create some astonishing situations. Like Git, all are easily fixable, yet still there is some friction. The PoLA, in its best form, seems to me to be about whether a user's will can be realized in as direct a way as possible. This might, potentially, have a very complicated implementation.

loopz 6y ago
Git, when explained properly, should be intuitive. This follows the Principle. The lack of explanation, or the complexity that arise in real life, may be problematic. If git has problems in this area, it is because of lack of proper communication.