6 ms·

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 thi

• 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.
  • burntsushi 2y ago
    > 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.
    • godelski 2y ago
      How about attacking my argument instead of my character?
      • burntsushi 2y ago
        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.
  • camgunz 2y ago
    > 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/ https://buttondown.com/hillelwayne/archive/why-not-comments/