Live data from Hacker News

Good Tools Are Invisible

gingerbill.org

161–170 of 305 posts

Re: Good Tools Are Invisible

#161
This is also true from the inverse. Making every tool visible may feel good to some users. They sit in their F16 cockpit, and they like having all those buttons, and knowing what they do.

But this does not scale. You can fit 100 buttons in front of you. You can learn each one and the best situations to use each. But can you fit 1000 buttons in front of you? No. Different humans have different complexity thresholds. Some humans can deal with 10 buttons, and some 250 buttons! But no human can deal with 2000 buttons. There exists a hard limit on tool complexity.

If you want your tool to be useful, then as you increase the number of different humans that sit in your cockpit, you naturally must lower the number of buttons in front of them. The tools must tend towards invisibility.

Re: Good Tools Are Invisible

#162

Earlier quoted context omitted.

I don't think your logic is off, but I also think that the FrobnosticatorStudio people have a point. The thing is, yes, the terminal gives you infinitely more capabilities but you probably have like, 20 actual things you do regularly? The learning curve makes it a hard sell when those 20 things are probably all you need. Like, sometimes I'll do something like this if I'm in a terminal and I want to find a build scrip…

My usual thought on this is that I don't want to get stuck at ctrlp ctrlf level. I always pick a tool that gives an intermediate expressiveness level even if it means a bit more efforts.. especially if it's not gui because I can reuse and compose it. For instance jq falls too far on the capabilities curve. It's a nuclear weapon but it's almost a programming language and I never can keep the operators in mind (even th…

> it's almost a programming language

It is a programming language. That thing you write between single quotation marks when you invoke jq is a program. (And like with other programming languages, it's often useful to write your jq programs to files instead of always writing them inline in the shell.)

I love jq, though. It provides an extremely good language for its task, even if I often have to take a look at the manual when writing an interesting jq program.

Re: Good Tools Are Invisible

#163
This is the type of text that tells more about the person writing than what it's written about. It feels to me his defending so hard his views because he doesn't even believe in it, as if he needs validation. Like, of course there are people who thinks vim is better because of macros, but I'm pretty sure many (if not most) of vim users don't even use that. Vim's main selling point is that you can do _anything_ without a mouse. And it's very customizable. Now, you can be more productive with any tool you want than the average vim user. Heck, I'm pretty sure there's at least one person in the world that's more productive using Notepad++ than the average vim user.

His whole rant on Linux and "highly configurable software" vs good defaults is just plainly nonsense to me.

> “Highly configurable” is often just an excuse for shipping no opinion at all and calling the resulting work your problem."

I couldn't disagree more. You can argue that Linux or other open-source software don't have "good defaults" is mostly because there's way less investment in 1) user experience; 2) quality assurance; mostly because there's no product logic involved in it.

Especially if you think that Linux, for example, is the mostly used in servers, and it works usually fantastically well in most server VMs. Maybe it needs a lot of fiddling to make it work on your old dell laptop because it's not where the work is put at. Windows will run well on it because Microsoft puts people actively working on making it run on most commercial user-end hardware. Apple machines will work perfectly on their hardware because that's what they're made for.

Arch Linux is not just better than any other Linux distro. It's better at one thing, just like Ubuntu is better at something else.

> I don’t want my tools to be “fun”. I want my tools to be invisible. > A good tool is and ought to be invisible—striving to make such tools is the goal of a toolmaker.

Bit of a wrong take, on my opinion. Every tool has its quirkiness, and you should embrace it. No tool is invisible. It feels less "visible" as you build more "muscle memory", but it's still there. We have to embrace the tools as part of the craft, not pretend they don't exist.

Re: Good Tools Are Invisible

#164
post #11

As a long time terminal user, it does not surprise me much when people just don't get it . The discussion often goes like this: — In a terminal, I can do so-and-so with a simple command — Well, in my FrobnicatorStudio, there's a shortcut Ctrl+Alt+So for that and this can go forever, going into pretty much useless comparisons like "in vim, I can delete 24 lines by pressing four keys" (no Sublime user ever needs that)…

vim isn't really something you use in pipelines though, it's a standalone tool.

Re: Good Tools Are Invisible

#165
There are people who get too fancy with vim, but it really is an invisible tool to many. Team around me changed IDEs multiple times and kept complaining about features changing, meanwhile I was using vim with some basic set of plugins like I've been doing for a decade, just works as always. Sublime is also a good invisible tool.

I don't care that vim looks "hacker" and has no GUI, but being able to run it via ssh is very convenient when dealing with remote machines, especially when your codebase isn't allowed to leave that.

Re: Good Tools Are Invisible

#166
post #96
post #11

As a long time terminal user, it does not surprise me much when people just don't get it . The discussion often goes like this: — In a terminal, I can do so-and-so with a simple command — Well, in my FrobnicatorStudio, there's a shortcut Ctrl+Alt+So for that and this can go forever, going into pretty much useless comparisons like "in vim, I can delete 24 lines by pressing four keys" (no Sublime user ever needs that)…

I've been working with the command line for just under two decades. A couple of years of those were spent with vim as my primary editor, but eventually I moved to Sublime and never looked back. But I still use the command line heavily in all my work. I usually have a konsole window that I alt+tab into whenever I need to build or run tests, instead of using Sublime's "build system" support. The only time I use vim is…

> I think the reason these types of discussions never die is because people in general tend towards closed mindedness. It's hard to put yourself in other people's shoes, and even harder to entertain the possibility that you're wrong.

I think the real reason is that people are used to GUIs who see the "harder tools" cannot entertain the possibility that they are wrong, and see the need to constantly make these hit posts to validate themselves. I have _never_ seen a vitriolic post made by a vim/emacs/tmux/etc. user telling users to switch over - I have seen countless by the "other side". I myself switched to terminal native workflows, not because of one of these posts but despite them, seeing how people who actually used these tools came off way more positive and seemed to enjoy their work way more than I saw from people who used e.g. VS Code and endlessly complained about anything not fitting into their worldview. It's exhausting and provokes no real discussion - nobody is actually being swayed by them, and it just adds fuel to the fire, letting people with opinions swing them around

Re: Good Tools Are Invisible

#167

Having designed a good number of internal tools for teams of developers I couldn't agree more. Earlier I had the tendency to "leave the guts" open, thinking my users were developers and would want that. All it did was put obstacles in my teammates actually doing their work. My teammates must use the tools I made for them to achieve work the company needs them to do, they don't want, nor should they want to, fiddle wi…

vi and emacs were designed by legendary computer scientists at two poles of the keystroke latency gradient. Bill Joy was on a model from an apartment in Berkeley, RMS was codifying the collected wisdom of a whole pool of elite typists on TECO and was doing so on the kind of connections at the MIT AI lab. Both of them were more or less stuck with QWERTY.

A keyboard interaction paradigm isn't a given chip or a driver for one. It is closer to UTF-8 than to Win 32. CUA is the Salesforce of such.

Ginger Bill, like many, is asserting that just because he's never encountered a bottleneck, there isn't one.

I'm not sure if that's arrogance or self-doubt puffing it's chest, but it ain't big dick energy.

Re: Good Tools Are Invisible

#168
post #98

Earlier quoted context omitted.

If we make a distinction between CLI apps and TUI apps, my interpretation is that the article was specifically talking about the latter. By a CLI app (with the emphasis on command line ) I mean something like grep, sort, cp, git, ls, tar, etc. The normal way of interacting with these is by writing commands on the shell, which means that if you know how to use it normally, you can also use it in a script. Which means…

Agreed about the difference between CLI and TUI; at the same time, I do indeed prefer TUI over the “normal” (window) GUI apps for the exact reason why I would prefer vim (or emacs for the other half) over a GUI editor: when you are already in the terminal, launching a TUI app is just faster than switching to a GUI window. So it's still about "terminal or not" for me, or even, what is your default starting point: is i…

> when you are already in the terminal, launching a TUI app is just faster than switching to a GUI window. So it's still about "terminal or not" for me

I’m principally a terminal person too, but my first thought was tmux cut/paste buffer (to transfer data whether TUI or CLI), not speed-of-launch.

Re: Good Tools Are Invisible

#169
post #11

As a long time terminal user, it does not surprise me much when people just don't get it . The discussion often goes like this: — In a terminal, I can do so-and-so with a simple command — Well, in my FrobnicatorStudio, there's a shortcut Ctrl+Alt+So for that and this can go forever, going into pretty much useless comparisons like "in vim, I can delete 24 lines by pressing four keys" (no Sublime user ever needs that)…

vim isn't really something you use in pipelines though, it's a standalone tool.

`command_a | vim - -c "file /dev/stdout" | command_b`

or, assuming vim is your $EDITOR, you can use vipe:

`command_a | vipe | command_b`

Re: Good Tools Are Invisible

#170
post #118
post #108

Earlier quoted context omitted.

Geez, I’m not saying there are none. I’m saying it’s silly to characterise it as an editor for puzzle lovers. You knowing ‘quite a few people’ can’t be generalised to the millions that use vim daily.

The article discuses that specific subset of users who are into puzzle solving, so we should ground this discussion around that point and not fall into the “tool x is good/bad” pointless debate.

It wholly does not. It in no way qualifies the statement that people who use tools with "more friction" (the unsound assumption under attack) because they view it as a puzzle game as a subset of the total users of that tool, and devotes zero time to discussing any alternative interpretetations of why someone would do so.
Post reply on HN