UCM should not use cd for namespace navigation

[xpe]

Purpose: I'd like to lay out the reasons why UCM should not use cd for namespace navigation. (This is what UCM currently does.)

Broader Context: #4

EDIT 2022-09-08: It is important to surface reasoning in the comments below, not just each individual's final preference. See also: #10

[xpe]

9.1 Reserve cd for changing the working directory

Many programming language consoles / REPLs include a change directory command (e.g. cd or chdir) for interaction with the file system. I suggest that UCM reserve cd for such a purpose.

[xpe]

9.2 Necessity and Correctness

Some key principles for programming languages and associated tooling include:

1. Don't introduce a new term unless it is needed ("necessity")
2. If you use a term, don't use it incorrectly ("correctness")

Applying these key principles to some particulars:

1. Unison (including both the language and UCM, the tool) does not need to have an additional word for 'namespace'.
2. Unison should not refer to namespaces as directories. They are different.

Suggestion: remove any reference to 'directory' that does not pertain to a filesystem directory.

[xpe]

9.3 The present situation appears to lack a conceptual foundation

The present situation, where UCM uses cd for namespace navigation, seems to lack a conceptual foundation, according to this account on Slack from September 2022:

Rúnar Bjarnason: The command is really called `namespace` and we added `cd` as a convenient alias
Rúnar Bjarnason: basically because we were constantly typing `cd` instead of `namespace` and getting an error :slightly_smiling_face:
David James: I'd hope that mistyping a command isn't the standard for adding things to ucm :grimacing:
David James: But I do think it is funny

[xpe]

9.4 j already provides good ergonomics

The j command (think "jump") is an existing alias for namespace.

What do I mean by ergonomics? I use the word like this Rust blog post talks about it:

Ergonomics is a measure of the friction you experience when trying to get things done with a tool. You want to achieve a state of "flow", in which ideas and intuitions are steadily transformed into working code with a minimum of fuss. (And, with Rust, we want that code to be reliable and fast as well.) The great threat to this experience is interruptions, which come in many forms: looking things up, switching contexts, going through a large amount of ceremony, or dealing with reams of errors where the compiler pedantically points out tiny things you forgot. Anything that takes your attention away from the problem at hand and puts it on details that don't really matter (or don't matter just yet).

I believe almost everyone can get used to j and achieve flow. (Those who cannot may of course add 'cd' as their own private alias.)

[stew]

I personally find the current cd command is natural. And I'd prefer we keep it.

In fact, I'd like it if we embraced it farther and allow things like cd ../.. and cd - for "previous location"

popd is one that I discovered naturally because it felt like is should be there and it was!

[xpe]

@stew I understand that cd feels 'natural' so you. Some agree. Some disagree.

Here is a key follow-up question for everyone:

• If it did feel natural to you, would you be swayed by someone else saying it felt unnatural to them?
• If it did not feel natural to you, would you be swayed by someone else saying it felt natural to them?

[xpe]

I'll be fully transparent about why I asked the two questions above. I think these questions highlight a problem: making a decision based only on what feels 'natural' risks moving a community towards position-based discussions rather than interest-based discussions. See https://www.pon.harvard.edu/daily/negotiation-skills-daily/principled-negotiation-focus-interests-create-value/

The four points mentioned there are:

1. Separate the people from the problem.
2. Focus on interests, not positions.
3. Invent options for mutual gain.
4. Insist on using objective criteria.

I recommend we think about the community interests rather than individual preferences. What kind of criteria we want to use to decide? See #10

[xpe]

@stew Are you willing to try a thought experiment step back a bit? What are the principles by which you'd like Unison to make these kinds of decisions? I created a separate discussion for this: #10

[xpe]

9.5 Using cd is a siren song

Introduction

“I think programmers have become
inured to incidental complexity…
when they encounter complexity,
they consider it a challenge to overcome,
rather than an obstacle to remove.
Overcoming complexity isn’t work, it’s waste.”
--- Rich Hickey, 2010 or earlier

The metaphor between file system directories and Unison namespaces is imperfect. It might seem ok-ish to start. But it breaks down.

Here is what I think is very likely to happen: Along the way, more and more people will become 'familiar' with cd in UCM. Inertia will take over. Conceptual clarity will lose out to 'pragmatism'. Many will want to extend the metaphor further, even to the point of trying to make the Unison syntaxes match the POSIX syntax. Now the tail will be wagging the dog. Also, such an effort is doomed to fail. It would be unnecessary effort. Unfortunately, the cause could be traced back by doubling down on unnecessary complexity. It will sap the community of energy that could be spent elsewhere.

[stew]

