6 ms·

This kind of thing isn't without precedent; ls famously ignores files/folders that start with a dot. ripgrep in no way tries to be a drop-in replacement for gr

• godelski 2y ago
  > ls famously ignores files/folders that start with a dot. This isn't related. There's a specific system standard. It's been that way for decades and is now expected. Last I checked, git isn't part of the unix system, isn't ubiquitous in file systems, and gitignores don't exclusively specify files that are junk or binary (I always exclude build artifacts, like most people, but build artifacts are useful to look at. And I do ML, so I'm never gonna include my checkpoints because git isn't for binaries, but I still want to search for them). > Also, it's fine if people make mistakes, Sure! And we should learn from the mistakes. I'm not arguing fd or rg should change. Momentum is a bitch. But if you're going to build a new tool, don't make this mistake. We've talked about principle of least surprises but let's also talk about the way you have to handle this issue. In my dotfiles, along with thousands of other people, I have alias fd="fd --no-ignore" But now we have an issue. What happens when I want to add back the ignore? Sure, with this example I just do `\fd` but doesn't if I add any of the other likely flags to my alias. So now you have to complexity your argument parser to handle precedence. Which dominates? Ignore or no ignore? Does order matter?[0] You now have to make choices to handle things you wouldn't have had to if you did it from the other way. This design choice requires more complexity overall to meet user demands. Given that aliases are the norm for these kinds of situations, it is not a hard ask to ask users to alias if they want this as the default. But let's talk about that generalization more, because I see this error in software all the time. People think Defaults should be what most people will use This is wrong, for multiple reasons. First, your tools will always take on a life beyond what you expect and you will always be bad at predicting what people need or want (therefore use flexibility). Second, while you should strive for this, there are many conditions that take higher priority. For example the principle of least surprise. Good design should strive for users not requiring a manual. It's almost always impossible to actually achieve, but you still do your best. One key aspect to this is understanding natural feedback. In our example of too much or too little we can see that there's natural feedback so the user can understand. And yes, the feedback will cause the user to likely reach for the manual, but it won't let them think something is right when something is actually wrong! Even if you know 90% of your users would be happy with a specific default this does not override the importance of natural feedback signals. It's why people will still push on a door labeled pull, because the design is telling them the instructions not the label. Labels are just a patch to fix what was just a bad design. Look, lots of design is ambiguous and there's almost never optimal solutions. But our specific example is a software version of a Norman door [0] for our specific example with fd it's probably safe to let the ignore flag strictly dominate but I'm sure you can understand examples where this won't be as obvious and that the conversation at hand actually generalizes far beyond even unix tools and is a general design principle.
  • camgunz 2y ago
    It's clear you feel strongly about this, so I'm not gonna try and talk you out of it; I think the viewpoint you're espousing is perfectly reasonable. But I think you're expressing a subjective aesthetic preference, while trying to give it the weight of objective superiority by appealing to the principle of least surprise, "system standards" and the like. As burntsushi's tried to explain to you, it's possible to be surprised by ignoring .gitignore. It's totally reasonable to configure a source folder and expect coding tools to all use the same stuff. If I had to set up a .grepignore and a .findignore etc etc that would be surprising to me (and probably violate some design principles as well). And besides, system standards are just what we decide they are, they're no better or worse objectively and they're definitely not consistent (find, for example, does not ignore dotted files/folders). This is probably also a design principle. I made this point elsewhere, but it's fine to prefer what you prefer. No further justification necessary! But you're presumptive bordering on rude when you tell other people that their preferences for tools they built are objectively wrong or worse. We should all be free to build tools without worrying that our aesthetic, personal preferences will be assailed as objectively worse or downright harmful. It's cool that ripgrep does this and plenty of people love it (it's very helpful inside an editor, for example). > In my dotfiles, along with thousands of other people, I have... Just give it a different name. For years I had 'cgrep' which was grep with a lot of --exclude to avoid junk generated html/js/css (etc). That way when I wanted grep I got grep, and when I wanted code grep I could get code grep. Ez. > Good design should strive for users not requiring a manual. I can't disagree with this more. This works only for shallow tools meant for dilettantes. I have... probably tens of thousands of hours in Vim. There's no way you could make Vim not require documentation, and I'm grateful it doesn't limit itself to only what is self-documenting and that I don't need to disable tutorial mode or little helpers every time I configure it on a new machine. It's a power tool for power users. It's not for everyone, and that's super OK. Reading is a major way we get new information! We shouldn't be so allergic to it.
    • godelski 2y ago
      > 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.