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)
Good Tools Are Invisible
121–130 of 305 posts
Re: Good Tools Are Invisible
#122If 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
#123I 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…
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
#124Earlier 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.…
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
#125Re: Good Tools Are Invisible
#126I've used vim for decades. Tried using Sublime about 10? years ago. It just got in the way.
Re: Good Tools Are Invisible
#127Re: Good Tools Are Invisible
#128As 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)…
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
#129Earlier 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…
There is more than selecting options. Selecting text is normally better with a mouse.
Re: Good Tools Are Invisible
#130For 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.