Extending the metaphor is not something "they will want someday" i'm openly calling for it here, and others are regularly in slack. I'm not so quick to label delivering these features as "unnecessary effort". I don't see how a directory structure is unnecessarily complex for use as a metaphor that doubling down on it is creating any extra effort at all. I don't think that asking for small extensions to this metaphor are much effort and they are a huge huge win for people that are spending a lot of time in UCM

…

On Thu, Sep 8, 2022 at 1:27 PM David James ***@***.***> wrote: 9.4 cd is a siren song *Introduction* “I think programmers have become inured to incidental complexity… when they encounter complexity, they consider it a challenge to overcome, rather than an obstacle to remove. Overcoming complexity isn’t work, it’s waste.” --- Rich Hickey, 2010 or earlier <https://www.red-gate.com/simple-talk/opinion/geek-of-the-week/rich-hickey-geek-of-the-week/> The metaphor between file system directories and Unison namespaces is imperfect. It might seem ok-ish to start. But it breaks down. Along the way, more people will become 'familiar' with cd in UCM. [They will want] to extend the metaphor further, even to the point of trying to make the syntaxes match. This is unnecessary effort caused by doubling down on unnecessary complexity. — Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAQJVEZ3L6TXXBXROE654DV5JD3PANCNFSM6AAAAAAQHIGHR4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[xpe]

Extending the metaphor is not something "they will want someday" i'm openly calling for it here, and others are regularly in slack.

Ok, fair enough.

That said, This actually strengthens my argument, in the sense that the follow-on desires I'm concerned about are already here. One result with the imperfect metaphor is people are trying to make namespace usability match existing shell conventions. Is this how we want to design UCM? ... by simply reappropriating existing shell commands into a new context? (What could go wrong? :))

I'd also like to advocate for the value of design. Design might involve reusing shell concepts and commands used for directories, but it shouldn't mindlessly default to them.

[xpe]

For the sake of argument, let's say I grant (temporarily) that my predictions above in 9.5 are wildly wrong, and there isn't any extra effort involved. This would mean 9.5 isn't a convincing supporting point.

But what about 9.1, 9.2, 9.3, and 9.4? Do they have zero bearing on this decision?

[stew]

I mean, yes! That IS what i'm advocating for this /particular/ thing, trying to be as clear as I can about that. I haven't been advocating for pulling in other shell modifiers or any shell commands. I'm trying to stay narrowly focussed to this discussion about the cd shell modifier. In this case I think that the fact that people that are using the things all the time expect it to be there (which is why it was created) is all I need to hear. This is how roads are built, we paved the places people were already travelling

…

On Thu, Sep 8, 2022 at 5:47 PM David James ***@***.***> wrote: Extending the metaphor is not something "they will want someday" i'm openly calling for it here, and others are regularly in slack. Ok, fair enough. That said, This actually strengthens my argument, in the sense that the follow-on desires I'm concerned about are already here. One result with the imperfect metaphor is people are trying to make namespace usability match existing shell conventions. Is this how we want to design UCM? ... by simply reappropriating existing shell commands into a new context? (What could go wrong? :)) I'd also like to advocate for the value of design. Design *might* involve reusing shell concepts and commands used for directories, but it shouldn't mindlessly default to them. — Reply to this email directly, view it on GitHub <#9 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAQJVAP5CXAKCGCLOLEFULV5KCI3ANCNFSM6AAAAAAQHIGHR4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[stew]

this feels like work now, but with respect to 9.1 I've extremely clear on no what have I been unclear about with respect to my feelings about 9.1?

I don't accept 9.2 #1 as a thing that is worth worrying about so the rest is moot for me. If you are really feeling strongly that we should accept #1 then I'd use that to say that we should NOT be introducing some new concept, we should just be re-using this concept of a directory structure, instead of some new namespace structure because they are practically isomorphic

I think 9.3 shows exactly why we should keep cd. it is the thing that people kept naturally trying even though it wasn't there. This reminds me of Ohio state not paving paths on their campus until they saw where paths were worn, then paved those paths, knowing they were letting the people decide what the paths should be, which seems great to me

9.4. makes an argument that j has good ergonomics, but no arguments about why j makes better ergonomics than cd in fact I could argue that it makes a better case for cd since that's the one that people reportedly keep trying anyway.

I don't think that your assuming that I wasn't' taking these things into account was in good faith, and I kinda feel like you keep turning the conversation into an adversarial feeling conversation so I thinking that this might be my last response to this discussion

[xpe]

this feels like work now

Yes, discussions can be hard. I'm sure we can all recognize that does not mean they are in bad faith or adversarial. It does not mean that effort is wasted. Communication can be hard.

I hope everyone can recognize that healthy debate is useful. Done civilly, it is essential.

