> aesthetic preference

I think this is the core of why we're not communicating and why I'm a bit frustrated with burntsushi. My argument has *nothing* to do with aesthetics (nor anything to do with preference). I think one reason poor design is so prolific is because people conflate design with aesthetics. That's part, and matters, but design is so much more and aesthetics is not what should drive design, but error analysis should[0].

My argument has from the beginning been about failure. How things fail and the nature of how this is communicated to the user. If you think by "design" I mean "aesthetics" then we have no hope of understanding one another.

This is why burntsushi's argument is not meaningful to me and has no potential to sway me, because it is not addressing the argument I'm making. My argument is that when you are doing failure analysis that you have to look at the different ways things can fail (I am considering both, and both have been in all my examples). Too much output is annoying but is highly unlikely to be catastrophic (especially if our prior is grep). It can also be dealt with in other ways and sends a clear signal (excessive output) to the user to do something about it and WHAT to do about it (filter). This is "free" information. But too little output does not communicate to the user that something is amiss and this is why it leads to catastrophic issues. That's why this is "more surprising." It isn't that too much output isn't surprising (it is), but that there's a natural signal back to the user.

"Deadly" errors are the ones where there's no indication that something is wrong. In our case, there's even a signal telling the user that things are fine when it is not. It's extremely difficult to fix problems you're not aware of and even harder to fix problems that tell you there's no problem. That's why this mode of failure has higher "surprise" (we can call it perplexity if you want to use more formal language) and why I'm talking in a non-subjective way. This has absolutely nothing to do with aesthetics this has nothing to do with preference. This has everything to do with modes of failure.

So arguments about preference are not addressing my argument, and if it is interpreted this way we will talk past one another. Maybe you want to argue that these cases are rare, but that is subjective to the type of programming you do. The issue here is not too different from rm or dd, where it is easy to make mistakes and that they are quite costly. But at least those tools will give you VERY STRONG feedback (you destroyed things *AND you'll know it very quickly*). It naturally communicates to the user that they fucked up. But it is why many distros create a default alias with the iv flags and why they'll check for rm -rf /. It's also why many admins alias rm to a trashing command. It is because rm (and dd) have poor design. Almost every Linux user has accidentally deleted something they didn't want to, it is almost a right of passage. This doesn't mean they aren't essential tools and aren't useful, and I'm not saying rg is useless or a bad program itself. I'm just making the argument that this one aspect is.

> Just give it a different name.

I think you misread. I didn't alias fd to find, I aliased fd to fd. I didn't alias rg to grep, I aliased rg to rg. This is orthogonal to the issue though as that was about the added complexity (we need not rehash).

> There's no way you could make Vim not require documentation,

I think you misunderstood my point, so let me try to clarify. You should strive for this, but this doesn't mean abolish documents nor that it is a replacement(you'll NEVER find me argue that!). I did want to make clear that this will almost never happen fully. I've been using vim for well over a decade as well, and I think vim follows the design principles I'm trying to convey (I guess poorly). Yes, you need documentation for vim, but vim's beauty is that learning one thing results in learning a dozen things. The hard part of vim is learning the core aspects: about command/operator keys and movement keys, so it is a framework that most are not use to using. For example, if all you knew was the movements h,j,k,l,w,e and operators d,y then we know 18 things. We then learn that $ moves to the end of the line, and we didn't learn 1 thing, we learned 3! We learn about a new operator c, and we've learned 7 things! This is why vim is so powerful. Because you gain knowledge for free. Learning vim doesn't have a linear learning curve, it is super-linear because of this communication that doesn't have to be explicitly stated.

It's not about "no manual" but maximize the amount of information the user gets "for free". You get to exploit your prior knowledge, not that that prior knowledge is free. So I don't really disagree with your main argument, but I think we are miscommunicating due to priors. I'm an avid reader of docs myself and I highly encourage people to read them[1] and am passionate about documenting things as well. But I am *NOT* advocating for no documentation. Personally I abhor the idea of "don't document, make your code self documenting." It is a false dichotomy because they were never at odds. Document your code *and* make your code as readable as possible. These complement one another and together are more powerful than if either was done alone. I'm quite verbose and so I hope you do not think I'd argue we should avoid reading. That would be quite hypocritical haha. FWIW, I do appreciate you engaging in a longer more nuanced conversation. Even if we continue to disagree I appreciate this and wish more long conversations would happen on HN.

[0] This is one of a number of things I wish was more formally discussed in software education that is commonly taught in traditional engineering education. Every engineer will spend several classes learning about modeling when things go wrong, and it is stressed how this drives the way you design things.

[1] A big reason I think people should reach for documents over things like stackoverflow is specifically because documentation is much more likely to create compounding knowledge. Whereas I believe many times these other resources are more about a short and concise answer that's narrow to the problem. Though that isn't to say there aren't fantastic SO posts, blogs, and all that. It is always case dependent.