Live data from Hacker News

Good Tools Are Invisible

gingerbill.org

121–130 of 305 posts

Re: Good Tools Are Invisible

#121
I only recently switched to emacs, and my motivation was not that I like tinkering but that having a flexible gui thing I can create custom views for w/ LLMs have basically 0 cost of producing new tools/uis. It's much the same with the linux example, I have been a lifelong windows user but switched around a year ago. I've tried multiple times in the past but hated tinkering and the issues that came up so never stuck with it. Now with LLMs I'm using a tiling wm and can just have a suite of hotkeys that automate everything I need to do, and if I ever want a new thing I can create the new view in a minute and never think about it again. The niceness in openness in tools is being about to integrate with everything else I use effortlessly. I wouldn't say invisibility the goal, but even further the idea of an isolated tool is an abstraction of the general human-computer interface. Your window manager is just as much a part of your ide or text editor as anything else, it's just the mediating layers between you and the program. From a phenomenological perspective the distinction between the different tools or piece of software is essentially arbitrary. Having more open tools that allow you to integrate with your WM and other things allows you to create that effortless, thoughtless experience. I would say a good tool is frictionless, not invisible. What constitutes frictionless for different people will obviously vary based on say how many different computers do you need to work on, what is the breadth of different kind of software and environments you need to work on? How do you control going between those? A frictionless code editor for me is not a code editor that is simple like sublime which in order to integrate with what I do I assume I could figure out some way to do it with a ton of custom scripting, but what is frictionless for me is what is open enough to allow me to go between a variety of different contexts without thinking about it, and being able to have whatever I want at hand without thinking about it. In the past I hate tinkering so much I would have never wanted to deal with this, and on windows particular it's practically not possible.