Some people may feel that detailed, probing conversation is adversarial. Sometimes that feeling of discomfort comes from having ideas challenged. Feelings of discomfort do not necessarily imply that something has gone wrong. Yes, discomfort is sometimes a recognition that something doesn't fit. But that something might well be an inconsistency in concepts that one takes for granted -- perhaps coming from one's own beliefs or things that haven't been viewed from enough angles.

I admit I feel uncomfortable with the degree of vocal support for cd. This does not mean the feeling is bad or useless. I'm following that where it leads. I'm trying to understand it. I'm trying so understand logical reasoning first. Maybe that won't get very far; the underlying support may be less about about before-the-fact reasoning; it may well be inertia or convenience and perhaps even rationalization of something that would take work to change. I'm not sure -- but I see a lot of indications this might be the case.

When I come across a language that blazes a new path regarding content-addressable functions, I tended to think this would be a community that doesn't give previous concepts or UX decisions undue weight. I thought it would be full of curious people that can put aside discomfort and seek the best abstractions.

Along the way I'm seeing a lot of what seems to be defensive behavior. This is human nature, we all do it. But once we see we are doing it, we should pause and look inwards. Patience is a virtue. It is easy to walk away when you feel frustrated. I've felt that way many times here.

[xpe]

@stew wrote:

I don't think that your assuming that I wasn't taking these things into account was in good faith...

@stew: First off, I understand the feeling. No one wants to feel misunderstood. Second, I can assure you that I asked for clarification out of curiosity, with the hope to learn. It was not bad faith.

[xpe]

this feels like work now

Yes, discussions can be hard. I'm sure we can all recognize that does not mean they are in bad faith or adversarial. It does not mean that effort is wasted. Communication can be hard.

Some people may feel that detailed, probing conversation is adversarial. Sometimes that feeling of discomfort comes from having ideas challenged.

I hope everyone can recognize that healthy debate is useful. Done civilly, it is essential. Feeling of discomfort do not necessarily imply bad faith, aggression, hostility, or any of that. Claims of feeling like something is hostile does not prove intent of the other party.

[xpe]

but with respect to 9.1 I've extremely clear on no what have I been unclear about with respect to my feelings about 9.1?

I'm not following; I don't see anything you've written here (in this thread) that concerns 9.1:

9.1 Reserve cd for changing the working directory

Many programming language consoles / REPLs include a change directory command (e.g. cd or chdir) for interaction with the file system. I suggest that UCM reserve cd for such a purpose.

[xpe]

9.4. makes an argument that j has good ergonomics, but no arguments about why j makes better ergonomics than cd

Yet, this point is correct, but only narrowly correct. Here is what I mean. The point of 9.4 is to argue that j is sufficiently ergonomic. Being sufficient is, well, enough. (Yes, I'm open to options that are 'better than sufficient' -- I'll touch on that below.)

The combination with 9.4 and 9.2 results in argument like this: 1. cd (which stands for change directory) uses an unnecessary term ('directory') and; 2. incorrectly implies that 'directory == namespace'. Note: Isomorphism is irrelevant to this argument; this is argument is about human language, documentation, communication, not mathematical isomorphisms.

but no arguments about why j makes better ergonomics than cd

This is correct; it makes no such arguments. If one argues that cd is more ergonomic than j simply because it is more familiar, I disagree. Good ergonomics do not sacrifice conceptual clarity and good naming. Good ergonomics guide us to better syntax choices inside the constraints of correctness.

More broadly:

• Ergonomics are not exclusively about what is familiar at time t=0 (initial conditions).
• Ergonomics involve a range of people across a range of experience levels.
• There is a value judgment involved in weighing how to trade-off ergonomics across different experience levels.
• Finding good trade-offs can be challenging.

[stew]

I'm against 9.1. I like the current cd behavior, thought that was quite obvious by now

[xpe]

Would you like there to be some way for UCM to change the local working directory?

[xpe]

I like the current cd behavior, thought that was quite obvious by now

Yes, I understand your position. I'm also trying to understand your values leading up to it.

Sorry if it wasn't obvious, but I added this at the top of this discussion: "EDIT 2022-09-08: It is important to surface reasoning in the comments below, not just each individual's final preference. See also: #10"

[xpe]

@stew I'm sorry if this discussion is too much for you. I understand if you want to disengage.

But I would ask others to engage. I would appreciate it. I'm trying to help. Sometimes outsiders spot things that insiders have forgotten. I think Unison has potential. This potential requires healthy debate.

[pchiusano]

Hi crew, I’m going to go ahead and close out this discussion now. @xpe please don’t initiate another thread on this topic. I don’t feel like the discussion is continuing to surface new information, so let’s just agree to disagree. 🙂