Hacker News Reader

Comment by camgunz | Hacker News Reader

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 grep. Not only is it super explicit about it in all the docs, a major raison d'etre for it is its UX, which differs substantially from grep's.

Also, it's fine if people make mistakes, flounder, or get stuck. When I installed RedHat 5.0 for the first time it took forever to figure out out how to run programs (gotta use ./), then it took forever to figure out how to use emacs, then it took forever to figure out how to save a file and exit emacs. Along the way I learned a ton about man and info pages, how to page up and page down, the names of the keys... skills and knowledge that have served me literally for decades (OK, maybe not how to use info pages). Not everything needs to be optimized for like, minimal number of clicks to purchase.

View on HN

  > 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.

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.

  > 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.

> 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).

Lmao. I've done this. That's my whole point! I've weighed it against the upsides of filtering by default. And I have legions of users who like those defaults.

Your comments are filled with the conceit of certainty instead of acknowledging trade offs. Your comments are so incredibly condescending.

How about attacking my argument instead of my character?

I'm not attacking your character. I'm criticizing your chosen words and communication style. I was extremely careful about that. If you can't fix that, I don't see us moving forward. I'm pointing it out because I perceive your comments as carrying the implication that I'm not doing "real" engineering, given your ranting about programmers these days not being taught how to model "when things go wrong." The idea that I didn't do that is insulting.

Besides, I've raised several points that you've completely ignored from my perspective as well. So engaging with you further seems pointless.

I will continue to advocate in favor of making bold UX choices by looking at trade offs.

> 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.

Same! I really feel like HN should have like a "branch topic" or "move to DM" or something. Is that email (I'm on a big "everything is email/NNTP" thing lately haha)?

> 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.

Well I think he did this at least as much as you have. If there were some kind of usage study or telemetry on how many times people run rg and then run rg -uuu I guess we'd have something approaching good data on this, but I don't think we do. In the absence of that, it seems like we just have a couple of different viewpoints on ripgrep UX, neither more objective or correct than the other. That doesn't make them invalid, it just means neither is measurably wrong. You might point to IDK, GitHub issues or something, but silent majority and all that.

> This has everything to do with modes of failure.

Ooh I think the miscommunication here is when you say "failure". It's not a failure that ripgrep honors .gitignore. It would be if it advertised that it honors .gitignore, but then scanned everything you listed to ignore--that would be a bug. Maybe your issue with these tools is that the names of them shadow their coreutils counterparts, but don't aspire to be drop-in replacements and have significantly different UX? I can understand that. IMO "grep" is both the very specific tool and behavior of grep, but also a generic "look for something in the contents of things" verb. Like, I'd be with you if ripgrep were "ripawk" or whatever, but I think grep has a certain broad abstract meaning at this point. But yeah, fuzzy.

> Too much output is annoying but is highly unlikely to be catastrophic (especially if our prior is grep).

Well, grep is really parsimonious by default. I don't worry about putting it in systems where output ends up in log files. I really dislike the modern trend of being maximally verbose by default; IMO that's what -v and -vv and -vvvvvv are for. I get pretty annoyed having to pipe output through grep, and the nuclear irony of piping grep output also through grep would probably destroy me.

> I think you misread. I didn't alias fd to find, I aliased fd to fd.

Oh yeah that's what I meant. Whenever I have stuff that has annoying CLI args I build aliases or functions in my shell config, so like:

    alias cgrep=grep --exclude=.git --exclude=.gitignore --exclude=.node_modules --exclude=frontend_build

That way I still have regular grep hanging around, but when I'm grepping in my source code folders I just use cgrep (actually I think it was pgrep because of where I was working, which is also a little easier to type). Maybe it's a little imperfect, but engineering is the religious practice of celebrating imperfection.

> it is super-linear because of this communication that doesn't have to be explicitly stated

Oh I'm 100% with you on this one. Vim has a mental model where once you gain the tiniest bit of fluency you just take off. At this point I can rarely even tell you what commands I'm inputting, or like when things go wrong it's like I tripped over my tongue or stuttered or something haha. I think tools that show you a way of thinking (Lisp is another) are amazing. And moreover, I think they create _culture_. Getting trapped in Vim (or emacs... it doesn't even tell you how to get out!) is cultural, rm -rf'ing / is cultural, reading tons of man pages is cultural, dd -of'ing the wrong device is cultural, and you take different things away from those experiences. I learned that when you're using dd you're in "I'm not fucking around I will destroy everything" mode, and also that that mode exists--in contrast to more gentle or verbose CLI/TUI/GUI tools, and I learned to appreciate both (love dd, love OpenBSD's wizard installer). It also made me realize you can create culture through your work, choosing which values and aesthetics to showcase or mental models to build a tool/app/platform around. In the same way every act is a political act, they're all also cultural, and by necessity spiritual. When I build I put something of my spirit into it, not something ineffable like a soul or whatever, but the culmination of my experience, taste and ethos.

Maybe that's why engineers get into super heated arguments over the tiniest of things. They're not tiny to us! We feel them deeply.

> Personally I abhor the idea of "don't document, make your code self documenting."

Yeah Hillel Wayne had a great post about it [0]. I've been very anti comment a lot of my career, but I've been turned around. I can feel my brain start to sag when I think of a page of code full of huge identifiers like remoteControlWithSendOffExemptionEnabled or wtfever.

> It's not about "no manual" but maximize the amount of information the user gets "for free".

I personally don't love little helper affordances or overly verbose output. TFA has the perfect example of Helix showing possible commands as you input, because that would drive me absolutely bonkers. My fingers speak Vim the language, and when I speak English I don't have a box in the bottom right corner of my sight that tells me how the rest of my sentence might go. It's an entirely different part of my brain; it's non-visual.

I don't want to be bombarded by information. I want the bare minimum to convey your point. My mind is already full of incredible amounts of junk and I am often struggling to marshal enough mental resources to do reasonably good work. If I need more information, I'm capable of asking for it. I'll write a tool myself if I have to.

I do think there's a tension here between like, someone learning Vim and someone having used Vim for years. A feature like this is maybe really helpful for the former (I'm not super sure, it could end up being kind of a crutch, who knows). Maybe a useful way to put this is I don't want to start from a super loud "wall of sound" information environment. I want to start from silence and turn it up to where I'm comfortable. I want to adjust the mix or EQ different things to raise or lower them. I want to be able to configure different scenes where sometimes I'm very concerned about what things look like in memory, whereas others I'm very interested in the call graph, but I never want to see the call graph when I'm examining the memory because I want to focus on the memory.