Just as an example of a frictionless tool, along with programming I also make music (including for some games I work on). When I was on windows to set up practicing playing music I had a preset in my daw I could open quickly, it would need to load then I could begin playing. On linux I just have something built into my taskbar with a performant amp sim and other audio thing always running so at any particular moment I can simply click something in my taskbar and immediately start using my guitar, mic, or analog synth I have set up on my computer. There's another menu to manage the mixing between channels, and things to run midi backing tracks I can practice to play along with. I could do this all on windows but doing each specific thing would require running something, making sure all my devices are still set up properly, using some other program whose UI I don't control to do something for me and just doing a bunch of different steps that impedes my ability to do this. Now I can just the moment I want to click something and it is immediately working with 0 frustration, it's a frictionless tool. I'm not just programming I'm also making music, games, assets for those games, and being able to leverage my WM/text editor to keep track of those things so I can cognitively offload them, and switch between them painlessly is to me the benefit of tooling. If I'm doing stuff with a team I can still leverage most of it but obviously the rest of the team isn't able to see the stuff I use to interact with it. The cost of creating small bespoke script/tooling/uis is essentially 0 now, and using AI to create bespoke tooling to me is a much safer approach than using AI to create code as it's just not really an issue if there's a bug in some of my personal scripts. I use odin for the game I am working on and I love it for it's simplicity and clarity, rather than using functions or programming language abstractions like classes to hide and organize functionality I just have some custom tooling for organize a mostly flat giant main game function. To me that's by far the least friction in understanding it and working on it. My main issue is across the projects I am working on, programming or otherwise, keeping things straight and coherent and being able to access and work with the associated files without thinking. Cognitively offloading to the greatest extent possible, so that what I do actually want to do is always at hand. I would say it's the opposite of invisibility though. (The psychoanalysis of what draws people to different editors is fairly boring and low effort, I absolutely hate tinkering. I am writing a game in Odin rather than using Godot because having to learn some poorly designed UI and how to futz around with it instead of just being able to do what I want is impossibly frustrating to me, it's a friction that locks me into future friction while the friction of learning emacs removed friction to other things)

Re: Good Tools Are Invisible

#122
Somebody wanted you to try their favorite tool, so they showed you how easy it is to do weird things in it. That doesn't mean they're using it because they can do puzzles!

If you're a programmer, you enjoy being able to get most of your editing done in your editor without going into the menus and digging for a feature, or searching a store for a plugin that allows you to do that. Of course if you have used your editor for years, and you know all the menus, shortcut keys, and have all the necessary plugins added, then you're fine!

Vim or Emacs allow you to learn some fundamental small tools and mix them to get your job done. Sublime and others allow you to find exact tools for those jobs that others put together. At the end, 10 years later, they're the same.

You're not better. They're not better.

Re: Good Tools Are Invisible

#123
post #29
post #17

I am afraid the author confuses familiarity with proof that his tools are better. The reality is that every tool has a trade off, and if a user prefers tool X compared to tool Y, it’s not because they are dumb, but likely they make better use of the affordances of that tool that only a power user would get. Give a developer 10 years each with vim, emacs and Sublime Text, they wouldn’t be so sure which is better. [1]…

The article was not against a tool but a way of thinking. He didn't say anywhere that Sublime was better than Vim. He did say that he disagrees with the idea that a tools friction is a feature. I can take his entire thesis and use it to show that vim is the perfect editor for me precisely because vim is invisible to me when I use it. In part this is because I turned vim into the tool I wanted. He turned sublime into…

>He turned sublime into the tool he wanted.

I think this also misses the point. Sublime just is the tool I want. I install it and I use it.

Eventually I may install a handful of add-ons via the baked in package control. But primarily it just is the text editor I want.

Re: Good Tools Are Invisible

#124

Earlier quoted context omitted.

The things about multiple cursors is that you think about the processing while doing it, while most people using macros looks at the structure of the text first and then devise the macro. I wouldn’t say the latter is faster, but it’s a different mindset. And the other thing is that vim has the “dot” command to repeat your last edit. Similar to macros, you think about your local edit first, then about where to repeat…

> The things about multiple cursors is that you think about the processing while doing it That visual feedback is EXTREMELY useful because I learn of the edge cases to what I am editing in bulk (usually formatting code or tables or whatever) as I am editing it. When you do a macro, you have to try and get it right, and then try again from the start each time to get it right. `dot` et al are not enough in that regard.…

> That visual feedback is EXTREMELY useful because I learn of the edge cases to what I am editing in bulk (usually formatting code or tables or whatever) as I am editing it

I do not disagree with that

> When you do a macro, you have to try and get it right, and then try again from the start each time to get it right.

But you are wrong in that, because you assume that visual feedbacks are necessary. They are useful. Using vim and the likes is very much like playing the piano or driving a car. You’re always one step ahead of your actions because translating intent into operations is effortless as they are ingrained in muscle memories. I don’t even look at the cursor much of the time because it will be where I need it. I don’t care for mistakes because they are easily corrected.

Even then, I rarely use macros because they are at the high end of the power spectrum. Only writing your own commands is higher on the list. Easy macros are easy to create, powerful macros are created only when necessary and are worth the carefulness. I don’t think there’s something similar to named registers and emacs counters with multiple cursors solutions. Or the ability to have multiple macros ready to go at anytime (very useful for data cleanup).

Re: Good Tools Are Invisible

#128
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 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 script

    cat packages.json | jq .scripts
And that's useful if I'm in the terminal, but if I'm in VSCode I'll just do

    ctrl-p -> packages.json  -> ctrl-f -> scr
It's actually fewer keystrokes.

I dunno, I've learned that people's workflows are really personal so I'd never tell someone to switch their's, but for me I prefer tools that understand the structure of my project instead of just treating it like text, so IDEs are a preference for me.

Re: Good Tools Are Invisible

#129
post #62
post #56

Earlier quoted context omitted.

>Your "flow" is just habits, things you've taught yourself to do By this logic a person who were comfortable with mouse should never grow to like VIM. > there is no "natural" or "intuitive" way to operate a computer. Fundamentally a computer is something that execute instructions. It is pretty poor interface to pick instructions from 100 options using a mouse as opposed to type it using a keyboard. A mouse hides the…

> By this logic a person who were comfortable with mouse should never grow to like VIM. Quite the opposite, my argument is that habits are changeable. > Fundamentally a computer is something that execute instructions. It is pretty poor interface to pick instructions from 100 options using a mouse as opposed to type it using a keyboard. A mouse hides the power of the computer behind a set of fixed clickable options. T…

Picking from 100 options is what the mouse is best for. Keyboards require learning so they are best for the options you do often enough to learn. I know about 10 different vi commands of the hundreds.

There is more than selecting options. Selecting text is normally better with a mouse.

Re: Good Tools Are Invisible

#130
I completely agree that the author is right and the strawman is wrong.

For example. The strawman criticizes GUI apps because he cannot navigate them with the keyboard alone. Keyboard-navigated TUIs are the worst type of UI.

CLI > GUI > TUI.

I don't like interactive tools because they're not scriptable. I don't care about keyboard vs mouse per se.

I don't like having to use different tools for the same job depending on if it's local or over SSH, so I prefer non-GUI tools in general. I want to have the same workflow for checking the processes running on a server and on a desktop. So htop it is, even though it's a TUI.

In my experience, actual GUI and TUI applications tend to suck compared to CLI tools. Tend to. The strawman seems to think that somehow this makes that whole class of UI inherently bad, so once again, I couldn't agree more that he's wrong. Then again, I care about the actual experience, not about whether it's inherent or incidental.

Post reply on HN