There's a value here of respecting a user's focus and attention that I feel like isn't getting enough play. My strong feeling is don't try to give me information unless I've specifically asked for it. Don't anticipate. Assume I know what I'm doing (at least, allow me that illusion haha).

[0]: https://buttondown.com/hillelwayne/archive/why-not-comments/

  > If there were some kind of usage study or telemetry

This still wouldn't convince me because it's not what my argument is about.

(Fwiw, I think one of the reasons BS is upset is how frequent the issue is brought up. You can see his frustration in the GitHub issues too. And how he points to it being at the top of the readme and it still doesn't get through to people. Just like a sign on a door saying pull. There's a reason that doesn't work. Why literate people keep failing. Ask why and how it can be prevented.)

I know I'm miscommunicating but I'm really not sure how. Because it isn't about what most people do. It isn't about what most people what. I know this sounds odd, and maybe that's what's getting in the way.

Maybe I shouldn't say error because you're thinking the tool has errored? How about user mistake? When user uses the tool wrong? When something unexpected happens? Any of these will substitute. It's all about when I user does something and it's not what they think they're doing. Similarly I understand how it appears I'm arguing for verbose by default, and in a way I am (I'm not blind to this lol), but I'm also not really. But when talking about verbosity in terms of programs I think we'd need to distinguish number of words from what kind of words. Though I think it's not uncommon for debug or warnings to be misclassified as info haha.

Design is about communication. Any command you enter gives you feedback. Returning nothing or returning too much are feedback, the tool communicating to you. That's why this is less about majority of the time and user preference. Most of the time I want to filter dotfiles. But I don't always and that still won't convince me because it's orthogonal to my argument. I think if you can see why you might understand my argument a bit more. Because you still seem to be focusing on it being about preferences when it's not. It's about the information users get back when they enter commands and what that means and tells the user. I know this sounds like preference, but it isn't. This is why I brought up Norman Doors before. I wouldn't fault someone for thinking a vertical bar on a door that you push is just preference because we don't talk about these types of language and just expect people to get it. But it isn't preference, it is bad design. I think if you watch this you'll understand my argument much better (it's 5 minutes haha). Because I think you'll understand why one could say that they way these doors are made are objectively bad but it looks like it's all about aesthetics

https://youtu.be/yY96hTb8WgI

So design isn't just about aesthetics, it is about language. Albeit an unspoken and unwritten one.

  > Maybe your issue with these tools is that the names of them shadow their coreutils counterparts,

Please see my initial post. I think we've been talking so much that things got lost.

  > I'm not fucking around I will destroy everything

We shouldn't get rid of sudo. But yes, requiring an explicit action to enter this mode is the design principle I'm discussing.

  > Hillel Wayne had a great post about it

I didn't like the post tbh. His issue is better solved by writing a better comment. The comment is terrible and doesn't communicate what it needs to. But most people think they're far better at writing and communicating than they actually are. If I'm doubt, let my own comments serve as examples lol.

It also has poor assumptions. Ones that work for him if he is the only one using the code but I think it's absurd to think a lack of comment will be reliably interpreted as intentional and holding meaning that the function is inefficient. It only works if comments are highly prolific. And a new person coming in will assume that it's just because of how common this is and it's a more likely explanation.

But he's right about not using self documenting code in that cumbersome way. That is, as you say, too much.

I do apologize. This conversation has been exhausting for me. Not really because of you but there's been several people I've talked with. I do appreciate you comments and the conversation. I will almost always be happy to engage in long form and nuanced conversations. So when you see me again don't hesitate to word dump on me lol. Distilling words is very hard, takes a lot of time, and a lot of skill. But I come to HN because I hate Twitter

Reply on news.ycombinator.com