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 with a little tool they won't find anywhere else.
I still leave a lot of escape hatches, but I try to design the internal tools in such way as to make the users fall into a pit of success.
Edit: also, error messages, error messages, error messages and auto suggestions for common errors
Edit 2: also the number of people only addressing the examples in the post rather than the spirit of the post is... disappointing.
I think I have the same perspective. I see it as a flavor of progressive disclosure. Sane defaults and a way to customize if needed. Start with the 80% case and let people customize if they want to. It needs to be optional.
Especially with developer tools I think there's a hesitancy to be opinionated. If you don't know for sure an option is "always correct" it seems safer to ask the user. Developers can be very pedantic. "95% of people probably want it this way, but I should make people pick because that 5% has a valid point". But now you've made it worse for most users.
It's also so much more complicated to support customization, more than I think people realize. It's not just about bugs, every option makes polishing your UX much more difficult. Both because of the testing surface and also because more flexible abstractions are harder to design.
Some time ago I made an abstraction "hey, most people in our company who use CloudFront don't care about all the implementation details, they just want some paths to be somewhat cached". I explained this idea to a coworker. It took a while, but he understood it. Two months later someone merged a PR that replaced my interface "I want this and this path cached" with a simple passthrough that exposes raw AWS interface. Same thing happened to S3 buckets where I noticed that most people just want "auto-delete files after X days either on or off".
I spent entire year trying to explain to my manager "most devs who create services want a simple deploy button". Instead, we tried to teach devs how our "infrastructure as a code" works so that they'd contribute. The effect was that only one guy engaged with us this way, and he always sent us AI-generated PRs, and every time he saw an error, he just copy-pasted it to ChatGPT without reading and then the answer back to me.
The project eventually shifted towards my original idea, but in an extremely painful way without any design at all. It's just a toolbox of completely random features glued together because one day manager says "no we don't need to support X" and two months later a Jira ticket "add support of X".
And before any major change, add a `--v2` for early adopters and `--v1` as default. Nobody should notice anything on `--v1`, any regression must be fixed imediately. Flip `--v2` as default, leaving `--v1` for the unforseen. Until you can finally get rid of them.
I think configurability depends on how important your tool is to the core job function or role being performed, where it becomes very valuable for helping them directly perform the tasks they and their employer value, vs how much it allows you make problems they don’t value as much get out of the way of the ones they do.
For example, I am a HUGE fan of the way Gusto handles payroll and all the different taxes and form filing for me, because I basically do not even have to think about the problem or fiddle with it at all. But to someone whose job is doing payroll/accounting/taxes or working within giant enterprise HR/legal/finance departments that does more harm than good, because it’s something they have to fight (or less charitably it makes their job too simple).
The other big problem is who is actually making the decision to pay or spend money on a thing, and whether it serves more of a defensive (eg auditability, security, constraints against undesirable behavior) or creative purpose. The creative stuff is sexier but hard to quantify, and end-users won’t actually be willing to pay that much for it relative to how much it helps them or how critical it is to their role.
Good read, and I think a sort of living mindset, or “process, not product”, though seems to be follow-on/reaction to Perl’s TMTOWTDI (Tim Toadie)[0], and Python’s response(“There should be one-- and preferably only one --obvious way to do it”)[1].
it really depends on the framing, some work, especially fun work that develops skills is more valuable than people realize.
From an org perspective the goal is to create the highest curve of performance over the lifetime engagement of the employee or from the employee perspective their career.
And a lot of that depends on teh relationship of the people involved. From my perspective its a net negative when if my movers worked out the day before, their muscles will be sore and they'll do a worse or slower job. From the moving companies perspective its good, they'll be stronger for more jobs. Unless they quit or are fired that day, in which case we're back to bad.
The real evaluation isn't the macro vs the sublime edit.
its does the thought process of making them macro improve them in other things, and what were they doing before that. In my experience no one is going use the time they spent writing a macro or a learning vim to do real meaningful work, they're doing that because they're bored or burned out and want to think about something else they find fun at the time.
your problem isn't your employees choose to write random scripts, its that they dont have a sense of urgency or care about their current task.
Some work is also less valuable than people - especially hackers - realise.
Hackers have an addiction to tractable problems that require effort and some skill, but have a well-defined solution.
They don't require true originality or cleverness. Barrelling through them with adequate but not outstanding skills is more than enough.
Hacker systems like Linux, Vim, and Emacs, offer exactly this. You can tinker with them to solve consecutive microproblems in a satisfying way. Likewise other standard projects like working with vintage hardware or repurposing a consumer product to do something interesting.
This kind of work generates dopamine, where spending four days trying to track down an incredibly subtle bug in a giant stack owned by a few tens of people generates frustration.
So it's not that employees don't care, it's because some work really is hard and frustrating, and solving tractable problems is far easier and more satisfying.
But is it productive? Even educationally? Not necessarily.
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.
RMS may be legendary but he's no John Carmack or whomever else. I use emacs every day, and nobody who does the same can honestly say the foundations are good. The performance is atrocious. The UI locks up when you make network calls because the whole thing is single threaded. The whole thing is a mess of spaghetti code and there are multiple instances of core developers like Eli Zarerski admitting on emacs-devel that they don't know how <internal core system> works.
RMS is a visionary but as an actual software developer he's pretty mid.
You’re judging RMS skills based on the current performance of a tool he created 40 years ago using the tools available at the time. That’s wild. You complain about emacs being single threaded but computers in the 80s had a single core. Software at that time was always single threaded. By the time multiple cores became available, emacs wasn’t RMS’s personal project anymore and with lots of users it couldn’t just replace the core to make it multithreaded.
Tell me what Carmack has written that’s still widely used but did not start with the same “problems” as emacs.
Emacs is just old. Its foundations (as in the general design) are truly fantastic. I still don't understand how the heck not a single other editor over so many years has even considered replicating ideas like indirect buffers. That alone is a truly brilliant idea, and there are so many more.
Performance is atrocious today. At some point, a couple of decades ago, it might have been considered superb, but some may still remember "8 megabytes and constantly swapping". Emacs can be slow, yet its keyboard latency is still better compared to some other, more modern tools.
I'm not disagreeing with you, Emacs can be so damn annoying, and yet paradoxically remain enormously useful. Sadly (or otherwise), there's still no meaningful alternative to it, nothing even comes close. Lem has a promising story, but I remain skeptical. I think Emacs gets core C improvements sooner than Lem reaches meaningful, practical parity, although I might be wildly wrong in my prediction simply because I don't understand the scale of entanglement of the C-written core of Emacs, yet surely it's probably easier than porting the gigantic body of Elisp in existence to work in Lem.
I can't really comment on RMS' software developer skills - I have never directly reviewed his code. Perhaps, in modern times he'd be considered a "no hire", because being a software developer today requires a little bit more than just being a brilliant code writer.
> Do you have to use it for work? Do you just consider other editors to be even worse, so Emacs is the best of a bad bunch?
Not who you’re asking but:
- I have a very long legacy of both muscle memory and “just right” coziness in my Emacs environment, that has followed me around from machine to machine since about 2003.
- I have flip-flopped between GUI Emacs and terminal Emacs probably a dozen times, with my most recent flop being due to Codex and Claude Code, which I run side-by-side with Emacs in a split pane tmux window.
- Yes, best of a bad bunch. I am also reasonably comfortable in Vi(m) but dislike how it handles having many open files, which is unfortunately necessary for most of the work I do.
- I have used VSCode off and on over the years as well, most recently with Gemini, but found the GUI experience quite frustrating and the lack of a CLI option ended up being a show stopper (I sometimes need to write code over SSH and the way VSCode handles remote editing is highly unpalatable to me)
Edit: one other nice perk that I discovered the other day: Claude is quite good at elisp. I was having a really weird issue that seemed like it sat at the intersection of a few packages interacting funny. Put Claude on the problem, got a very detailed explanation of how three packages had evolved and how one of them hadn’t caught up with subtle changes the other two had done. Put together a patch and suggested I make a PR to upstream. I haven’t fully reviewed the patch but the bug seems fixed properly.
Emacs is not an editor. It's a Lisp-driven text orchestrator with a built-in editor. You can type your text in whatever IDE and still control everything through Emacs.
> try to design the internal tools in such way as to make the users fall into a pit of success.
Yes. I couldn't agree more. The tools have to make it quick and easy for the users to succeed - as invisible as possible, and transparent to what a user wants to achieve.
The effect of the interface becoming "invisible" is actually a function of time spent in the interface. I think what the author is reacting to is discretionary friction; designers or product folks adding features or complexity. The thing is, that friction may be necessary in order to achieve a certain task (think about resolving a merge conflict). And given enough time in the interface, even those "disruptive" steps fade into the background.
To give a concrete example, the console of a 737 is incredibly dense with controls. The airplane itself has many different modes, and there are many moments of intentional friction.
However, if you interview a pilot with 10+ years in a 737, they will tell you the interface has become invisible.
The same goes for the supposedly "bad" Bloomberg terminal. You'll find the same thing in Healthcare, where an interface cluttered with buttons is exactly the right solution for someone who spends 8+ hours/day in a MR scanning software and wants instant access to all the controls.
As programmers, I think we're too quick to generalize our own experience and preferences and try to apply them to others.
Source: I spent 10 years designing consumer and professional software at IDEO
It really depends on the tool… CRMs and EHRs are often designed to be customizable. But end-users typically don't want to spend a lot of time configuring and customizing the interface itself. All the choices quickly become overwhelming.
A "customizable" tool for any task sufficiently complicated to be someone else's profession inevitably results in a tiny micro-economy of configuration engineers who specialize in customizing the tool to be just so.
But the crazy thing is this is still a better solution in the majority of cases than not offering extensibility at all. It turns out buying one piece of enterprise software for $250,000 and hiring one specialist in it for $150,000 per year has historically been a better deal than dumping millions into building it yourself. The gains in efficiency for the fifty $400,000 per year doctors, and 500 $100,000/ye nurses, etc who use it are still worth it.
> … discretionary friction; designers or product folks adding features or complexity.
This is far more precise. The article talks about this from the users side, how there is a class of user who enjoys learning all of these “extra” features, even though they ultimately provide less value than the core features.
>> If people find vim, emacs, or whatever genuinely good and productive, I’m not going to criticize them for using it. People are most comfortable with what they know. But for the people I am discussing, that same familiarity blinds them to their tools’ flaws, and leads them to celebrate those flaws, flaunting them as games.
> The article talks about this from the users side, how there is a class of user who enjoys learning all of these “extra” features, even though they ultimately provide less value than the core features.
With Vim, Emacs, Git,... there's a core concept that all those extras get backs to. The issue with normal editor is that their concept of a text file is an array of lines of characters. Some goes further with providing some parsing to further isolate things like strings or symbols.
With Vim, there's the buffer (aka the content), the window (where user view the content), the cursor (which is the point of origin of many actions) and various commands that moves the cursor according to what's in the buffer. Like with the hand, you can draw, write, make dough, play the piano,..., you use the same hand, you don't have to replace it to do any other actions, you only taught yourself how to do it.
Same with git. It has a core concept that encapsulate everything to do with versioning text files, you just have to compose them to do what you want.
This kind of conceptual simplicity, even though the interfacing may be rough, is good because you are solving classes of problems instead of solving them one at time. For a particular problem, you only need to switch configurations, not to learn a new tool.
The issue is when you tackle a bunch of features not related to each other, or simplify the model so much that it's a toy instead of a tool.
> a class of user who enjoys learning all of these “extra” features, even though they ultimately provide less value than the core features.
I don't think this was actually established. The author may have a point about the UX of multiple cursors in Sublime, but comparing that to Vim macros is missing the point of the macro system — i.e. that you can create something that persists between editing sessions, and encapsulate a sequence of steps even of fundamentally different kinds. (For example, do multiple cursors allow you to implement a new command to transpose elements of a comma-separated list?) More importantly, though, this is not addressing the general principle about "extra features".
I haven't known other Vim users to speak of such "games".
Yeah I think this is all coming from someone who never got good at vim.
Multi-cursors can be nice, but a sufficiently powerful implementation of that looks like helix or kakoune, and those are at least as complex as vim, if not more.
When you're good at vim, it is invisible. Once you're good at writing macros, you can do stuff which is impossible with Sublime-style multi cursors.
I assume those are situations where the author would have "just written a quick script," but vim macros are an interactive scripting language specifically designed to tersely express text transformations. Your script is never going to be quicker than that.
I'm not saying this as a vim partisan or anything. You could easily argue that vim over-optimizes and saves little time in the grand scheme—that's a fair critique. But it's strange to insist that complex tools are complex only for the sake of complexity. It's a weirdly conspiracist mindset.
> but vim macros are an interactive scripting language specifically designed to tersely express text transformations
Yes, I think this is important here. Although it's still hard for me to imagine a level of mastery where one deliberately "writes" macros (what, directly in the vimrc?) as opposed to recording them. Perhaps it's within my grasp to optimize them later, but.
All that said, there are quite a few things I don't like about Vim even though the overall editing model clicks with me, and ideas I've had for something I'd like better. Although I guess I really should check out alternatives before running my mouth about that…
The 737 example is actually quite fitting. Sure, a long time pilot will perceive the interface as invisible.
But if you contrast it with the complexity of the same functions on other aircraft, you start to see how complicated it really is. The F-22 for example handles a lot of faults (like engine fires) automatically.
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) vs "in Sublime I have multiple cursors" (no vim user ever needs that either).
The proper argument here, probably, is this one: the terminal, with its way of combining small CLI tools
into pipelines, covers infinitely many use cases, but indeed has a learning curve, taking probably a year or so to become really comfortable. When you reach that point, you will be, on average, much more productive than an average GUI user, but it requires some dedication, pain, and suffering to reach that point, and people often do it involuntarily.
In my case, my first job required managing customers' servers over ssh, those servers had bare minimum installed (often vi, not vim), and I had no choice other than figuring out how to do things effectively in this setup. If not for that experience, I'm not sure I would've gone through the pain of starting doing things in the terminal.
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 <enter> -> 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.
I agree that both approaches are equally fast, and I myself did use VS Code at work a lot before the agents became widespread, so I can imagine myself doing either options. The terminal version is still less keystrokes because of the tab completion or reverse-i-search, but that's nitpicking.
> people's workflows are really personal so I'd never tell someone to switch their's
I regularly, especially when working with younger colleagues at work, find myself struggling to look at how slow they are in the terminal, like when they hit the up arrow 20 times to find the specific command in the history. If I have a close enough relationship with a person to make sure my advice won't be considered rude, I'd probably say “Ctrl+R and then type”, or even “let me show you how I would do it faster”, but doing this too often is borderline rude, so sometimes I just watch and feel bad for them.
I've seen it with seniors too. The smartest person I worked with (by far!) used to constantly use the menus in Visual Studio (OG Visual Studio, not code) for basically every operation. It was incredibly painful to watch. Watching him debug was a nightmare.
The second smartest guy I worked with couldn't really type properly. (He'd use two fingers). He was still a fantastic coder.
The thing is though, it kind of didn't matter because the value these guys provided was with their incredibly high intelligence, and the friction with how they interacted with tools was more of an issue on the margins than a big deal.
I think for people solving easier problems than these guys (who were working on legitimately hard problems), like, a webdev fixing frontend code, tools might matter a lot because there's less thinking and more navigating and typing. So context matters here a lot. But I definitely don't think you get to be an amazing programmer by CLI mastery (it definitely helps, but it's not a requirement)
I have used and use both regularly. The IDE makes the normal stuff really fast, but the CLI enables things that just can't be done in the IDE. I quite often ended up being the guy that dealt with things quickly, especially in an emergency. I just had the tools to get things done quickly, even when I hadn't been in that situation before. And I say that without even being good at awk and sed, which are used a lot by others in those situations. I always meant to get good at them, but never did. I ended up using other simpler tools instead to get the same kinds of things done.
In short, knowing the CLI way is absolutely useful, even if you use the IDE for 95% of stuff. And I also don't recommend going full CLI, because the IDE way is faster for that 95%.
Most things in life are about balance, and that's true here, too.
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 though I loved the idea at first).
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.
fwiw, Clojure pretty much replaced jq in my toolbelt. Dealing with EDN is so much gratifying - it's almost twice more compact than JSON, it's far more readable; filtering, grouping, sorting, slicing data is so much more straightforward and actually composable, not to mention that I get to do that interactively, directly from my editor.
My shell is configured to show me previews of commands that match from my history. Depending on how long ago I typed the cat command, it might be "cat -> tab -> return"
> I prefer tools that understand the structure of my project instead of just treating it like text
... but in the example you gave, did you not just have it pull up the text contents of a file in a window, and search through it (visually) as text? And on the command line, did you not invoke `jq` specifically to parse the JSON file as JSON?
And really, there is no reason that a TUI pager can't have progressive search that highlights matches. For that matter, vim actually does it. On the other hand, if you're just trying to jump forward to a named unique section, then the appropriate comparison is
> less packages.json <enter> -> /scr
Sure, `less` is more keystrokes than ctrl-p. But you're doing it in a much more general environment (it has to select from every program on your path), so of course it is.
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 that you can combine these into pipelines.
By a TUI app I mean (and I think the article means) something like Vim, Emacs, Tmux, Lynx, Tig, Midnight Commander, Claude Code, etc. - an interactive app that takes over your terminal while you're using it. You're not going to compose those into a pipeline. Or to be more precise, you're not going to use them in pipeline by using them the way you normally use them. If you can use them, it's probably because the app decided to provide a command-line interface in addition to the TUI.
You should not underestimate how confusing those CLI tools are to people who have never used them before.
For example, I would argue that for someone with no experience, figuring out how to copy a file from one folder to another is easier in Windows Explorer than learning how to use cp.
> For example, I would argue that for someone with no experience, figuring out how to copy a file from one folder to another is easier in Windows Explorer than learning how to use cp.
I don't believe this.
If you find a person (well, two I guess for this experiment) with no computer experience and want to teach them how to copy files, your first step will be teaching them what is a file and how they are organized in the computer.
Explaining what a file is takes the same amount of time for both cases (we can ignore how devices and processes are files in Linux and how files in Windows contain many data streams and extra metadata).
In both cases you need to teach them the file system is hierarchical and folders can be nested and can contain files.
For Windows you have to teach them how to double click to open folders. They can double click "My Downloads" to see their downloads. They can double click "My Music" to see their music files.
For the CLI you have to teach them that `ls` can list the contents of a directory. They can `ls Downloads` to see their downloads. They can `ls Music` to see their music files.
For Windows you then teach them they can open multiple windows (assuming you want to copy from one folder to another folder). And you teach them they can click, hold and drag and drop a file to move it (but sometimes it will be copied when they do that) and they can hold in Control while dropping to copy the file to the destination instead. Or you teach them they can use Ctrl+C to mark a file for being copied and then navigate to the destination and use Ctrl+V to copy the file. Or you teach them to right click for the right click menu, and that "copy" means "mark this file for being copied", and that a right click in the middle of a window displaying the target folder lets them select "paste" which means "copy the marked file here".
For the CLI you teach them `cp Downloads/foo.mp3 Music/` copies foo.mp3 from their downloads to their music directory.
The CLI is also infinitely easier to help newbies use over the phone!
Look I’m a big fan of having CLI interfaces, and they can definitely let you do things that you just can’t do (or are extremely difficult to do) with a standard desktop gui. But at the same time, the GUI means they never have to learn that `cp Downloads/foo.mp3 Music /` will give them a cryptic error that Music can’t be found. Or that if they’re already in the Downloads directory then they need to instead type `cp foo.mp3 ../Music/`, or that they’re going to need to figure out the special way to tell the computer what they mean when they want to do `cp Downloads/foo bar (feat. baz and the fizzbuzzes).mp3 Music/` and that doesn’t work when they type it in.
The initial explanation of the happy path might be slightly longer to teach drag and drop or right click copy and paste for files, but that happy path will also deal with a lot more scenarios in the exact same way than the happy path cli commands will.
My mom struggled to understand the concept of copying and pasting when she got her first computer at home, with Windows. It was more than 20 years ago, but I think the idea that you need to copy in one place, then go to some other place and paste there, still sometimes confuses her in the context of files, even though she does not have any issues with that when copy-pasting texts.
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 it a desktop with icons or menus, or a command line with a prompt? For me it's a terminal, so I prefer TUI apps.
...but not Midnight Commander: it's an outlier in your list, a tool that actively prevents you from learning the way how things work in terminal. Same for all attempts to invent a UI for git.
> 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.
Exactly this. The non-composability and non-standardization of GUI tooling is my main issue with them ; having the same toolkit available to solve every problem takes some doing but is ultimately more efficient.
That being said, it's a hard sell. It's not easy to grok the simplicity of the commandline tools until you've used them to solve what would otherwise be an intractable problem.
Yes, any GUI that doesn't provide any kind of RPC or composable API layer is almost a lost cause to me. I'd personally refuse to use it. With a caveat, though: on MacOS, which I absolutely abhorred in the beginning, having now been required to use for work (instead of Linux), I found the beauty of OSA (Open Scripting Architecture). Holy mother of Turing, I wish there was anything similar on Linux. I had no idea how amazing this thing was. I can fearlessly dig things out of even complex UIs for automation in ways that I can't ever dream to be able to do on Wayland. That still not an excuse - any serious UI should provide a functioning API.
> — Well, in my FrobnicatorStudio, there's a shortcut Ctrl+Alt+So for that
When I get those people typically I'll switch to Emacs (it's always open), use dired and rename 20 files at once, using either a keyboard macro I make on the spot or using a regexp replace.
This usually not only get them to shut up for good, they also typically then see me as the "computer wizard".
I demo'ed some terminal (piping command calls) and Emacs tricks to a very good dev who's using JetBrains tools. He got it and was very respectful... He told me: "yeah I can see the appeal, but it's not for me".
The CLI / terminal / command line utils won: LLMs have proved that. The discussion is over.
"I don't think I've ever had" stance, about any problem is not a good argument. At some point you'd face them and the mental models shaped by the tools you choose, often force you to deal with them in a way that often creates small, subtle micro-annoyances. You won't even consciously notice them, yet they add up. You get constantly distracted, every time by small bits, your focus budget gets eroded without you even noticing it. You feel inexplicably tired at 3PM without any meaningful work getting done for the day.
In psychology there's a term called "emotional bank account model" - small chronic negatives silently drain the account, so by the time something "big" happens there's no reserve left, even though the big thing isn't the actual cause. That is I think why our field has notorious "burned out programmer" problem. We can't even explain the reasons - because the accumulation is diffuse and undramatic, people lack a narrative-worthy explanation, and the real cause is chronic negative-affect accumulation.
That is why it is important to seek ways for the "gratified productivity" where no matter how small your problem seem to be, you can find ways to automate it nicely, ideally reaching for solutions quickly. Tools do shape your mindset. Expertise changes what affordances you perceive. Experienced Emacs user when stumbled on a problem looks at a workflow and literally sees the seams where it can be pried open, the way a climber sees holds on a blank wall. Novices often don't even recognize the wall. It's not that Emacs "has this capability, but other tools don't", it's not about specific features, it's about the mindset. Experience awk hacker for the same "rename 20 files problem" may combine a complex looking single-liner and say: "who needs Emacs schmimax? ble...", the difference in the approach, but the result is not just the output but also the mental gratification - small problem fixed quickly. While a newbie would be doing it manually, and maybe even solving it faster, but there's no gratification. We are species of "tool builders" - we get excited from using tools, sharpening them each time. Menial tasks don't leave that sharpened mental edge, they "blunt" your mindset and accumulate frustration.
I've had to batch-rename files many times over the years. That means:
1. I do it manually over however many minutes. Works if there aren't too many (especially if the pattern is too complex to trivially automate).
2. I make a Python script for it. No way I'm renaming a thousand files by hand.
3. I don't do it. Too much work. The problem lingers forever.
Or these days,
4. I make an AI datacenter eat another town's water supply.
I've never used Emacs. I tried vi(m) nonconsensually and had to google how to exit. A while later, I tried it intentionally and hkjl navigation didn't work because I use a custom keyboard layout, so I never touched it again. Sublime Text and its many cursors for the win!
I'd love a way that isn't miserable to do such a common basic task.
It opens the list of filenames in a given directory (or set of files passed on cmdline) in an editor of your choice, and then you use your editor to rename them; the changes get applied when your editor is closed.
> I'd love a way that isn't miserable to do such a common basic task.
The problem is that you actually describe a family of tasks which is not basic. The "iterate over files, select the right ones and apply rules to rename them" part is common; the problem is that the rules vary broadly in kind and complexity, and you haven't figured out how you want to specify them (some ways will be limited in the complexity they can handle.
(Usually the selection of files is trivial; when not, we can fold that complexity into the change rules, and emit null changes in some cases.)
If your selection rule is simple enough for Bash globbing, and your per-file rename rule is simple enough for, say `tr` to handle, then that's trivial to wrap up as a Bash script (or function). In fact, you could write the Python script such that it just accepts a single input filename and outputs the changed version, and handle the rest externally.
> I've never used Emacs. I tried vi(m) nonconsensually and had to google how to exit. A while later, I tried it intentionally and hkjl navigation didn't work because I use a custom keyboard layout, so I never touched it again. Sublime Text and its many cursors for the win!
I'm not really clear on how text editors are supposed to be relevant to batch file renaming. If trying vi(m) the first time wasn't your idea, then there should have been someone else around responsible for guiding you through it. But the variations I've tried had arrow-key navigation configured by default (and `vimtutor` explicitly tells you that it should also work); you really don't have to learn hjkl, which exists largely for a combination of historical reasons with a lot of back-filled justifications. (I would have used ijkl, mimicking an arrow-key layout.) And everything can be remapped in the config files.
The only case I can imagine is when I rename a Java interface and want all implementations to be also renamed accordingly. I can do that in 1 second in IntelliJ. With dired on emacs that would not be possible at all and I would need a tool that can find all implementations first: that requires a LSP on emacs, and then from a xref buffer, not sure how I could rename all classes and their files at once. Probably would need to be manually done? Anyone knows how to do it in emacs with one command?
Java implementations sometimes take part of the name from the interface they implement, for example, `FooRunner` probably implements `Runner`.
My example was that I renamed `Runner` to whatever, `Executor`, and IntelliJ will ask me if I want to rename also implementations (in this case, it would show `FooRunner` -> `FooExecutor`).
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 when I need to ssh, or am using Termux on my phone.
> The proper argument here, probably, is this one: the terminal, with its way of combining small CLI tools into pipelines, covers infinitely many use cases,
Extensible GUI tools (Sublime, VSCode, etc) cover infinitely many use cases too, except they offer more reliable and reproducible runtime environments.
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.
But at the end of the day this only matters for novices. After enough experience with them, no matter what you use, your productivity bottleneck isn't going to be your tools (unless its ed...).
> 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
But this only speaks about what some GUIs lack, it's not necessarily true that GUI apps can't be composable, it's just that seldom they are made as such. The true potential of a GUI app is much richer than what terminal currently offers (unless it starts to receive capabilities usually present only in GUIs, as we can see with some of them - but then it's a GUI with the severe terminal restrictions, a strange beast).
I have a similar relationship with wireshark. I understand the use of a live capture and display and the attraction of the click GUI.
But at some point I just figured I was wasting so much time in there. Switched tshark and jq or good old bash/awk/grep and gnuplot, back to the command-line, then python for batteries, still using the output of tshark... and then ended writing a pcap(and ng) parser with ethernet-ip-udp/tcp and a full java IDE and never went back. I went the same meandering path with every data capture and exploration tool I had to use repeatedly.
I feel I'm not the only one having this repeated sequence of tooling improvement, hopefully there is a well named scale to describe it.
I've never managed to make the terminal work for me. But I've been using windows since I was like 5 and I'm really bad at remembering shortcuts besides a handful of ones I use every day.
> When you reach that point, you will be, on average, much more productive than an average GUI user
How sure are you about that? I often watch streams of people using emacs or vim, with totally custom setups and it seems like a wash to me. They look like wizards doing some stuff, and then other things seem slower than my own workflow.
That's a weird thing to say. GUI slows down me A LOT when I sometimes have to switch to it from my terminal for whatever reason. Where did you get your "absolutely no one" data point?
You should read again what I said. Do you think that simply using GUIs makes anyone less productive? You can’t think of any cases where a GUI is definitely better for a task than a terminal? If you think that , consider why the vast majority of people are using GUIs for everything, and only a tiny minority is using terminals for everything. It’s ridiculous, yes, to imagine you would be more productive if no GUIs existed (you just misunderstood my point).
I reread your original comment. It would have been better if you had included those small details that, for some reason, you left out. In my opinion, you simply failed to get your point across.
Anyway, my point stands. "Absolutely no one" without any context makes no sense whatsoever. There are a number of tasks that are much, much more efficient to perform in the terminal than in a graphical interface. So no, I didn't misunderstand your point - you're just wrong.
> any cases where a GUI is definitely better
Sure I can. Not all of them are though. So be careful with exaggerations.
whoa, you can and absolutely should pipe things in and out of vim - it's natural. Emacs on this actually in disadvantage - it doesn't give you a built-in way for piping from and into buffers, but for that there is emacs piper script: https://github.com/agzam/mxp
Dunno, never had to do this. At most I might set PAGER=vim which means maybe something else is piping for me. If you're piping with vim then fine, but it's not a requirement to use it, unlike smaller utils that are begging to be piped.
is not a defensible argument (regardless of what you use), see the relevant comment here¹
the bigger point is to get more precise and utilitarian control over text which I already discussed here in this thread², piping in and out of your editor buffers sometimes comes very handy.
Most programmers come to appreciate a single fundamental truth about their field way too late into their careers. That the most basic foundational unit, the substrate they need to conquer is text. Everything stems from it. We have to deal with text our entire lives. It doesn't matter where that text appears - in web browsers, in Jira, in Slack, terminal, in PDFs, Word or LaTeX documents. Code is just structured text. The feeling of empowerment and liberation when you can deal with text on your own terms is a disproportionate multiplier.
Vendors are designed to own you and ownership can have different forms. Slack.app that doesn't let you easily extract code snippets from a thread - owns you. Jira that forces you to use their imbecilic, quirky wysiwyg owns you. Note taking app that keeps the data in their db and not your files - ain't your friend. The friction is the ownership. When extraction of text requires effort, the tool has leverage over you. It's a subtler form than data lock-in - behavioral lock-in. You adapt your workflow to what the tool makes easy, and gradually the tool's affordances shape what you even think to do. Information gets buried in threads, search is mediocre, export is hostile. The "solution" they offer is to stay there longer - search in Slack, link to Slack, screenshare in Slack, summarize with AI in Slack, don't ever leave Slack. The tool becomes the answer to the problems the tool creates. It doesn't become "invisible" like the article says, you just don't realize that you're "lost" yourself in it.
Most popular editors and IDEs don't give you direct leverage over plain text either, at least not without the effort from your side. Shortcuts, popups, UI elements in the IDE at best are local drivers - you can't easily grab a thing from the outside and feed it to your LLM context in the middle of a task, or insert within a comment in the code - you have to switch, copy, paste, deal with format inconsistencies, manual conversion, etc. Then we keep bargaining what method is the best, fastest and most convenient - using the mouse or keeping the fingers on the home row, modality or complex shortcuts. All for the sake of the problem that's artificially enforced on your workflows.
Terminal-heavy users eventually start appreciating the leverage Unix philosophy grants them over text, but that's still contained within locality, they still have to constantly jump around, while eventually figuring out ways for automating some aspects of it.
Anyway, this should be a little more of a deeper discussion than a forum comment. Point is - do not give in to the status quo. Liberate your text - deal with it on your terms. Get annoyed whenever you need to switch back and forth just for the sake of finding the piece you need and moving it around - it should be instantaneous and instinctual. Like boxers moving on a ring and casually throwing punches. Long time Vim and Emacs users "get it", even though often don't follow true - some things never become gratifying instincts. Sometimes, even the opposite forms - redundant muscle memories.
I realized that I was typing the comment above in the middle of the night; finally, brain fatigue hit and I wrapped it too soon (thus some typos, sorry). That all was some "poetry." Now let me give you some concrete example cases.
1. You're typing a message to your colleague, and you're doing it in Slack, Teams, etc. Why? Why not use your trusted editor where you probably already have smart completions, quick spellchecking, thesaurus, definition and etymology lookup, translation and dictionaries, LLM integration and more.
Years ago I realized that and stopped typing anything longer than three words in anything else but my editor. But that forced me to copy-n-paste a lot, so I automated the process. I'd press a key in the middle of typing - regardless of what the current app is, the script simulates pressing Cmd/Ctrl+a Cmd/Ctrl+c; opens the editor buffer; inserts the text; I'll do editing; press a key - it goes back to the app; pastes the text. Stupidly simple, deviously efficient. Suddenly, my entire OS is my editor and my tool is "invisible" - like the article describes.
2. You're typing a message to your colleague. Now you're doing it in your editor, you want to share the url to the thing opened in your browser. What do you do? Normally, you'd switch to the browser, press another key to focus on the navbar, copy the link, switch back, paste the link. Goddammit, the url is cryptic. You, being a good teammate, want to add a description, now you have to go back to the browser to copy it. Then you have to make it into a markdown link format. Darn it. Was it parens and square brackets, or the other way around? We don't even realize how often we do this, because this simple action has become a routine. What's the point of arguing if mouse or vim or shortcuts is faster if the action is fundamentally flawed? For me, inserting a link in the middle of typing, from any tab in my browser is within a keystroke. It intelligently and properly formats it while retrieving the document.title.
3. Your colleague sends you a message: "Hey Jon, what about FOOBAR-41234?..." You know it's a Jira ticket number. But between FOOBAR-41345 and -41234 and a bunch of other recent ones you have no mental recollection of what that number is about. You go to your browser, navigate to the Jira instance, darn thing says you have to re-login, now you're going through 2FA - it won't even let you-in unless you find your phone and confirm it. All that effort just to look at the title. We all recognize this familiar flow, don't we?
Why even deal with this BS at all? Jira, Asana, Trello, etc. - all have CLI tools, you should leverage that. In my editor, whenever the cursor stumbles on a pattern like above, it immediately fetches the ticket description and shows it in a popup. I can quickly convert the plain "FOOBAR-41234" into a markdown, org-mode, whatever link format that has a description.
4. You're looking at FOOBAR-41234, you even see the description (because your editor is smart now), but how do you answer questions like: "what are the PRs related to this ticket?", "find slack threads that mention it", etc.? That stuff should be quick and easy. Do get annoyed whenever it takes longer than two seconds to answer any of these or similar questions.
5. You are pair-programming over Zoom. Alice (your colleague) is sharing the screen, you are reviewing some big unit of work. She's scrolling through the code changes, occasionally opening documentation, navigating to different sites, etc. You just can't bear constantly interrupting her with "slow down, I'm taking notes", "please, share this link", etc. After the session you frantically try to recall, but most of it is gone now, your notes are whacky, containing a bunch of broken urls and half-typed nonsense. Three weeks later it is a complete and utter garbage. Then you spend years debating of note-taking strategies trying to figure out what "works" and what doesn't.
That should annoy you. Darn it, if I can see it on the screen, why can't the computer "see" it too? It irked me, so I hooked up Flameshot, Tesseract, and Emacs and now I can select any area of my screen and the text gets OCRed and pops in a buffer. It's not always accurate, but it is quick and I don't even have to tell Alice to slow down anymore.
---
These are just a handful of examples, and I haven't even touched anything code related. Hopefully you can already see what I meant in my post above. Do liberate your text from the tyranny of complex GUIs, do get annoyed when you have to manually retrieve any piece of whatever. You're a damn programmer, computers and computer programs should obey your command, never forget that.
Recently revamped my terminal setup after all IDEs have just gotten painfully slow to work with (the debugger + git integration in intellij was my last moat, but spend some time to learn nvim-dap + lazygit and it's excellent). AI has been immensely helpful here too to figure out the long tail of weird config gotchas.
Also thanks confirming the multiple cursor YAGNI for vim, could never wrap my head around needing it in the first place.
> usually because they don’t realize how much more productive keyboard navigation is than reaching for the mouse a lot of the time.
In a large number of cases people who say they are more productive have never measured it. They have no idea if it is true. There are been many competitions between keyboard and mouse navigation over the years. Depending on the details of how the test is written one will win or the other, often by a significant amount, in many cases the loser is the one that user said was more productive before seeing the real results.
I think if you need to measure this kind of thing, you're missing the point in the first place. I don't want to be chasing some absolute productivity metric, I want a setup that doesn't break my flow. For many people, reaching for the mouse breaks their flow and feels wrong, which is oftentimes worse than being a second slower, because it takes you out of the mental frame you were in.
For me, using my mouse while I'm working feels natural, so trying to change my workflow to learn how to navigate everything by keyboard would be a huge amount of extra effort just to maybe possibly save a little bit of time in some situations.
I think this is unhealthy self-handicapping. Your "flow" is just habits, things you've taught yourself to do. You weren't born with the ability to use either a keyboard or a mouse, there is no "natural" or "intuitive" way to operate a computer. It's all 100% learned behaviors that can be altered.
>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 power of the computer behind a set of fixed clickable options. That is a pretty poor interface.
> 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. That is a pretty poor interface.
You continue to argue for my point. OP was claiming that measured efficiency does not matter because it's about "flow". I argue that one can teach oneself to flow differently, the commands can be learned.
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.
We are not talking about keyboard shortcuts (key combinations that you press to do something) by the way, and about the actual typing of commands in the terminal/shell/repl what ever...
Reaching for the mouse doesn't break my flow. It makes the thing I was doing invisible in the flow. Keyboard shortcuts require me to think, which makes it FEEL like I'm doing something, and that something is in the flow so it feels like I'm productive. However the mouse doesn't even enter into the flow at all, I just do the thing and get on with the real work without breaking flow.
Again, there is no universal correct answer. Sometimes the keyboard really is better. However sometimes the mouse really is better and because I'm proficient in it I don't break my flow to use it.
I been doing a lot of Bender. Keyboard on left hand and Mouse on right. The keyboard shortcuts in Blender are excellent, but there are _many_.
I know this sounds silly, but what really breaks my flow is moving my mouse from the middle of the screen where my model is, to the top of the screen where the menus is.
I bought a Stream Deck which is a programmable keyboard with 32 buttons and a screen behind them. I've programmed my most common commands there, so I can just reach across with a finger and smash a button rather than move the mouse away from the center of the screen.
It saves about 1 second, but really makes a huge difference.
I use blender a lot too. I bind space to search and then use that instead of shortcuts for pretty much everything that isn't the few shortcuts I've memorised (and g/s/r xyz etc)
Most knowledge about human computer interfaces was obtained through metrics.
Groupings, menu bars, corner buttons, context menu orderings, and other things didn't just spawn into existence. There was a time where human pattern recognition and physiology was an active consideration for user interfaces.
One of the reasons mouse input became popular is precisely because interfaces were created to be easy to use with it.
All of this brings me to my questions: Why do you reject measuring how good an interface is? Or given your dismay over keyboard based workflows, why do you think they would win most of the time?
I'd wager that if actually tested, in only a few scenarios the keyboard would win, while hybrids (with both mouse and keyboard input) perform best for most people.
https://danluu.com/keyboard-v-mouse/ - """The widely cited studies on mouse vs. keyboard efficiency are completely bogus ... <testing, reading, etc.> When I look at various tasks myself, the results are mixed, and they’re mixed in the way that most programmers I polled predicted. This result is so boring that it would barely be worth mentioning if not for the large groups of people who believe that either the keyboard is always faster than the mouse or vice versa."""
Sigh, I don't know why a blog-post against micro benchmarks should alter my opinion on this topic.
There are more metrics than just "speed" regarding an interface. You also want it to be discoverable and visually distinct.
How someone interacts with your software is absolutely measurable and the results will vary by how a user is likely to use it in frequency and variety of function. Someone that needs to do something specific with your software every day will interact with it quite differently than someone that just hops onto it every now and then to do a different task each time.
All of this requires actual studies and observation of users over time. Micro benchmarks have no space there. Testing how fast a find and replace is is meaningless. In case of software for writing text you'd test a user actually writing prose, changing font sizes, title colors, and maybe replace a word over the file too. You would have commonly used functions mixed in with less commonly used functions over how the software is used under a specific use case. (For example, writing text, revising text, and polishing a graph representation are different use cases)
This is not easy, which probably why it's not done all too often, but it is also most definitely unlike a micro benchmark (which your link argues against).
All that being said, I don't know of any person strictly pitting mouse against keyboard when testing UI for possible improvements.
I think that's a pretty reductive stance to take. Keyboard nagivation is more productive _if_ the primary use of the tool is text-based. In a word processor, an IDE, a file manager, or anything else where the primary mode of interaction is reading, typing, and processing the things you've read and typed, keyboard navigation can be demonstrated to be faster and more natural _only if_ the user has taken the time to learn the shortcuts.
For tools that are mainly for non-text visual information, then the keyboard versus mouse debate is much more heavily weighted in favor of the mouse. Even then, there are times when effective keyboard shortcuts are far more useful than menus and icons. Take any CAD or 3d modeling software as an example. 90% of what a user does will be interacting with visually-presented spatial data, but even then knowing the shortcuts for changing tools or modifying a tool's settings will make you much faster and remove the need to constantly navigate nested menus of options.
Drawing/Painting and Cad modeling is very much like games. One hand on the keyboard and the other on the mouse. This mixture can be also done well in other programs. I only bother learning shortcuts for daily tools, not something I use every blue moon.
What I take issue is with tools that make them hard to use with low contrast between widgets or shortcuts that does not work if a text input is focused. Also tools that forget they have a primary usage and wants me to know everything at once (notifications, big action buttons, guided tours and what not).
That's because it's practically impossible to collect objective data here, i.e. without confounding factors.
A product where the user spends 99+% of their time reading/consuming is almost certainly easier to use with a GUI. The market settled on thumb-flicking for doom scrolling instead of a button or scroll wheel interface, for a reason.
A product where the user spends 99+% of their time writing is almost certainly easier to use with a keyboard. Most sane people do not write essays on their phones with two thumbs; a keyboard and a proper word processor are preferred.
Most products fall somewhere in the middle. Most products have multiple interfaces, some primarily for consuming information and some primarily for producing it, and thus would find different inputs more productive in different modes. When people claim that they find one input type is more productive than the other, most likely is that their particular use-patterns fall more in-line with the one most aligned with their use-patterns.
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] They might have a personal favourite, sure, but would also be able to tell why other people prefer other tools.
I am afraid this is one of those arguments borne of ignorance whereby one is has never given a proper chance to software they are unfamiliar with.
1: to me the mark of a greybeard that has been around a while is a vague dislike of every software and any promise of improving such software. In the long run, every piece of software tends towards mediocrity.
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 the tool he wanted. His basic point however still stands. If you are making something for someone else to use then making that tool invisible to them is a powerful property.
If people find vim, emacs, or whatever genuinely good and productive, I’m not going to criticize them for using it. People are most comfortable with what they know. But for the people I am discussing, that same familiarity blinds them to their tools’ flaws, and leads them to celebrate those flaws, flaunting them as games.
Sorry, I find the Linux desktop thing to be an accurate generalization. There's scarcely any usability advantage over there unless someone has specific requirements. The dominating mindset there isn't to make stuff just work, and it shows.
Vim, not so much, maybe I don't know enough who use vim besides myself.
> I am afraid the author confuses familiarity with proof that his tools are better.
Literally NOT what I was implying or even said anywhere. Quote me where I said anything like that.
To quote myself:
> What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great.
This has nothing to do with why I or another person one tool over another, but rather treating the flaws as if they are things to have a puzzle game to work around.
People don't use vim because they enjoy puzzle solving. I don't even know how you got this conception. People use vim because they are effective at editing with vim, period, just like you are effective with Sublime Text.
People don't use Linux because they enjoy tweaking config files and everybody else has too busy a life to do that. That's a silly misconception and veiled attempt at feeling superior at those time-wasters.
> rather treating the flaws as if they are things to have a puzzle game to work around
Case in point.
Good tools are indeed invisible, but the arguments the article is built on are very shaky and honestly just sound from someone that didn't spend much time with other tools, but still has strong opinions about them.
I do know quite a few people who use vim because they do enjoy the puzzle. So there are absolutely people as he describes. Saying that there aren't people like that just undermines your point.
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.
> If people find vim, emacs, or whatever genuinely good and productive, I’m not going to criticize them for using it. People are most comfortable with what they know. But for the people I am discussing, that same familiarity blinds them to their tools’ flaws, and leads them to celebrate those flaws, flaunting them as games.
> People don't use vim because they enjoy puzzle solving.
I didn't say that either nor even imply it, and you know that when you quote me afterwards. So huh?!?!
> People don't use Linux because they enjoy tweaking config files and everybody else has too busy a life to do that.
A lot of people, including younger myself, got into Linux and Android BECAUSE it was configurable and customizable. And even played around with all of the customizations because it was fun to do. But it didn't really make my general experience better because I was forever trying to correct something I should have to correct in the first place.
I am not sure how much clearer I can be in the article or in my replies to comments.
> I didn't say that either nor even imply it, and you know that when you quote me afterwards.
You come across that way when you describe your interactions with Vim users talking about how they use macros. (Which, incidentally, doesn't match my experience at all.) More importantly, your comparison of "Vim users do this with macros" to "I could do this with (proper) multiple cursors" doesn't seem apt.
Perhaps it could possibly make sense if we had at least one concrete example of "this"; but the most obvious thing to do with multiple cursors is patterned editing of multiple matching text fragments, and Vim users would (or I would, at least) normally do that with a /g regex. To the extent that macro is useful, it's because multiple changes are done (such that the dot command wouldn't help), and if that's too complex to do easily with regex then I can't imagine that the simultaneous changes with multiple cursors could actually get it right anyway.
More importantly, though: the real point of a macro is that, having recorded it, you can persist it even across editing sessions. You also mentioned the possibility of writing a script; a macro is that, just in a very small, focused language.
> A lot of people, including younger myself, got into Linux and Android BECAUSE it was configurable and customizable. And even played around with all of the customizations because it was fun to do. But it didn't really make my general experience better because I was forever trying to correct something I should have to correct in the first place.
This doesn't match my experience at all. I play around with customizations because I understand that the default couldn't possibly have anticipated what I wanted. But more importantly: I use multiple user accounts on my system (all for myself; I did this on Windows too) and what I appreciate about Linux is that I can duplicate configuration files instead of having to navigate through UIs again and click a ton of options (perhaps following notes on what to click; I never descended to the AutoHotKey level of madness, though).
You can be less of a coward and reply to my comment, since you are talking about me personally, rather than mentioning me by name elsewhere.
gingerBill and I were disagreeing, sure, but at least we were arguing on topic. I fail to see what is insightful about your comment than just pointing and saying 'get a load of this guy.'
Casting aspersions at others behind their back, and then claiming "I wasn't talking to you" when called out for it, is not a productive or civil mode of discourse. Please don't.
It’s weird how much the author fixates on Vim being “visible” and implies multiple cursors and features in Sublime aren’t. Just because your brain is trained to not think about it anymore doesn’t make it any less visible.
Multiple cursors aren’t a native feature in many tools, it is still something to learn how to use, let alone effectively — just as Vim key bindings are. Plus, vim is more than just a TUI choice for terminal-only users, it’s key bindings for people that have learned that a keyboard is a natural extension of themselves and would rather not jump back and forth to mice repeatedly — just as “multiple cursors” can be to a sublime user of 15 years.
That's not what I was saying. I used vim macros specifically as an example, not Vim as a whole.
> I’ve had people tell me how “fun” it was to build a macro to handle some one-off text-refactoring problem. But when I looked at what they were doing and how long it took, my honest reaction was: I could have done that in Sublime in a minute with multiple cursors, or just written a quick script.
and
> What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great.
If you can affectively use vim macros, then GREAT! But if you cannot, even with using vim for decades, then please don't advertise them as the "fun" part.
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 it (usually tied to the next item in the search list).
Edit (after reading the article).
Both vim and emacs (which have the steep learning curve) are aimed at power users. It’s best to compare them to professional tools like CAD, DAW, industrial appliances,… The friction when learning is because a lot of users don’t know what’s possible to do or even have the kind of problems that experienced users do (or they fail to perceive them as issues). After a while, it becomes like an extension of your thinking and the tool disappears.
Exactly. And I'm no purist - I'm happy to use "dot" with a mouse if I want to easily repeat an edit in tens of places if they're not nicely aligned or searchable.
One of the things about Emacs and Vim is that you have commands that does things. They all have the same conceptual model. In vim, you have the text objects, the motions, and the counts (and more advanced ones like line and pattern addressing). In emacs, you have the point, the mark, and the arguments (including the universal one) (the advanced ones are which modes are currently active). That’s mostly the internal state that matters when you think about an edit which changes A to B.
You think about the evolution of the internal state and the suitable commands just appears, just like you think of an idea and the suitable words appears. Learning commands is like expanding your vocabulary, not learning how to speak. Learning how to speak is internalizing the aforementioned conceptual model.
> 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. So the multiple cursors approach is better not because it's a different mindset, but it produces a different feedback loop to correct mistakes.
If you still prefer the macro approach over the multiple cursors approach, then you do you. But as an example in the article, I have seen people think they are being productive by their own standards, and they really aren't.
You're over-fixating on the misuse of macros and generalize that to make a statement about Vim [1], almost as if that's the only useful feature in Vim. There are more basic editing commands that are much simpler, quicker, and powerful. It's what is actually used most of the time.
Also, getting bulk editing perfect, including the edge cases, is inefficient regardless of the tools you use. For the majority of those cases, I would just combine simple search and replace (cgn), dot repeat (.), and undo plus skip (un) for the edge cases. Then jump back (N) to the edge cases and make manual edits. It's quick, provides instant visual feedback, and requires less cognitive work than trying to process it all at once. And that's the approach people likely have in mind when they mention dot repeat.
> 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).
> I’ve had people tell me how “fun” it was to build a macro to handle some one-off text-refactoring problem.
I can't relate, either as a Vim user myself or having heard other users.
To the extent that it happens, it's surely because the macro can be seen as a sort of programming. Vim offers you two esoteric programming languages, if you want to see them that way: vimscript obviously, and the simple concatenation of Vim commands. But any system consisting of a text editor plus a way to record and play back its commands gives you the latter. Vim isn't doing anything special to create that second esolang; it's just bundling the playback mechanism.
But that rather is the point: creating the macro is as much "scripting" as actually using vimscript is. Not only is it recorded in an at-register, but it can be stored as plain text in a vimrc file. It should be compared to "written a quick script" and not to "used multiple cursors"; and any sensible Vim user would have a different approach (commonly powered by :%s/foo/bar/g , perhaps with backreferences) to the cases where Sublime's multiple cursors shine. (Yes, you can use visual-block across multiple lines if everything lines up; and yes, it's inferior to a real multiple-cursor system; and no, I don't think I've ever personally had a use case for it.)
There are people who reach a level of proficiency where they enjoy the challenge of an intentionally difficult to use programming language. Vim macros are accidentally a programming language, and definitely not intentionally difficult. And using them to "handle some one-off text-refactoring problem" is entirely missing the point, and a sign that one has more room to grow in proficiency and a lot more room in wisdom.
In short, the people you've heard this from should not at all be taken as representative of Vim users.
What I find especially weird is that I'm not sure I've ever heard anyone describe vim as a puzzle that's fun to solve. The most common sentiment is that it has a learning curve, but ends up being worth it.
My intro to vim was a guy using some kind of web browser in vim, or maybe it was a browser with vim controls, and I was like wtf. But I did end up using vim for just code/text editing without any fancy macros, it was worth.
I don't think of vim as a puzzle, but I do use it because I find it fun to use in some ineffable way. Note that I also don't claim that it makes me more productive; I use it because it sparks joy, regardless of however productive it makes me.
> multiple cursors really are better than macros 99.999% of the time (since they give direct visual feedback)
I don't know what he means, vim macros also give direct visual feedback while writing them. You just edit as normal while recording, and replay those edits later. I think it is technically possible to write a macro without seeing the live effect on the text as you write it, but I've never done that.
I looked up multiple cursors out of interest, I guess the advantage is that it's one interface that is easy to explain. I would use multiple vim commands to replace it in practice.
I'll agree that multiple cursors are maybe better than macros for most of the things that someone would use multiple cursors for, but usually I wouldn't use macro's.
But I think most of the things I do with macro's cannot be done with multiple cursors.
I would be very interested in being proven wrong, if someone has some examples of "this is where multiple cursors are great, and vim doesn't have a good alternative".
> You just edit as normal while recording, and replay those edits later.
And there is the problem. The first time you do the edit, it might be fine, but when you make a mistake in the edit, you then have to go back and correct all of the cases. With multiple cursors, I am seeing instant visual feedback on all instances of the cursor at once. I am getting literally 2D spatial information, compared to the 1D spatial information per each replay. The multiple cursors approach is better not because it's a different mindset or whatever, but rather it produces a different feedback loop to correct mistakes.
If you still prefer the macro approach over the multiple cursors approach, then you do you. But as an example in the article, I have seen people think they are being productive by their own standards, and they really aren't.
Agreed. I used to enjoy vim macros, but ever since switching to Helix I reach for its multiple cursors all the time and barely use its macros. But that doesn’t mean multiple cursors don’t have a learning curve, I still need to think of he method to place the cursors in the right places.
> The clearest sign a tool is serving you is that you stop noticing it—it becomes invisible.
It is because you are already very familiar with and accustomed to this tool.
The main meaning of the author probably is (from one article):
We need to remember that the purpose of using tools is to solve specific problems and achieve goals.
No tool is perfect. When using the useful functions of a tool, we also need to tolerate or ignore some of its shortcomings. Don't seek out or switch to a new tool simply because of some insignificant flaws. In the process of selecting and using tools, don't have the perfectionism, and always keep the goal in mind. The important thing is to master the useful functions of the tools to quickly, effectively, and efficiently complete tasks or goals, thereby significantly improving efficiency and productivity, rather than constantly complaining, switching tools, and wasting time and energy.
For the tools we choose, one must become truly familiar with and proficient in their use, continuously customize, modify, and improve them, and strive to use them to the fullest extent, thereby significantly improving efficiency and productivity, and solving practical problems and achieving goals faster and better.
For example I've been using Jujutsu exclusively (as a Git frontend) for years and I don't think about it, I just use it. I reflected on this couple of years. It's existence is completely transparent to me.
I, however, don't agree with sibling commenter that it's a function of time spent with X though. As a counter example: Emacs was my go to editor for 15+ years, last 2 years - because reasons - I was switching between Neovim, Helix, Emacs, Kakoune. 6 months ago I settled with Kakoune.
Even with many years in Emacs, I still tweaked and tuned it. There was always something to do, change, understand. I actively thought about Emacs.
With Kakoune after initial "set me up" phase, it's just as transparent as Jujutsu. Sure, I made complex plugins (for searching, highlighting unbalanced parenthesis and even a GUI wrapper called Kakvide). But the difference is that in Emacs the driver was the tool itself and in Kakoune it's always "I wonder if I can do X".
And so I believe that Kakoune is better tool than Emacs as it's more transparent to me even with a big time difference in usage.
As someone deeply invested in Emacs who had a short fling with Kakoune a few years ago I'm super curious how did you manage the transition? I have lots of notes in org-mode and rely on packages like Magit and so on, due to that I'm always wary of the fact that a lot of my computer use flows through Emacs (for better or worse).
Also one thing that intrigues me about Kakoune is the possibility of writing CLI utils in whatever language and then calling them from Kakoune. The same can be done from Emacs but generally you'd go for Elisp instead.
I've also found I miss fancier text decoration like subscripts, bold, italics, underline and mixing monospace with another font when not using Emacs.
Obviously Kakoune is much simpler than Emacs, so face variability, very interactive UI is not there (though there'd be nothing preventing writing it, but I doubt anyone wants it enough).
As for transition - I always was somewhat of an UNIX guy, so I replaced Swiper/Occur/Consult with delegating to shell. Kakoune has just enough utilities to create a on-keystroke-updated-buffer so I'm happy with that. In some languages I go as much to create "find functions" special mode - composition with shell is easier than Lisp - I rarely have to read documentation.
For Git I use Jujutsu (so I stopped using Magit long time ago) but Kakoune has a very nice "!commmand<ret>" utilities. It's nothing more than a "C-u M-!", but positioning of feature differs.
So the transition is mainly about delegation, not sticking to one application, but instead finding utility that does it and use that instead.
jj required a very weird mind shift in how I work, but since it’s clicked I’d never go back. Occasionally it makes easy things a bit awkward, but the amount of hard things it makes easy is incredible. Several patterns of work have become common for me that I would never have done before.
GUI tools were better in the 90s when interfaces were more standardized, and I think the "invisibility" factor was a big part of it. I don't want to have to learn a company's whole design philosophy system because they thought building a packaged web app was "cooler" than using a standard widget toolkit. I find myself using the terminal more and more as time goes on, because I find the total friction to be less when things are predictable. I'd probably not have left the GUI world if we were all still using some modern equivalent of user32.dll.
A corollary to this I've experienced (and observed in many others) is that maintainers of good tools will very often have a much more negative perception of how users collectively view their tool than how they view it in reality. It can be hard to tell the difference between "10 users complained to me today about bugs/missing features and 9990 used it without issue" and "10 users complained to me today about bugs/missing features and 90 used it without issue", despite there being a huge amount of effort needed to go from having 90% user satisfaction and 99.9%.
I have a strong suspicion that this is a major factor in why so many open source maintainers experience burnout; the unhappy users are going to be more visible than the happy ones, and the fraction unhappy new users needed to produce the same volume of bug reports/feature requests goes down with respect the to rate at which new people start using something. This essentially creates an illusion to the maintainer that no matter how much they work to improve things, nothing they do has made a difference in the overall quality of what people experience, and that saps the motivation to keep going.
I don't really have a good solution to this problem. The only obvious answer is to be more vocal with praise when something works well, but that's the type of collective action problem that tends to not really ever happen in reality. I've personally tried to go out of my way to give frequent and enthusiastic positive feedback when something works well for me, but unless everyone starts doing this, I'm not going to be able to make too much of a difference.
"We notice the person who is for ever bowing and fussily servile, and perhaps say, How humble he is! But the truly humble person escapes notice: the world does not know him."
> The clearest sign a tool is serving you is that you stop noticing it—it becomes invisible. You don’t celebrate its flaws because you’re not turning them into a hobby, rather you just get mildly annoyed and route around them.
I think this is more dependent on the user than on the tool. Surely, different tools will attract different users and we can probably measure strong correlation.
I also think this position lacks balance. Your tool is never perfect, sometimes you realize you could improve it, and you should balance implementing the change with the effect it'd have on your habits. Sure, the longer you use your tool, the smaller those changes are, but your usage evolves throughout your life, and it's only natural that your tools do so to.
Only tangentially related, but this is why I gave up on fountain pens. They are cool and elegant, far too cool to be a practical tool for me. I realized this at one time I was in Bonn; I was thinking deeply about a problem as I was holding this wonderful Sailor Pro Gear in my hand. At some point it slipped, fell on the desk and bent the nib sideways, a total disaster. That broke my stream of thought and ruined my day. Nah. Tools need to cater to me, not vice versa.
Do people have fun building vim macros? Vim macros are awesome because they don't involve reading manuals, memorizing obtuse key commands which you never use on a regular basis, or understanding weird configuration lines - you just use the editor the way you normally would except you're hitting record. Vim's power is that I can be editing, notice I don't have something, make it in 2 minutes, and then get back to more normal work. At least try to understand the thing first before criticizing it?
Running tests is a good example: do you want to run them from your IDE or do you want to run tests in the terminal?
The IDE folks praise the simplicity of having one tool which can run tests quickly without requiring added context and with having other IDE features able to load test context quickly.
The terminal folks praise the modularity, at-will configuration, and transparency. You do things the way the rest of the community does which makes it easier to get support and debug when things go wrong. Tests become a small tool you can reuse in other contexts (git bisect, watch commands, CI)
“memorizing obtuse key commands which you never use on a regular basis” is exactly why I prefer Emacs over vi(m). The default configuration on Emacs works like most other contexts—I can just use the arrow keys to position a cursor and type.
And then, at least on the Mac, some of the basic commands in Emacs carry over not just to the terminal, but to things like text input windows in Safari and other Mac-assed apps so I can almost always use ctrl-a to go the beginning of a line, ctrl-e to go to the end, ctrl-k to delete to the end of the line and sometimes also I get esc-del to delete the previous line although that works in terminal, but not a Safari input window (and escape gets captured in IntelliJ’s terminal which kind of stinks).
I do feel that common config across a team is always a good thing. I’ve been the only IntelliJ guy on an Eclipse team and the only Eclipse guy on an IntelliJ team and both cases were worse than conforming to the convention.
Every time there's a post here on git and I read the comments, I keep thinking of all the years I've used fossil and how it's been completely invisible, in the background, letting me get ahead with my work.
Invisible work doesnt lead to promotion, hence FAANG companies stopped making invisible+good tools, if things are invisible they get deprecated or stay in KTLO and eventually die
I think this missed the emotional experience of using a tool.
My kitchen knives are decent knives, but no hand-forged Japanese masterpieces. Using them is a joy though, because I have an ingrained understanding of their ergonomics and how they cut.
I remember how clumsily I handled them at first. I take them to a sharpener regularly.
That experience of built-up familiarity puts me into a state of mind where I feel competent and joyful.
This is also true for my mechanical keyboard and some reference books I keep around my desk.
They are not necessarily the best possible tools, but they’re gateways to who I am at my best in different disciplines.
I think of "invisibility" as a way of removing unnecessary friction and the author doesn't quite drive home that point effectively.
Good invisibility is like well designed roads. Smooth, clear markings, adequately wide or narrow for the desired speed, easy and obvious signs. Unbothersome and pleasant. Drivers simply drive, rather than get bothered by, "gotta avoid the pothole. Here's comes the bumpy part. That blindspot, I gotta slow down for way too much. Unseen pedestrians pop out here."
This is where invisibility in interstate highway regulations are obvious.
When I see TUI vs GUI comparisons, it distills to friction for a given context/workflow.
I worked in a restaurant with a micros system. It was a very easy to use GUI that was touch screen button driven. A 1 person order could easily be entered in 6-7 button pushes in 2-3 seconds to a seasoned operator: drink > coke > dish > steak > medium > a1 > submit
The beauty with micros was that it reduced the typical navigate > select > add > back-to-navigate workflow into 1-2 button presses with a receipt-like tally providing immediate state feedback.
In this scenario, telling a user to get into a terminal console and type "cd Foo; ./add ketchup" would violate the invisibility principle. It has nothing to do with TUI or GUI.
To me, good tools get out of the way, in the given context. Micros did that.
CLI users are in a CLI flow, thus introducing a mouse to a keyboard workflow violates the invisibility workflow. But for a GUI user to hit up the terminal violates their flow.
Ultimately, all workflows are in search of a faster/less-toilsome feedback loop to the desired goal and tools are in service to the loop. Well designed tools with rabid followings understand through usage where to add friction, and where to cut toil and I'd argue this is where CLIs shine with decades of refinement of the same tool chain.
GUIs are a, it depends on how composable or self contained the given problem for a GUI interface is.
But yes, tools should be invisible. How they become invisible depends.
Interesting how all of grep, sed, ls, cp, mv, rm, cat, pwd, chmod etc are well over 50 years old and get used more than ever today. Claude code owes at least some of its success to the well established and solid unix toolchain
What is a good tool that's invisible? I'm genuinely curious. All tools I've used are either simple and heavily limited (so, not "invisible" because hard things are hard) or powerful but heavily specialized (so, not "invisible" because the learning curve is very evident). I feel the trade off is inescapable.
A good tool is invisible such that it is highly opinionated and nails the 80, 90, 99% use cases in terms of making assumptions regarding logical defaults.
Restated, the tool understands the process and what a “good” result/outcome looks like. It correctly presumes relevant and important information (especially given the current stage of your full task), and can “fill the gaps” between start and finish.
A good tool can distinguish between what you wanted, what you thought you wanted, and what you “should have” wanted.
A good tool makes it easy to do the “right” thing and hard to do the “wrong” thing.
A good tool doesn’t function to be understood, but to not be misunderstood.
I have spent a lot of time sitting in this question, having spent years creating design and drafting automation tools for architects, designers, and engineers in the building-design industry.
A tilling window manager is a fantastic tool that is close to invisible.
Though I don’t agree with the author. Visibility isn’t what matters, if you get comfortable with a specialized tool like a CAD software, or a game engine studio like Unreal, it’s not invisible at all but your brain will stop focusing on all the noise on your screen and you become pretty focused and productive. I live emacs, but Rider is also a fantastic editor.
Though I would love for things like LLMs to be way more out of your way, more “invisible”, more tool like. I hate the current UX of having to tame a patronizing, annoying fake human just to get things done the way I want them to be done
Many definitions of tool explicitly exclude body organs to draw a line between innate mechanisms that are inestricably linked to the body and objects used to extend one's innate physical or mental influence on the environment. The eye is not a tool, according to these definitions, but eyeglasses are.
This has traditionally been one of the points of attraction for the Mac desktop. It has a higher than average number of native applications which conform to platform conventions and are specifically designed to not stand out.
The best apps there acknowledge that they’re just one of a wide variety of tools the users reaches for regularly and avoid the hubris that comes with use of UI as brand identity. They don’t try to hog the user’s attention, vie for mindshare, or unnecessarily force the user to learn new or foreign UI patterns. They try their best to avoid saddling the user with any kind of unpleasant surprise (even if that’s just ensuring that common interactions work as expected) and they just sit quietly in the background until needed, serve the user’s purpose, and recede again.
EDIT: a lot of it comes down to small things which compound. For example, native tree views on macOS (NSOutlineView) expand/collapse entire subtrees when the user Option-clicks a disclosure arrow. This can save a ton of time and I die inside a little every time foreign toolkit apps don’t implement it.
I'd like to pick on the word 'invisible': if the user can get into a flow state with a tool where work becomes the major focus. I can argue that you can get into that state with any tool with enough practice. And sometimes that's only possible if the tool is actually visible to you as in all graphical UI bits you need are exactly where you remember them to be, exactly where your motor reflexes immediately seek and find.
So regarding proficiency. I bet you weren't as proficient with multiple cursors and all the things you can do with it when you first used it. (15 years is a long time to remember how it all started.) I could argue that all the key shortcuts and other bits you need to make multiple cursors work effectively doesn't come to everyone instantly. But with time you could and would hit that level.
Overall tho, vim is an interesting comparison to make also because sublime text also has a 'vintage mode'. I personally use it with vim shortcuts enabled. it lets me use vim motions on top of everything sublime offers. Does sublime + vim make it more 'invisible' to me than it is to you?
I generally have issues with arguments like this. It starts with a sexy phrase that projects some earned wisdom but then the rest of the supporting arguments are forced into the narrative most of the time by selectively ignoring important information. You could have just said I love sublime and I prefer it over vim because of this and that. or it could have been a direct critique of linux desktop. they would all stand on their own, even better I would argue, without being shoehorned into an overarching, simple, catchy phrase.
Well said. I do get the appeal of a somewhat fiddly tool though. Tool gives you a little puzzle each day, then you solve it! A little puzzle solved/accomplishment a day keeps people sane. Plus I think it's just nice to feel like you really understand the tool you're using and know it's 'language' for lack of a better word.
I think I've fallen into the same camp of getting tired of things not 'just working' out of the box. Now I'm always happy to use something with less friction over more.
Would I like to use something with community plugins like VS Code and configure it to be exactly what I want? Sure. But everything where I work was designed for bigger editors like QTCreator and then VS - so that's what I use because it has the least friction with our workflow. Would I like to get the absolute best hi-fi music player application? Sure. But HQPlayer is a pain to learn and configure, so I just went with the far-more-user-friendly MusicBee.
Friction is fun when you're young and have time and energy to burn. Less so once work becomes part of the normal routine.
The article topic is interesting, but the example it picks to illustrate deserve the purpose a bit. There isn’t any text editor that is really invisible. Dæmons/services are invisible. Copy-paste single clipboard is invisible. Switching displayed context is invisible.
Probably becoming skilled at using Sublime afterward become nice in some cases, but personally I never achieved the cumbersome of integrating multiple text pointers in my habits. In the rare occasion it feels like it might be useful, I know I will need to look at what are the keyboard dance moves again, and by the time I go search for it, my brain already generated several ready to go alternative paths to achieve the change. And I don’t even know if it can do things out of the box like `:grep pattern-to-select-buffer | g!:pattern-line-to-exclude:s:initial-string:target-string:g | update`. That’s already awesomely powerful for this level of granularity.
But that’s a rare case where to make the tool shine: most editor deal with full literal substitution just as well (if not better in term of UI), more complex refactors will be better dealt with with whatever decent modern IDE, and whatever more cases that want would want to cover using some more advanced macro is probably going to be just as easy to deal with a bespoke script.
Also Sublime is not everywhere. Nor is Vim or Emacs to be clear (as soon as you are outside of a Unix lineaged box). Though probably if one need to ssh in some remote box `vi` will most likely be an option, even busybox integrate one. But we are no longer talking about whole contemporary project edition here of course.
Still the underlying point is nice to highlight, melting it with editor war didn’t make it a favor.
A piano is not inherently a better musical instrument than a harmonica. You could argue that a piano is more complex and more puzzle like requiring more of an investment to learn for similar results.
A harmonica has a much lower barrier to entry and can be mastered over years of practice. So can a piano but with a lot more effort for more or less the same result. They both make music after all.
Ultimately, it comes down to familiarity and basic preferences. Pianos and harmonicas are basically the same if you've used them for long enough and you can get the same results with both (but a harmonica requires a lot less fuss and "games")
[I wish piano players would stop looking down on harmonica players - stop being so tribal!]
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.
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.
I know the link is by the creator of Odin, but I can speak personally for my passion for seamless tools. I have ever had as seamless, high-flow of a development environment as I do now using Nim with Sublime on Mint at work. Every one of these tools is intended to slide out of the way of your thoughts, and they do so deftly. I'm never fighting the tools; instead, the tools are facilitating me transforming my thoughts into compiled programs. All of my time and energy is spent formulating a sound model rather than fiddling with configs or fighting obtuse features.
> What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great.
I think it’s fine if that’s your hobby, but I agree that in a professional context one should be much more critical of their tools. Even asking “why do I need a tool for this at all?” will reveal shortcomings in processes, data structures or other tools that will reap much greater rewards if effort is put into fixing those instead of optimizing use of a quirky tool.
Theoretically yes, but in reality I have found that often it's much easier to just fix something locally or with a workaround rather than jumping through all hoops required to get somebody in another team or even another company to understand and agree with you on your (or your teams) issues, let alone fix them in a satisfactory way.
"The year of the Linux desktop still isn’t upon us (in 2026), and part of the reason why it has taken so long to get to that point is fundamental: a lot of the people who use Linux love fiddling with configuration files to reshape their system"
"part of the reason", yes, besides people's familiarity with Windows, it being pre-installed, Linux's splintered ecosystem in general, games, drivers for hardware, and so much more...
But what I want to contribute: LLMs like codex can be brilliant for custom setups, maybe not for the layman, but for the now lazy but previously-into-tuning your setup person with an itch remaining. For years I've not been wanting to tune my system, I have actual work to do. A few hours spent configuring a tool for small marginal gains is hours I could spend more productively.
Hence, Default Ubuntu with Gnome, good enough, let's do actual work. But I as I get to work more away from my desk setup (hence away from a docking station and external monitors) and more on my Laptop alone, I recently started to long for my i3 setup from years ago...
A few hours of prompting codex and I have sway set up w/ vim like keybindings, all the information I want in a task bar (I couldn't even tell you which, swaybar I think), a good launcher for applications that I like (it's graphically fancier than the simple default launchers for tiling wms), have kitty as terminal with awesome shortcuts for tab navigation, have bash aliases for saving and loading terminal sessions, no shortcuts (sway versus vim vs kitty) are in conflict, all overlap beautifully and make sense (different modifier keys, but same vim motion like fundamentals). I can simply pull the plug on my docking station or re-attach and everything keeps being fine.
So I have a custom setup, custom to me, that especially on a single screen makes me far more productive, setting it up is 10% the time it used to be, making changes in the future will be 10% it used to be, and I still a) leveraged the capabilities for customization and b) it being simple text based configs I can still leverage that going forward and c) have still the insight if needed (looking at the configs).
Codex on Linux in general feels like a super power. Due to the heavy text-based workflow Linux allows for, the Composability of terminal tools etc, I doubt working together with an LLM on setting up a system could work so well on any other system.
> What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great.
I'm confused by this because I simultaneously agree with Bill by the examples given in the article; things like "ricing" Linux and Vim, but I also advertise Odin as being great due to this friction which may be seen as a limitation.
My favorite example is Odin's approach to metaprogramming and compile-time features. Odin is featureful in this regard, but not nearly to the extent that other languages are (D, Zig, Nim, C++, C) and it may have been the deciding reason I've written far more Odin than any of those other languages.
I _can't_ just do whatever I want at compile-time in Odin. That's a blessing for people like me. I toy with the compiler. I admire languages and language design, and toying with them, learning all of the features, is an expression of that interest. For Odin, there really aren't many novel features for you to toy with. It's just not a toy at all. I don't mean "toy" in then derogatory sense, or to designate others as such. I simply mean that Odin is just not fun to fiddle with, you use it to do something.
I rarely use vi{,m} these days but I sometimes still instinctively type motions or :commands into other terminal editors (which naturally blurts them out into the text buffer). When using something like Sublime or VSCode, I'm always hunting through menus, documentation and search engines to do something simple like ":%!sort -u". Kate is a bit unwieldy—far from invisible—but I've found it to be the most frictionless editor on the market by a wide margin.
Many small reasons; changing workflows, very strange default settings (may have been fixed a few years ago?), snaggy desktop integration, because it's a pain to use at work on Windows, etc.
“Good tools are invisible” is not an objectionable thing to claim, but the example used is confusing: a power user of vim presumably feels like their flows are invisible, just like the author feels like his Sublime patterns are invisible. It’s not clear at all that there’s any “good tool” quality to tease apart between the two.
I find the best features, or mechanics in games too, are ones that fall out of greater architectural design. For example, if you've ever played popular hero shooter games like Overwatch, Marvel Rivals, or Paladins, they all have different physics engines; you can tell as you switch between the games. Which one's the "most correct" is up for personal interpretation, but they all try to grant the player affordances, abilities, and special 'tech' all while staying a simple engine for models and hitboxes to interact in.
Then there's coyote time and networking latency. All these little but meaningful details to consider on top of the base action of making a space for 'things to happen'.
When implementing a feature, I feel I'm always thinking back to when I'd get frustrated with the ways Paladins characters clip on walls more than in Overwatch, or the jarring air mobility difference between games like TF2 and the floaty feel found in the others already mentioned so far.
I want the feature to feel like it could emerge as a result of the first natural instinct from play. Like when you enter a game world and you obviously know the keyboard and mouse 'control the world', so you start there and begin mapping your intuition of the experience. It starts with the surface visual communications. The HUD, the world itself, the buttons. Maybe your keyboard lights up and shows you what keys to press (chroma sdk for example).
Then gets deeper as your experience grows. And the best features, ui, designs, games, etc. engage people who are curious enough to keep digging without enforcing the digging upon the average user.
One important thing falls out of a design philosophy like that. You never exclude a power user, and never baby a new user. It just... is the tool itself.
The Linux on the desktop one was the biggest “hell, yeah” moment for me. 99% of the desktop preference is familiarity. Since my personal computing has been on a Mac exclusively for the last 24 years and I’ve not used Windows for work more recently than 2018 (and it was sporadically the case in the decade before that), when I do use Windows, it feels like I’m typing in molasses. A Linux desktop feels like I’m typing in molasses with casts on both hands. That the desktop varies depending on the distro and whoever decided on the defaults makes it that much worse.
Meanwhile, I largely use a vanilla setup in MacOS. The only changes in the UI I make beyond the default are installing rectangle and flycut, switching the default keyboard to ABC-Extended and turning off caps lock. Everything else runs with default settings and I’m happier for it, especially when I need to do something on someone else’s machine. Losing those minor customizations doesn’t make the machine unusable or introduce too much friction.
I had a similar experience with macOS a few years ago. After using GNOME for over 15 years, I had to switch to a Mac for work for about two years; and I never fully adapted. Windows, on the other hand, I've never been able to take seriously; every time I use it, the interface feels completely different.
The same goes for tools like Word, Excel, and PowerPoint. I prefer Markdown for creating presentations and documents, and I even use Vim keybindings in VSCode and JetBrains IDEs (because I am lazy and you can use them nearly everywhere). My "TV/Steam" runs a tiling window manager (Sway) and is controlled by a keyboard instead of a remote (and you guest it, you can use Vim keybindings with sway). At one point, I used the right-hand for mouse at work and the left-hand at home. And, of course, there is the classic switch from a native-language keyboard to an English one for programming.
What I'm trying to say is, you can adapt if you're motivated. And sometimes you don't.
I'm also a huge friend of trackpoints instead of touchpads. And I avoid to use the mouse and keyboard at the same time. Usually, mouse while planning, reviewing and presenting and keyboard when creating. And I learn keybindings for software that I use daily because of that.
Less GUI, means more Content / Information on the screen. And sometimes you benefit from that.
My takeaway? Do whatever makes you happy. Rewiring your brain from time to time keeps it flexible and sharp; like learning a new language or playing a musical instrument. It's a workout for your mind.
And Productivity isn't just about speed; it's also about quality. Sometimes, slowing down (by using a mouse) to focus on the craft of your work leads to better results than rushing to get things done as quickly as possible.
I really don't understand what everyone does that gets in their way on Linux desktop. I install Debian and the packages I use, I open Gnome, I open the software I'm using, I do my work.
I mostly agree with the points made, however I would not call this "invisible" as it was chosen to be called in the title.
Good tools should be obvious, with the main ways to use it being very low friction and low cognitive overhead. That is not the same as them being invisible. It is just a different type of visibility (one that doesn't require users to get a driving license before they can use the tool properly).
When I design such tools, I tend to think about the problem from the users perspective. What is the information they really need to know? In which environment does the rest of the context reside? Which error cases exist, who will have to deal with them and what will they need to know?
You see this a lot with beginners, because until you’ve done the work long enough to truly know what works, you only really know what you have seen through other people’s performance of the work (to the degree it is even understandable and perceptible to you). Also your social circle is probably mostly other beginners or more experienced people who are evaluating you in terms of basic competency/understanding as someone who knows more than a guy off the street who wants to be or claims to be capable of something.
So the costly/difficult-to-fake signaling of competency through complex setups, or tool fluency, has very high personal value because it positions you as someone who is interested and capable of learning about this stuff. And if you don’t have any real work to do yet, or even know what it is all the work is actually done for, it’s the most obvious place to start.
Once you understand this you can start to understand how developer tools marketing actually works, and why “this completely eliminated that problem entirely!” is NOT what developers get excited about paying for or using unless it’s something they/their social peers don’t value. Conversely, if you create a vessel for them to participate in some kind of social trend/signaling game within their social world it stops mattering as much or not it’s more productive or doesn’t actually save any time.
This applies in almost all social systems, if you’re interested in learning more about it some good terms are “costly signaling”, “mechanism design”, and animal psychology. Just don’t let yourself think you’re too smart to do it yourself - it’s inherent to the act of socializing, so anytime you’re doing that, your perceptible behavioral signals are going to affect the outcome, whether you like it or not
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.
I agree with Odin creator here. I am not sure when or why we have come to a conclusion in our professional industry that "real software engineer uses vim/emacs/insert your CLI editor here" type of mental model. Is it just the testosterone level speaking here?
Decades ago, really. Before IDEs were remotely as capable as they are now, it was just generally assumed you'd advance from a basic text editor like notepad or nano into vim or emacs.
This must be an online thing. In 15+ years of career I haven't yet heard "real software engineer...". If you get your work done no one cares how the hell you accomplish it
"invisible" is something I used to describe emacs magit. It's a thin layer over git output, it pops up, it infers parameters from ui state, call the usual git command, and goes out. Lean and fast (unless large project it seems).
Keybooard and Mouse. Everytime. I have the same question.
How much do you type in a day that moving the hand to the mouse is a productivity loss? I spend a lot of time staring (thinking, planning) than typing. So, moving my hand to the mouse and back barely has any impact.
It has a pretty profound impact on me, since the only way I can use a computer is using a screen reader, which works primarily using a keyboard. It can read things under the mouse, but it is not at all a comfortable way of working.
Thanks for explaining the context. It makes sense in your case where using mouse is a hard constraint. My reaction is more towards people who optimise for productivity.
I was once in a meeting with a guy for a specific purpose and he wasted about 10 minutes lecturing me on why he uses vim, I had no issue with it but honestly that entire world is absurd to me, do what you want as long as it works for you
This is a very interesting idea, partially because I recently wrote about how Svelte is kind of "invisible" as a tool for writing webapps (compared to f.ex. React). Much like gingerBill says here, when I use Svelte the tool "disappears into the background", at least for me.
Something I was hoping this would discuss is why do good tools feel invisible? But doesn't seem like it really went into that.
How does this apply to non-personal-computer-based tools? Heidegger has some cool commentary on the topic. I think good tools can be invisible, but they also unlock new capabilities, almost like a new bodily sense or a new organ. It's easy to focus on a text editor's removal of friction between thought and text, but I also wonder what new capabilities our tools will unlock.
I live with default wallpaper and default melody on my phone, so yep, having good defaults is fine. But in some huge products, you usually less then 10% features (and everyone is using different 10%), so it's nice to have ability to tweak things and make you need around.
One of my favorite tools is my bicycle. To me, the user interface of my bicycle is totally invisible. I just pull it out of the garage, hop on, and away I go. And it's not like I enjoy my bicycle as a "puzzle" either -- I just want it to go somewhere.
But to my 6 year old, the user interface is quite literally fear-inducing. Everything about the tool is very "visible" to him. Does that make it a bad tool?
I think this article might miss the point that tools like vim often have a much higher ceiling than the transparent or conventional alternative. You get good at the puzzle part of it (which goes along with any craft), and you are able to do things faster than your former self could have conceived.
I remember coming up as a programmer and seeing someone who was truly excellent at using their text editor making large sets of changes that would have taken me double or triple the time and having this feeling of, "ohhh that's the payout."
Look, I'm sorry to be that guy. But if you're struggling to bulk edit text in vim, you're definitely holding it wrong.
And emacs isn't even in the same category of tools, though I understand why one might think it is.
My retraction aside, I agree that the BEST software is the one you never really think about. Raycast is a great, recent example for me. Or perhaps Keyboard Maestro. It takes some fiddling to get set up, but then it just becomes a part of how I use my Mac. I only notice it when it breaks because my flow breaks.
In the age of agents, I’ve found the headline claim is even more true
I acquire and operate ecommerce companies, and build a lot of workflows with openclaw-like agents (my own stack).
When it’s working really well, there’s literally no interface needed besides iMessage and email. I’ve built a SaaS app interface style largely to show it off for demos because invisible tools don’t make for great demos
word for word why softwares like herdr, haicue, ampcode is getting adopted for ai tooling where it is hot, although just because its cli bound it doesnt mean you cant have elaborate almost-gui text interfaces... lynx is a good example from past.
Vim is a bad example to use here. I certainly have no hacker-vibe pretensions, I use Xcode almost exclusively, but with the Vim key bindings which have been integrated very well. The productivity gains with Vim commands are impressive.
Progressive disclosure is a good framing. Sane defaults keep common workflows fast, while a well-designed escape hatch lets advanced users solve exceptional cases without making every screen noisy.
> I’ve had people tell me how “fun” it was to build a macro to handle some one-off text-refactoring problem. But when I looked at what they were doing and how long it took, my honest reaction was: I could have done that in Sublime in a minute with multiple cursors, or just written a quick script
I totally agree with the larger point, but there are things you can do with vim macros that are just an absolute PITA to do with the built-in tools in vscode. Or maybe there is a specific tool that can compete (or beat) a specific use case of a vim macro, but macros are a single tool that covers a zillion use cases. So for this specific example I think there’s a tangible difference in capabilities.
Also 99.9% of the time-saving macros that people write on a day to day basis are not being shared with a single other person. It’s just a tool that becomes invisible to people who are comfortable with it. I’d argue that modal editors are particularly good at getting out of your way! Particularly ones with little or no config, like helix (or even vim mode in an IDE)
The problem with the article is that it's two arguments pretending to be one.
The first argument is about people. People romanticize the flaws of their tools, turn vim macros into a personality, and mistake the feeling of cleverness for output. Fine. True. Bill is correct that a lot of tool evangelism is tribal signaling dressed up as productivity advice. However, people join these tribes because they get benefit from it. If the tool wasn't meeting their perceived needs, they wouldn't be passionate.
The second argument, the one in the title, is about tools: that being invisible is what makes a tool good. That one is fundamentally wrong, IMO.
Halfway through, Bill admits the invisibility test "is a personal one." Which means: a tool is good when it disappears for you. Sublime is invisible to him because he's been at it for fifteen years. On day one it was not invisible to anyone. In fact, I remember buying a book and reading it back in the day about how to get better at using Sublime. So "good tools are invisible" reduces to "good tools are tools you've already mastered." That's not a claim about tools; rather, it's a claim about experience. Every powerful tool is bad to the novice and invisible to the expert. So I'll categorize this one as a veiled tautology.
Then there's the metric. Bill's "honest test" is wall-clock time and mistakes made. Anyone who's less familiar with a tool is going to make more mistakes up front. I have a couple of professional-grade sanders that I've used for some projects around the house, and because I use them infrequently, I tend to make mistakes when I get started since it's not my core competency.
The right question for a power tool isn't how fast you did the routine thing, it's what became possible that wasn't before. Git is not invisible to anyone, ever, and it's the most successful version control system ever built, for better or worse. Of course, lots of people also think Git is bad, so I'm not making any particular claims on that front, but it did manage to reach a local maxima that led people to jump ship from SVN et al. SQL has been the standard for fifty years and is famously brutal to master. A profiler demands your full attention every time you open it. These tools are good because they expand the frontier of what you can express. A tool that makes the impossible merely hard beats a tool that makes the easy invisible. Bill's metric scores the median task and is blind to the edge, which IME is where I end up spending more of my time as I grow as a software developer..
The configurability section is where the essay argues against itself. Bill's fix for "highly configurable" cop-outs is "good defaults, plus escape hatches for the rare cases." But the escape hatch is the whole problem with his thesis. The moment a tool has escape hatches, the knowledge to use them is valuable, and the tool isn't invisible even to him. He wants the power and wants to disown the learning it costs. You don't get to do that. The escape hatch and the learning curve that leads to it are the same object. He even admits it. In the learning-curve section he concedes a steep curve "could absolutely be a cost worth paying" if the payoff is real productivity. That's the entire counter-thesis. So I'm not really sure what point he's actually trying to make with this article besides that you should have good defaults for tools.
> Sublime is invisible to him because he's been at it for fifteen years.
It's not perfect and the bugs that have been there for years (and won't be fixed) have annoyed me for years too. The reason I still stick to Sublime is just because the alternatives that are similar are much much slower. I wish Sublime was actually invisible to me, but it isn't. It's just the most invisible I've found out of the alternatives.
> But the escape hatch is the whole problem with his thesis
I understand what you are saying, but the point of an escape hatch is that for the general everyday cases, the defaults should be good and invisible. But there will always be edge cases which you cannot handle nicely, either there hasn't been a way discovered yet which is better or there are other external accidental things which prevent it from being "nice" (not I am talking about tools in general and not just text editors, maybe even programming languages hint).
> The escape hatch and the learning curve that leads to it are the same object. He even admits it. He even admits it. In the learning-curve section he concedes a steep curve "could absolutely be a cost worth paying" if the payoff is real productivity. That's the entire counter-thesis.
I don't agree with your interpretation of my article. I am talking about certain people in particular that are saying the bad aspect of tool is actually good. If there is a high learning curve for a tool, it needs to eb compared to the current alternatives. But sometimes the curve is "essential" and cannot be improved upon, for better or for worse. I have yet to see many "essentially" high learning curves in the domain of programming.
I am not sure how to summarize the entire article other than what I already wrote in the conclusion.
I think you hit on a point with git and sql I made in a different context.
Removing friction from the context and flow. For what git and sql do, they arguably have the most efficient and effective work flows for their purposes.
Managing complexity becomes unavoidable for certain problems, so for challenges of the tool, sometimes, it's simple the challenge of the problem.
I would say his point is not articulated well. Tools should be less toilsome and provide faster feedback loops.
I'm pretty sure he's just finding the most condescending way he can think of to "correct" people who have a lower tolerance for paper cuts than he has.
The author's message is really "You idiots that can't just ignore the friction you can't fix, and change your habits and workflows to match what the corporate overlords know you really need should just STFU with your tips and tricks for how to customize your power tools, because I don't do that, so why should you?"
This is my mentality but when it comes to my company. I want to have clients for which I consistently produce solid work, no flash, no news headlines. Doing the work and quietly building a reputation.
i learned to code primarily from really old guys so i started on vim. i was forced to use vim because i was doing a lot of remote hpc work. now i like vim. use vim/tmux combo to improve my mouseless workflow. i just need a better way to look at all my files and pdfs without touching my mouse. i should try sublime as i cant have any real comparison between the two without having tried both. but i much prefer mouseless workflows.
The 2600 makes it really easy to the block signal path so no sound gets out, which can be confusing. Once you learn it though it can do all kinds of tricks the MiniMoog can't.
An Arp 2600 can make two completely different sounds at the same time though and a MiniMoog can't. Bob Moog himself was a fan of the 2600.
Both are classics, still being copied to this day, but for different reasons.
Or to put it another way, a piano is harder to learn than a tambourine. That doesn't make either worse in the right circumstances.
this reminds me of some programmers' blog where he talked about the line between when software does something helpful automatically for a user, vs the line of where it nags you to make decisions it could have made itself.
Obsessive hacker tools like Emacs are not a productivity enhancer. But If you find them fun go for it. You are allowed to have fun. You are allowed to enjoy your environment. If tinkering with Emacs is fun for you go for it. It's prob not replacing mental cycles for "productive" work. It's replacing zoning out with social media or YouTube between productive work times.
I can't justify using Emacs myself on a productivity basis. But working in an environment I think is fun while being productive makes me marginally happier.
Which is kind of what I was arguing. Understand that having "fun" is not necessarily equivalent to being "productive". And even by an individuals own standards, the two can be completely different.
If you are having fun, and it's a hobby: who cares? If it's in the professional setting, make sure what you are doing is not actually wasting time and/or money, i.e. be productive.
If my measured productivity decreases but my ability to find joy in what I do increases, it's probably worth it. Not to mention the second-order productivity boost that comes along with enjoying one's work.
This is an objectively idiotic and uninformed take.
Do you people think we spend our weekends tweaking our configs because that is how we get our fun? Some do, sure, the vast majority have created their config once and find themselves more productive compared to whatever alternative you might be suggesting. Configuring vim or eMacs is an investment, as you are likely to still see it around in 20 years. Being familiar with one’s tools is the key to productivity.
Calling it an ‘obsessive hacker tool’ just shows you don’t know what you’re talking about, but come with preconceived notions about why people prefer other tools.
> Obsessive hacker tools like Emacs are not a productivity enhancer.
This is intellectually dishonest framing. "obsessive hacker tools" is incoherent -- it's not the tool that is obsessive or a hacker. I don't obsessively hack emacs--I barely know elisp--and emacs is very much a productivity enhancer for me. The main benefit of the hackability of emacs for me is that hackers write useful packages for it that I occasionally run across and install.
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.
Agree that good tool should be invisible. We want essential not accidental complexity in how the tool works.
But good tool should also be fun and makes us feel productive. We can't neglect the emotional aspects of designs. And at the end of the day, if a less productive tool makes us much happier, we will less likely be burned out. That is productivity in the long term.
Maybe only AI Agent doesn't care about the emotional aspects fro tool use, but that's a separate topic.
Also, it's not about steep learning curves. We want low floor, high ceiling tools. Some of the examples the author used are either low floor low ceiling, or high floor high ceiling. Neither is ideal.
The very first paragraph about macros taking a while is wrong. They are really useful and once in your muscle memory a near instantly accessible solution to small tedious tasks.
This is true in Neovim and Emacs.
I also don't use these editors for identity. That is also dumb. I use them because it's fun and they are invisible tools once mastered.
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.
good luck editing a photo with CLI tools ( though im sure someone has developed something for this lol)
to your point i think there is a lot of merit to having CLI-first development, where if it can be done in a CLI then do it in a CLI. if a GUI is to be built as an assistance tool, great, but let the actions map to commands that could be saved and re-run
Or good luck editing text with CLI tools, for that matter.
Obviously, those need an interactive UI.
> to your point i think there is a lot of merit to having CLI-first development, where if it can be done in a CLI then do it in a CLI. if a GUI is to be built as an assistance tool, great, but let the actions map to commands that could be saved and re-run
And this is probably why CLIs suck less in practice because the development effort isn't diluted by building multiple frontends.
Vim does not have multiple cursors which can be placed ANYWHERE even multiple on the same line and at any offset. You are clearly not aware of what Vim actually offers.
To be fair to the commenter, you didn't provide any details in the example you provided. For all we (the readers) know, Visual Block mode would have worked in the situation you are describing. I have to assume not, but it's not clear from the article.
Vim macros are not that hard to write, but I do agree with you, visual feedback is better. It can be annoying to have to re-record a macro, that's why I tend to use :s (search & replace) or Visual Block mode over using a macro (most of the time I don't need a macro).
I understand you state vim is "just an example", but you use this example as the main backbone of your article. Add more detail. You're arguing with vague anecdotes which requires the reader to read between the lines.
An aside: visual feedback, multi-cursor support and sane defaults is likely what led to new modal editors being created, such as Helix and Kakoune.
Same line edits can be done with search and replace and regex. And your article doesnt specify offsets, in which case you can use a plugin, which you state you already have to do that for sublime's flaws. There's so many other examples you couldve used.
TUI and CLI isn't the same thing. A badly written TUI will fail to check isatty() on stdin and will dump ANSI escape codes, which are not trivial to remove from the output as they follow a format that has different formats, lengths and sentinels that denote the ending.
I'm fully aware they're not the same thing, I'll not sure what gave you the impression I think they are.
I agree that a badly written TUI is... badly written? Obviously I'm referring to well executed TUIs.
For example, I regularly pipe the result of ls, grep or fd into Helix then use multicursor editing to set up a script. You simply can't do that with a GUI.
Gvim is a TUI with a GUI taped on top, and whilst the PowerShell you've given there does call a GUI library function as described, I'm pretty sure the author is referring to non trivial examples of a GUI like sublime or VS Code.
So, I think of articles like this that evaluate "software" or "tools" or the value of "coding" so often miss the huge point of "there are a lot of different kinds of software/tools."
It just depends on what you're DOING. It's all so very subjective. And I think the smart direction here would be for us to be clearer and force ourselves to be more specific when we begin to evaluate approaches like this.
Certain types of work NEED invisible tools. Other types of work NEED "legible" complexity. To say nothing of individual preferences.
I just don't see much value in sweeping generalizations like this article.
This is truly a high-quality post. I completely agree with it.
Workflow is tied to one's identity.
Regarding the discussion about Linux desktops in this post, I think the reason Linux lacks popularity as an desk operating system is that programmers want their computers to be not a 'product' but their own personal tool. So rather than preferring a unified system, they tend to want more freedom to modify the OS themselves.
In other words, this is about system customizability, and about 14 years ago, Linus Torvalds made a similar point [1].
Personally, I think the TUI vs GUI debate simply depends on the domain you belong to. Those focused on OS or open source work face pressure to become familiar with TUI, while programmers like me who deliver software to factories face pressure toward GUI. The people I deliver to almost always ask for the same thing: 'Make it understandable without reading the manual.'
On the other hand, most of the TUI and low-level work I've encountered has been dominated by the 'Read The Fucking Manual' culture.
I think people see the pros and cons of their environment depending on where they place their identity. I'm a programmer, but honestly, I don't really enjoy looking at a terminal. I look at the logical structure of my code and the logs when it runs, but I'm not really comfortable with the terminal. But the typical end users I deliver to are even less comfortable with terminals than I am. So I don't particularly like terminal culture or memorizing long command strings. They're just more used to clicking buttons.
The problem is that the products we develop don't just stay with developers—they also need to be accessible to ordinary consumers. Of course, those who build tools for developers might not think that way, but I believe that even ordinary consumers should be able to easily operate the software
Others, of course, think differently. In the end, as the author of this post said, it's a matter of identity.
More often than not, good people too. And there are a lot of them. But a single unrepresentative person yelling in the room is all it takes to break stillness of quiet exchanges.
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)
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 with a little tool they won't find anywhere else.
I still leave a lot of escape hatches, but I try to design the internal tools in such way as to make the users fall into a pit of success.
Edit: also, error messages, error messages, error messages and auto suggestions for common errors
Edit 2: also the number of people only addressing the examples in the post rather than the spirit of the post is... disappointing.
I think I have the same perspective. I see it as a flavor of progressive disclosure. Sane defaults and a way to customize if needed. Start with the 80% case and let people customize if they want to. It needs to be optional.
Especially with developer tools I think there's a hesitancy to be opinionated. If you don't know for sure an option is "always correct" it seems safer to ask the user. Developers can be very pedantic. "95% of people probably want it this way, but I should make people pick because that 5% has a valid point". But now you've made it worse for most users.
It's also so much more complicated to support customization, more than I think people realize. It's not just about bugs, every option makes polishing your UX much more difficult. Both because of the testing surface and also because more flexible abstractions are harder to design.
Some time ago I made an abstraction "hey, most people in our company who use CloudFront don't care about all the implementation details, they just want some paths to be somewhat cached". I explained this idea to a coworker. It took a while, but he understood it. Two months later someone merged a PR that replaced my interface "I want this and this path cached" with a simple passthrough that exposes raw AWS interface. Same thing happened to S3 buckets where I noticed that most people just want "auto-delete files after X days either on or off".
I spent entire year trying to explain to my manager "most devs who create services want a simple deploy button". Instead, we tried to teach devs how our "infrastructure as a code" works so that they'd contribute. The effect was that only one guy engaged with us this way, and he always sent us AI-generated PRs, and every time he saw an error, he just copy-pasted it to ChatGPT without reading and then the answer back to me.
The project eventually shifted towards my original idea, but in an extremely painful way without any design at all. It's just a toolbox of completely random features glued together because one day manager says "no we don't need to support X" and two months later a Jira ticket "add support of X".
And before any major change, add a `--v2` for early adopters and `--v1` as default. Nobody should notice anything on `--v1`, any regression must be fixed imediately. Flip `--v2` as default, leaving `--v1` for the unforseen. Until you can finally get rid of them.
This helps being as invisible as possible.
Excellent idea; it's good practice to do that with APIs, so why not with command-line tools as well?
I think configurability depends on how important your tool is to the core job function or role being performed, where it becomes very valuable for helping them directly perform the tasks they and their employer value, vs how much it allows you make problems they don’t value as much get out of the way of the ones they do.
For example, I am a HUGE fan of the way Gusto handles payroll and all the different taxes and form filing for me, because I basically do not even have to think about the problem or fiddle with it at all. But to someone whose job is doing payroll/accounting/taxes or working within giant enterprise HR/legal/finance departments that does more harm than good, because it’s something they have to fight (or less charitably it makes their job too simple).
The other big problem is who is actually making the decision to pay or spend money on a thing, and whether it serves more of a defensive (eg auditability, security, constraints against undesirable behavior) or creative purpose. The creative stuff is sexier but hard to quantify, and end-users won’t actually be willing to pay that much for it relative to how much it helps them or how critical it is to their role.
Getting out of the way is important because people use dozen of tools each day for n and out.
Unfortunately there is still a thing to balance against, which is forcing people to do the right thing.
There always will be bunch of people who nag about being impeded by doing something correctly, because they feel it is waste of time.
> make the users fall into a pit of success
I don't have anything else to add but I thought this was a wonderfully evocative phrase.
Here's some additional context on the phrase, for today's lucky ten thousand[0]: https://blog.codinghorror.com/falling-into-the-pit-of-succes...
[0]: https://xkcd.com/1053/
Good read, and I think a sort of living mindset, or “process, not product”, though seems to be follow-on/reaction to Perl’s TMTOWTDI (Tim Toadie)[0], and Python’s response(“There should be one-- and preferably only one --obvious way to do it”)[1].
[0] https://perl.fandom.com/wiki/TIMTOWTDI
[1] https://en.wikipedia.org/wiki/Zen_of_Python#Principles
it really depends on the framing, some work, especially fun work that develops skills is more valuable than people realize.
From an org perspective the goal is to create the highest curve of performance over the lifetime engagement of the employee or from the employee perspective their career.
And a lot of that depends on teh relationship of the people involved. From my perspective its a net negative when if my movers worked out the day before, their muscles will be sore and they'll do a worse or slower job. From the moving companies perspective its good, they'll be stronger for more jobs. Unless they quit or are fired that day, in which case we're back to bad.
The real evaluation isn't the macro vs the sublime edit. its does the thought process of making them macro improve them in other things, and what were they doing before that. In my experience no one is going use the time they spent writing a macro or a learning vim to do real meaningful work, they're doing that because they're bored or burned out and want to think about something else they find fun at the time.
your problem isn't your employees choose to write random scripts, its that they dont have a sense of urgency or care about their current task.
Some work is also less valuable than people - especially hackers - realise.
Hackers have an addiction to tractable problems that require effort and some skill, but have a well-defined solution.
They don't require true originality or cleverness. Barrelling through them with adequate but not outstanding skills is more than enough.
Hacker systems like Linux, Vim, and Emacs, offer exactly this. You can tinker with them to solve consecutive microproblems in a satisfying way. Likewise other standard projects like working with vintage hardware or repurposing a consumer product to do something interesting.
This kind of work generates dopamine, where spending four days trying to track down an incredibly subtle bug in a giant stack owned by a few tens of people generates frustration.
So it's not that employees don't care, it's because some work really is hard and frustrating, and solving tractable problems is far easier and more satisfying.
But is it productive? Even educationally? Not necessarily.
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.
RMS may be legendary but he's no John Carmack or whomever else. I use emacs every day, and nobody who does the same can honestly say the foundations are good. The performance is atrocious. The UI locks up when you make network calls because the whole thing is single threaded. The whole thing is a mess of spaghetti code and there are multiple instances of core developers like Eli Zarerski admitting on emacs-devel that they don't know how <internal core system> works.
RMS is a visionary but as an actual software developer he's pretty mid.
You’re judging RMS skills based on the current performance of a tool he created 40 years ago using the tools available at the time. That’s wild. You complain about emacs being single threaded but computers in the 80s had a single core. Software at that time was always single threaded. By the time multiple cores became available, emacs wasn’t RMS’s personal project anymore and with lots of users it couldn’t just replace the core to make it multithreaded.
Tell me what Carmack has written that’s still widely used but did not start with the same “problems” as emacs.
Emacs is just old. Its foundations (as in the general design) are truly fantastic. I still don't understand how the heck not a single other editor over so many years has even considered replicating ideas like indirect buffers. That alone is a truly brilliant idea, and there are so many more.
Performance is atrocious today. At some point, a couple of decades ago, it might have been considered superb, but some may still remember "8 megabytes and constantly swapping". Emacs can be slow, yet its keyboard latency is still better compared to some other, more modern tools.
I'm not disagreeing with you, Emacs can be so damn annoying, and yet paradoxically remain enormously useful. Sadly (or otherwise), there's still no meaningful alternative to it, nothing even comes close. Lem has a promising story, but I remain skeptical. I think Emacs gets core C improvements sooner than Lem reaches meaningful, practical parity, although I might be wildly wrong in my prediction simply because I don't understand the scale of entanglement of the C-written core of Emacs, yet surely it's probably easier than porting the gigantic body of Elisp in existence to work in Lem.
I can't really comment on RMS' software developer skills - I have never directly reviewed his code. Perhaps, in modern times he'd be considered a "no hire", because being a software developer today requires a little bit more than just being a brilliant code writer.
sorry for the stupid quesiton, but why do you use Emacs daily if you consider the performance atrocious and the foundations unsound?
Do you have to use it for work? Do you just consider other editors to be even worse, so Emacs is the best of a bad bunch?
> Do you have to use it for work? Do you just consider other editors to be even worse, so Emacs is the best of a bad bunch?
Not who you’re asking but:
- I have a very long legacy of both muscle memory and “just right” coziness in my Emacs environment, that has followed me around from machine to machine since about 2003.
- I have flip-flopped between GUI Emacs and terminal Emacs probably a dozen times, with my most recent flop being due to Codex and Claude Code, which I run side-by-side with Emacs in a split pane tmux window.
- Yes, best of a bad bunch. I am also reasonably comfortable in Vi(m) but dislike how it handles having many open files, which is unfortunately necessary for most of the work I do.
- I have used VSCode off and on over the years as well, most recently with Gemini, but found the GUI experience quite frustrating and the lack of a CLI option ended up being a show stopper (I sometimes need to write code over SSH and the way VSCode handles remote editing is highly unpalatable to me)
Edit: one other nice perk that I discovered the other day: Claude is quite good at elisp. I was having a really weird issue that seemed like it sat at the intersection of a few packages interacting funny. Put Claude on the problem, got a very detailed explanation of how three packages had evolved and how one of them hadn’t caught up with subtle changes the other two had done. Put together a patch and suggested I make a PR to upstream. I haven’t fully reviewed the patch but the bug seems fixed properly.
Emacs is not an editor. It's a Lisp-driven text orchestrator with a built-in editor. You can type your text in whatever IDE and still control everything through Emacs.
> try to design the internal tools in such way as to make the users fall into a pit of success.
Yes. I couldn't agree more. The tools have to make it quick and easy for the users to succeed - as invisible as possible, and transparent to what a user wants to achieve.
[flagged]
[dead]
The effect of the interface becoming "invisible" is actually a function of time spent in the interface. I think what the author is reacting to is discretionary friction; designers or product folks adding features or complexity. The thing is, that friction may be necessary in order to achieve a certain task (think about resolving a merge conflict). And given enough time in the interface, even those "disruptive" steps fade into the background.
To give a concrete example, the console of a 737 is incredibly dense with controls. The airplane itself has many different modes, and there are many moments of intentional friction.
However, if you interview a pilot with 10+ years in a 737, they will tell you the interface has become invisible.
The same goes for the supposedly "bad" Bloomberg terminal. You'll find the same thing in Healthcare, where an interface cluttered with buttons is exactly the right solution for someone who spends 8+ hours/day in a MR scanning software and wants instant access to all the controls.
As programmers, I think we're too quick to generalize our own experience and preferences and try to apply them to others.
Source: I spent 10 years designing consumer and professional software at IDEO
> The effect of the interface becoming "invisible" is actually a function of time spent in the interface.
emacs starts with "extensible", so wouldn't extending the tool be part of the interface?
Purchased tools rarely align with this - they provide functionality over customization. especially in the apple world.
It really depends on the tool… CRMs and EHRs are often designed to be customizable. But end-users typically don't want to spend a lot of time configuring and customizing the interface itself. All the choices quickly become overwhelming.
A "customizable" tool for any task sufficiently complicated to be someone else's profession inevitably results in a tiny micro-economy of configuration engineers who specialize in customizing the tool to be just so.
But the crazy thing is this is still a better solution in the majority of cases than not offering extensibility at all. It turns out buying one piece of enterprise software for $250,000 and hiring one specialist in it for $150,000 per year has historically been a better deal than dumping millions into building it yourself. The gains in efficiency for the fifty $400,000 per year doctors, and 500 $100,000/ye nurses, etc who use it are still worth it.
> … discretionary friction; designers or product folks adding features or complexity.
This is far more precise. The article talks about this from the users side, how there is a class of user who enjoys learning all of these “extra” features, even though they ultimately provide less value than the core features.
>> If people find vim, emacs, or whatever genuinely good and productive, I’m not going to criticize them for using it. People are most comfortable with what they know. But for the people I am discussing, that same familiarity blinds them to their tools’ flaws, and leads them to celebrate those flaws, flaunting them as games.
> The article talks about this from the users side, how there is a class of user who enjoys learning all of these “extra” features, even though they ultimately provide less value than the core features.
With Vim, Emacs, Git,... there's a core concept that all those extras get backs to. The issue with normal editor is that their concept of a text file is an array of lines of characters. Some goes further with providing some parsing to further isolate things like strings or symbols.
With Vim, there's the buffer (aka the content), the window (where user view the content), the cursor (which is the point of origin of many actions) and various commands that moves the cursor according to what's in the buffer. Like with the hand, you can draw, write, make dough, play the piano,..., you use the same hand, you don't have to replace it to do any other actions, you only taught yourself how to do it.
Same with git. It has a core concept that encapsulate everything to do with versioning text files, you just have to compose them to do what you want.
This kind of conceptual simplicity, even though the interfacing may be rough, is good because you are solving classes of problems instead of solving them one at time. For a particular problem, you only need to switch configurations, not to learn a new tool.
The issue is when you tackle a bunch of features not related to each other, or simplify the model so much that it's a toy instead of a tool.
> a class of user who enjoys learning all of these “extra” features, even though they ultimately provide less value than the core features.
I don't think this was actually established. The author may have a point about the UX of multiple cursors in Sublime, but comparing that to Vim macros is missing the point of the macro system — i.e. that you can create something that persists between editing sessions, and encapsulate a sequence of steps even of fundamentally different kinds. (For example, do multiple cursors allow you to implement a new command to transpose elements of a comma-separated list?) More importantly, though, this is not addressing the general principle about "extra features".
I haven't known other Vim users to speak of such "games".
Yeah I think this is all coming from someone who never got good at vim.
Multi-cursors can be nice, but a sufficiently powerful implementation of that looks like helix or kakoune, and those are at least as complex as vim, if not more.
When you're good at vim, it is invisible. Once you're good at writing macros, you can do stuff which is impossible with Sublime-style multi cursors.
I assume those are situations where the author would have "just written a quick script," but vim macros are an interactive scripting language specifically designed to tersely express text transformations. Your script is never going to be quicker than that.
I'm not saying this as a vim partisan or anything. You could easily argue that vim over-optimizes and saves little time in the grand scheme—that's a fair critique. But it's strange to insist that complex tools are complex only for the sake of complexity. It's a weirdly conspiracist mindset.
> but vim macros are an interactive scripting language specifically designed to tersely express text transformations
Yes, I think this is important here. Although it's still hard for me to imagine a level of mastery where one deliberately "writes" macros (what, directly in the vimrc?) as opposed to recording them. Perhaps it's within my grasp to optimize them later, but.
All that said, there are quite a few things I don't like about Vim even though the overall editing model clicks with me, and ideas I've had for something I'd like better. Although I guess I really should check out alternatives before running my mouth about that…
The 737 example is actually quite fitting. Sure, a long time pilot will perceive the interface as invisible.
But if you contrast it with the complexity of the same functions on other aircraft, you start to see how complicated it really is. The F-22 for example handles a lot of faults (like engine fires) automatically.
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) vs "in Sublime I have multiple cursors" (no vim user ever needs that either).
The proper argument here, probably, is this one: the terminal, with its way of combining small CLI tools into pipelines, covers infinitely many use cases, but indeed has a learning curve, taking probably a year or so to become really comfortable. When you reach that point, you will be, on average, much more productive than an average GUI user, but it requires some dedication, pain, and suffering to reach that point, and people often do it involuntarily.
In my case, my first job required managing customers' servers over ssh, those servers had bare minimum installed (often vi, not vim), and I had no choice other than figuring out how to do things effectively in this setup. If not for that experience, I'm not sure I would've gone through the pain of starting doing things in the terminal.
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
And that's useful if I'm in the terminal, but if I'm in VSCode I'll just do 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.
I agree that both approaches are equally fast, and I myself did use VS Code at work a lot before the agents became widespread, so I can imagine myself doing either options. The terminal version is still less keystrokes because of the tab completion or reverse-i-search, but that's nitpicking.
> people's workflows are really personal so I'd never tell someone to switch their's
I regularly, especially when working with younger colleagues at work, find myself struggling to look at how slow they are in the terminal, like when they hit the up arrow 20 times to find the specific command in the history. If I have a close enough relationship with a person to make sure my advice won't be considered rude, I'd probably say “Ctrl+R and then type”, or even “let me show you how I would do it faster”, but doing this too often is borderline rude, so sometimes I just watch and feel bad for them.
I've seen it with seniors too. The smartest person I worked with (by far!) used to constantly use the menus in Visual Studio (OG Visual Studio, not code) for basically every operation. It was incredibly painful to watch. Watching him debug was a nightmare.
The second smartest guy I worked with couldn't really type properly. (He'd use two fingers). He was still a fantastic coder.
The thing is though, it kind of didn't matter because the value these guys provided was with their incredibly high intelligence, and the friction with how they interacted with tools was more of an issue on the margins than a big deal.
I think for people solving easier problems than these guys (who were working on legitimately hard problems), like, a webdev fixing frontend code, tools might matter a lot because there's less thinking and more navigating and typing. So context matters here a lot. But I definitely don't think you get to be an amazing programmer by CLI mastery (it definitely helps, but it's not a requirement)
I have used and use both regularly. The IDE makes the normal stuff really fast, but the CLI enables things that just can't be done in the IDE. I quite often ended up being the guy that dealt with things quickly, especially in an emergency. I just had the tools to get things done quickly, even when I hadn't been in that situation before. And I say that without even being good at awk and sed, which are used a lot by others in those situations. I always meant to get good at them, but never did. I ended up using other simpler tools instead to get the same kinds of things done.
In short, knowing the CLI way is absolutely useful, even if you use the IDE for 95% of stuff. And I also don't recommend going full CLI, because the IDE way is faster for that 95%.
Most things in life are about balance, and that's true here, too.
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 though I loved the idea at first).
> 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.
fwiw, Clojure pretty much replaced jq in my toolbelt. Dealing with EDN is so much gratifying - it's almost twice more compact than JSON, it's far more readable; filtering, grouping, sorting, slicing data is so much more straightforward and actually composable, not to mention that I get to do that interactively, directly from my editor.
My shell is configured to show me previews of commands that match from my history. Depending on how long ago I typed the cat command, it might be "cat -> tab -> return"
> I prefer tools that understand the structure of my project instead of just treating it like text
... but in the example you gave, did you not just have it pull up the text contents of a file in a window, and search through it (visually) as text? And on the command line, did you not invoke `jq` specifically to parse the JSON file as JSON?
And really, there is no reason that a TUI pager can't have progressive search that highlights matches. For that matter, vim actually does it. On the other hand, if you're just trying to jump forward to a named unique section, then the appropriate comparison is
> less packages.json <enter> -> /scr
Sure, `less` is more keystrokes than ctrl-p. But you're doing it in a much more general environment (it has to select from every program on your path), so of course it is.
Ctrl-shift-o -> scr is what I use. I love symbol navigation :)
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 that you can combine these into pipelines.
By a TUI app I mean (and I think the article means) something like Vim, Emacs, Tmux, Lynx, Tig, Midnight Commander, Claude Code, etc. - an interactive app that takes over your terminal while you're using it. You're not going to compose those into a pipeline. Or to be more precise, you're not going to use them in pipeline by using them the way you normally use them. If you can use them, it's probably because the app decided to provide a command-line interface in addition to the TUI.
You should not underestimate how confusing those CLI tools are to people who have never used them before.
For example, I would argue that for someone with no experience, figuring out how to copy a file from one folder to another is easier in Windows Explorer than learning how to use cp.
> For example, I would argue that for someone with no experience, figuring out how to copy a file from one folder to another is easier in Windows Explorer than learning how to use cp.
I don't believe this.
If you find a person (well, two I guess for this experiment) with no computer experience and want to teach them how to copy files, your first step will be teaching them what is a file and how they are organized in the computer.
Explaining what a file is takes the same amount of time for both cases (we can ignore how devices and processes are files in Linux and how files in Windows contain many data streams and extra metadata).
In both cases you need to teach them the file system is hierarchical and folders can be nested and can contain files.
For Windows you have to teach them how to double click to open folders. They can double click "My Downloads" to see their downloads. They can double click "My Music" to see their music files.
For the CLI you have to teach them that `ls` can list the contents of a directory. They can `ls Downloads` to see their downloads. They can `ls Music` to see their music files.
For Windows you then teach them they can open multiple windows (assuming you want to copy from one folder to another folder). And you teach them they can click, hold and drag and drop a file to move it (but sometimes it will be copied when they do that) and they can hold in Control while dropping to copy the file to the destination instead. Or you teach them they can use Ctrl+C to mark a file for being copied and then navigate to the destination and use Ctrl+V to copy the file. Or you teach them to right click for the right click menu, and that "copy" means "mark this file for being copied", and that a right click in the middle of a window displaying the target folder lets them select "paste" which means "copy the marked file here".
For the CLI you teach them `cp Downloads/foo.mp3 Music/` copies foo.mp3 from their downloads to their music directory.
The CLI is also infinitely easier to help newbies use over the phone!
Look I’m a big fan of having CLI interfaces, and they can definitely let you do things that you just can’t do (or are extremely difficult to do) with a standard desktop gui. But at the same time, the GUI means they never have to learn that `cp Downloads/foo.mp3 Music /` will give them a cryptic error that Music can’t be found. Or that if they’re already in the Downloads directory then they need to instead type `cp foo.mp3 ../Music/`, or that they’re going to need to figure out the special way to tell the computer what they mean when they want to do `cp Downloads/foo bar (feat. baz and the fizzbuzzes).mp3 Music/` and that doesn’t work when they type it in.
The initial explanation of the happy path might be slightly longer to teach drag and drop or right click copy and paste for files, but that happy path will also deal with a lot more scenarios in the exact same way than the happy path cli commands will.
My mom struggled to understand the concept of copying and pasting when she got her first computer at home, with Windows. It was more than 20 years ago, but I think the idea that you need to copy in one place, then go to some other place and paste there, still sometimes confuses her in the context of files, even though she does not have any issues with that when copy-pasting texts.
> The CLI is also infinitely easier to help newbies use over the phone!
I vaguely recall a scene from https://en.wikipedia.org/wiki/Who%27s_the_Boss%3F about this. "Click on the icon that says 'Word'..."
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 it a desktop with icons or menus, or a command line with a prompt? For me it's a terminal, so I prefer TUI apps.
...but not Midnight Commander: it's an outlier in your list, a tool that actively prevents you from learning the way how things work in terminal. Same for all attempts to invent a UI for git.
> 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.
Exactly this. The non-composability and non-standardization of GUI tooling is my main issue with them ; having the same toolkit available to solve every problem takes some doing but is ultimately more efficient.
That being said, it's a hard sell. It's not easy to grok the simplicity of the commandline tools until you've used them to solve what would otherwise be an intractable problem.
Yes, any GUI that doesn't provide any kind of RPC or composable API layer is almost a lost cause to me. I'd personally refuse to use it. With a caveat, though: on MacOS, which I absolutely abhorred in the beginning, having now been required to use for work (instead of Linux), I found the beauty of OSA (Open Scripting Architecture). Holy mother of Turing, I wish there was anything similar on Linux. I had no idea how amazing this thing was. I can fearlessly dig things out of even complex UIs for automation in ways that I can't ever dream to be able to do on Wayland. That still not an excuse - any serious UI should provide a functioning API.
> — Well, in my FrobnicatorStudio, there's a shortcut Ctrl+Alt+So for that
When I get those people typically I'll switch to Emacs (it's always open), use dired and rename 20 files at once, using either a keyboard macro I make on the spot or using a regexp replace.
This usually not only get them to shut up for good, they also typically then see me as the "computer wizard".
I demo'ed some terminal (piping command calls) and Emacs tricks to a very good dev who's using JetBrains tools. He got it and was very respectful... He told me: "yeah I can see the appeal, but it's not for me".
The CLI / terminal / command line utils won: LLMs have proved that. The discussion is over.
I don't think I've ever had to rename 20 files at once, so I wonder if the way people work is kind of shaped by their tools?
"I don't think I've ever had" stance, about any problem is not a good argument. At some point you'd face them and the mental models shaped by the tools you choose, often force you to deal with them in a way that often creates small, subtle micro-annoyances. You won't even consciously notice them, yet they add up. You get constantly distracted, every time by small bits, your focus budget gets eroded without you even noticing it. You feel inexplicably tired at 3PM without any meaningful work getting done for the day.
In psychology there's a term called "emotional bank account model" - small chronic negatives silently drain the account, so by the time something "big" happens there's no reserve left, even though the big thing isn't the actual cause. That is I think why our field has notorious "burned out programmer" problem. We can't even explain the reasons - because the accumulation is diffuse and undramatic, people lack a narrative-worthy explanation, and the real cause is chronic negative-affect accumulation.
That is why it is important to seek ways for the "gratified productivity" where no matter how small your problem seem to be, you can find ways to automate it nicely, ideally reaching for solutions quickly. Tools do shape your mindset. Expertise changes what affordances you perceive. Experienced Emacs user when stumbled on a problem looks at a workflow and literally sees the seams where it can be pried open, the way a climber sees holds on a blank wall. Novices often don't even recognize the wall. It's not that Emacs "has this capability, but other tools don't", it's not about specific features, it's about the mindset. Experience awk hacker for the same "rename 20 files problem" may combine a complex looking single-liner and say: "who needs Emacs schmimax? ble...", the difference in the approach, but the result is not just the output but also the mental gratification - small problem fixed quickly. While a newbie would be doing it manually, and maybe even solving it faster, but there's no gratification. We are species of "tool builders" - we get excited from using tools, sharpening them each time. Menial tasks don't leave that sharpened mental edge, they "blunt" your mindset and accumulate frustration.
I've had to batch-rename files many times over the years. That means:
1. I do it manually over however many minutes. Works if there aren't too many (especially if the pattern is too complex to trivially automate).
2. I make a Python script for it. No way I'm renaming a thousand files by hand.
3. I don't do it. Too much work. The problem lingers forever.
Or these days,
4. I make an AI datacenter eat another town's water supply.
I've never used Emacs. I tried vi(m) nonconsensually and had to google how to exit. A while later, I tried it intentionally and hkjl navigation didn't work because I use a custom keyboard layout, so I never touched it again. Sublime Text and its many cursors for the win!
I'd love a way that isn't miserable to do such a common basic task.
Try vidir from moreutils (or its improved version, https://github.com/bulletmark/edir ).
It opens the list of filenames in a given directory (or set of files passed on cmdline) in an editor of your choice, and then you use your editor to rename them; the changes get applied when your editor is closed.
> I'd love a way that isn't miserable to do such a common basic task.
The problem is that you actually describe a family of tasks which is not basic. The "iterate over files, select the right ones and apply rules to rename them" part is common; the problem is that the rules vary broadly in kind and complexity, and you haven't figured out how you want to specify them (some ways will be limited in the complexity they can handle.
(Usually the selection of files is trivial; when not, we can fold that complexity into the change rules, and emit null changes in some cases.)
If your selection rule is simple enough for Bash globbing, and your per-file rename rule is simple enough for, say `tr` to handle, then that's trivial to wrap up as a Bash script (or function). In fact, you could write the Python script such that it just accepts a single input filename and outputs the changed version, and handle the rest externally.
> I've never used Emacs. I tried vi(m) nonconsensually and had to google how to exit. A while later, I tried it intentionally and hkjl navigation didn't work because I use a custom keyboard layout, so I never touched it again. Sublime Text and its many cursors for the win!
I'm not really clear on how text editors are supposed to be relevant to batch file renaming. If trying vi(m) the first time wasn't your idea, then there should have been someone else around responsible for guiding you through it. But the variations I've tried had arrow-key navigation configured by default (and `vimtutor` explicitly tells you that it should also work); you really don't have to learn hjkl, which exists largely for a combination of historical reasons with a lot of back-filled justifications. (I would have used ijkl, mimicking an arrow-key layout.) And everything can be remapped in the config files.
The only case I can imagine is when I rename a Java interface and want all implementations to be also renamed accordingly. I can do that in 1 second in IntelliJ. With dired on emacs that would not be possible at all and I would need a tool that can find all implementations first: that requires a LSP on emacs, and then from a xref buffer, not sure how I could rename all classes and their files at once. Probably would need to be manually done? Anyone knows how to do it in emacs with one command?
It would be the same as in IntelliJ. As long as you have the Java LSP active, you issue the `lsp-rename` action: https://emacs-lsp.github.io/lsp-java/#lsp-mode-commands
This works exactly the same for all languages whose LSP support this action, which is most of them.
No! Rename in JSP is not intelligent enough to match an interface name with its implementation names and decide whether to also rename those!
What do you mean by "implementation names"? I assumed you meant changing the "implements X", which should be easy for an LSP.
Java implementations sometimes take part of the name from the interface they implement, for example, `FooRunner` probably implements `Runner`. My example was that I renamed `Runner` to whatever, `Executor`, and IntelliJ will ask me if I want to rename also implementations (in this case, it would show `FooRunner` -> `FooExecutor`).
That and Python. LLMs will use one-off Py scripts for anything on the complicated side.
When appropriate I use M-S-! or M-S-| to run a shell command in emacs.
Why not eshell?
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 when I need to ssh, or am using Termux on my phone.
> The proper argument here, probably, is this one: the terminal, with its way of combining small CLI tools into pipelines, covers infinitely many use cases,
Extensible GUI tools (Sublime, VSCode, etc) cover infinitely many use cases too, except they offer more reliable and reproducible runtime environments.
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.
But at the end of the day this only matters for novices. After enough experience with them, no matter what you use, your productivity bottleneck isn't going to be your tools (unless its ed...).
> 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
But this only speaks about what some GUIs lack, it's not necessarily true that GUI apps can't be composable, it's just that seldom they are made as such. The true potential of a GUI app is much richer than what terminal currently offers (unless it starts to receive capabilities usually present only in GUIs, as we can see with some of them - but then it's a GUI with the severe terminal restrictions, a strange beast).
I have a similar relationship with wireshark. I understand the use of a live capture and display and the attraction of the click GUI.
But at some point I just figured I was wasting so much time in there. Switched tshark and jq or good old bash/awk/grep and gnuplot, back to the command-line, then python for batteries, still using the output of tshark... and then ended writing a pcap(and ng) parser with ethernet-ip-udp/tcp and a full java IDE and never went back. I went the same meandering path with every data capture and exploration tool I had to use repeatedly.
I feel I'm not the only one having this repeated sequence of tooling improvement, hopefully there is a well named scale to describe it.
Then your manager asks you to wrap it in a GUI so your coworkers can use it, and the cycle is complete.
I've never managed to make the terminal work for me. But I've been using windows since I was like 5 and I'm really bad at remembering shortcuts besides a handful of ones I use every day.
> When you reach that point, you will be, on average, much more productive than an average GUI user
How sure are you about that? I often watch streams of people using emacs or vim, with totally custom setups and it seems like a wash to me. They look like wizards doing some stuff, and then other things seem slower than my own workflow.
Absolutely no one ever has been shown to be more productive because they don’t use GUIs. It’s kind of preposterous to think that could be true.
That's a weird thing to say. GUI slows down me A LOT when I sometimes have to switch to it from my terminal for whatever reason. Where did you get your "absolutely no one" data point?
You should read again what I said. Do you think that simply using GUIs makes anyone less productive? You can’t think of any cases where a GUI is definitely better for a task than a terminal? If you think that , consider why the vast majority of people are using GUIs for everything, and only a tiny minority is using terminals for everything. It’s ridiculous, yes, to imagine you would be more productive if no GUIs existed (you just misunderstood my point).
I reread your original comment. It would have been better if you had included those small details that, for some reason, you left out. In my opinion, you simply failed to get your point across.
Anyway, my point stands. "Absolutely no one" without any context makes no sense whatsoever. There are a number of tasks that are much, much more efficient to perform in the terminal than in a graphical interface. So no, I didn't misunderstand your point - you're just wrong.
> any cases where a GUI is definitely better
Sure I can. Not all of them are though. So be careful with exaggerations.
vim isn't really something you use in pipelines though, it's a standalone tool.
whoa, you can and absolutely should pipe things in and out of vim - it's natural. Emacs on this actually in disadvantage - it doesn't give you a built-in way for piping from and into buffers, but for that there is emacs piper script: https://github.com/agzam/mxp
Dunno, never had to do this. At most I might set PAGER=vim which means maybe something else is piping for me. If you're piping with vim then fine, but it's not a requirement to use it, unlike smaller utils that are begging to be piped.
> never had to do this
is not a defensible argument (regardless of what you use), see the relevant comment here¹
the bigger point is to get more precise and utilitarian control over text which I already discussed here in this thread², piping in and out of your editor buffers sometimes comes very handy.
___
¹ https://news.ycombinator.com/item?id=48876315
² https://news.ycombinator.com/item?id=48869558
Kinda is, maybe I found better ways to avoid or deal with those scenarios.
`command_a | vim - -c "file /dev/stdout" | command_b`
or, assuming vim is your $EDITOR, you can use vipe:
`command_a | vipe | command_b`
Most programmers come to appreciate a single fundamental truth about their field way too late into their careers. That the most basic foundational unit, the substrate they need to conquer is text. Everything stems from it. We have to deal with text our entire lives. It doesn't matter where that text appears - in web browsers, in Jira, in Slack, terminal, in PDFs, Word or LaTeX documents. Code is just structured text. The feeling of empowerment and liberation when you can deal with text on your own terms is a disproportionate multiplier.
Vendors are designed to own you and ownership can have different forms. Slack.app that doesn't let you easily extract code snippets from a thread - owns you. Jira that forces you to use their imbecilic, quirky wysiwyg owns you. Note taking app that keeps the data in their db and not your files - ain't your friend. The friction is the ownership. When extraction of text requires effort, the tool has leverage over you. It's a subtler form than data lock-in - behavioral lock-in. You adapt your workflow to what the tool makes easy, and gradually the tool's affordances shape what you even think to do. Information gets buried in threads, search is mediocre, export is hostile. The "solution" they offer is to stay there longer - search in Slack, link to Slack, screenshare in Slack, summarize with AI in Slack, don't ever leave Slack. The tool becomes the answer to the problems the tool creates. It doesn't become "invisible" like the article says, you just don't realize that you're "lost" yourself in it.
Most popular editors and IDEs don't give you direct leverage over plain text either, at least not without the effort from your side. Shortcuts, popups, UI elements in the IDE at best are local drivers - you can't easily grab a thing from the outside and feed it to your LLM context in the middle of a task, or insert within a comment in the code - you have to switch, copy, paste, deal with format inconsistencies, manual conversion, etc. Then we keep bargaining what method is the best, fastest and most convenient - using the mouse or keeping the fingers on the home row, modality or complex shortcuts. All for the sake of the problem that's artificially enforced on your workflows.
Terminal-heavy users eventually start appreciating the leverage Unix philosophy grants them over text, but that's still contained within locality, they still have to constantly jump around, while eventually figuring out ways for automating some aspects of it.
Anyway, this should be a little more of a deeper discussion than a forum comment. Point is - do not give in to the status quo. Liberate your text - deal with it on your terms. Get annoyed whenever you need to switch back and forth just for the sake of finding the piece you need and moving it around - it should be instantaneous and instinctual. Like boxers moving on a ring and casually throwing punches. Long time Vim and Emacs users "get it", even though often don't follow true - some things never become gratifying instincts. Sometimes, even the opposite forms - redundant muscle memories.
> Anyway, this should be a little more of a deeper discussion than a forum comment.
You should turn this into a post of its own, it's probably the most insightful thing I've taken away from this entire conversation.
I realized that I was typing the comment above in the middle of the night; finally, brain fatigue hit and I wrapped it too soon (thus some typos, sorry). That all was some "poetry." Now let me give you some concrete example cases.
1. You're typing a message to your colleague, and you're doing it in Slack, Teams, etc. Why? Why not use your trusted editor where you probably already have smart completions, quick spellchecking, thesaurus, definition and etymology lookup, translation and dictionaries, LLM integration and more.
Years ago I realized that and stopped typing anything longer than three words in anything else but my editor. But that forced me to copy-n-paste a lot, so I automated the process. I'd press a key in the middle of typing - regardless of what the current app is, the script simulates pressing Cmd/Ctrl+a Cmd/Ctrl+c; opens the editor buffer; inserts the text; I'll do editing; press a key - it goes back to the app; pastes the text. Stupidly simple, deviously efficient. Suddenly, my entire OS is my editor and my tool is "invisible" - like the article describes.
2. You're typing a message to your colleague. Now you're doing it in your editor, you want to share the url to the thing opened in your browser. What do you do? Normally, you'd switch to the browser, press another key to focus on the navbar, copy the link, switch back, paste the link. Goddammit, the url is cryptic. You, being a good teammate, want to add a description, now you have to go back to the browser to copy it. Then you have to make it into a markdown link format. Darn it. Was it parens and square brackets, or the other way around? We don't even realize how often we do this, because this simple action has become a routine. What's the point of arguing if mouse or vim or shortcuts is faster if the action is fundamentally flawed? For me, inserting a link in the middle of typing, from any tab in my browser is within a keystroke. It intelligently and properly formats it while retrieving the document.title.
3. Your colleague sends you a message: "Hey Jon, what about FOOBAR-41234?..." You know it's a Jira ticket number. But between FOOBAR-41345 and -41234 and a bunch of other recent ones you have no mental recollection of what that number is about. You go to your browser, navigate to the Jira instance, darn thing says you have to re-login, now you're going through 2FA - it won't even let you-in unless you find your phone and confirm it. All that effort just to look at the title. We all recognize this familiar flow, don't we?
Why even deal with this BS at all? Jira, Asana, Trello, etc. - all have CLI tools, you should leverage that. In my editor, whenever the cursor stumbles on a pattern like above, it immediately fetches the ticket description and shows it in a popup. I can quickly convert the plain "FOOBAR-41234" into a markdown, org-mode, whatever link format that has a description.
4. You're looking at FOOBAR-41234, you even see the description (because your editor is smart now), but how do you answer questions like: "what are the PRs related to this ticket?", "find slack threads that mention it", etc.? That stuff should be quick and easy. Do get annoyed whenever it takes longer than two seconds to answer any of these or similar questions.
5. You are pair-programming over Zoom. Alice (your colleague) is sharing the screen, you are reviewing some big unit of work. She's scrolling through the code changes, occasionally opening documentation, navigating to different sites, etc. You just can't bear constantly interrupting her with "slow down, I'm taking notes", "please, share this link", etc. After the session you frantically try to recall, but most of it is gone now, your notes are whacky, containing a bunch of broken urls and half-typed nonsense. Three weeks later it is a complete and utter garbage. Then you spend years debating of note-taking strategies trying to figure out what "works" and what doesn't.
That should annoy you. Darn it, if I can see it on the screen, why can't the computer "see" it too? It irked me, so I hooked up Flameshot, Tesseract, and Emacs and now I can select any area of my screen and the text gets OCRed and pops in a buffer. It's not always accurate, but it is quick and I don't even have to tell Alice to slow down anymore.
---
These are just a handful of examples, and I haven't even touched anything code related. Hopefully you can already see what I meant in my post above. Do liberate your text from the tyranny of complex GUIs, do get annoyed when you have to manually retrieve any piece of whatever. You're a damn programmer, computers and computer programs should obey your command, never forget that.
preach, brotha
Recently revamped my terminal setup after all IDEs have just gotten painfully slow to work with (the debugger + git integration in intellij was my last moat, but spend some time to learn nvim-dap + lazygit and it's excellent). AI has been immensely helpful here too to figure out the long tail of weird config gotchas.
Also thanks confirming the multiple cursor YAGNI for vim, could never wrap my head around needing it in the first place.
> usually because they don’t realize how much more productive keyboard navigation is than reaching for the mouse a lot of the time.
In a large number of cases people who say they are more productive have never measured it. They have no idea if it is true. There are been many competitions between keyboard and mouse navigation over the years. Depending on the details of how the test is written one will win or the other, often by a significant amount, in many cases the loser is the one that user said was more productive before seeing the real results.
I think if you need to measure this kind of thing, you're missing the point in the first place. I don't want to be chasing some absolute productivity metric, I want a setup that doesn't break my flow. For many people, reaching for the mouse breaks their flow and feels wrong, which is oftentimes worse than being a second slower, because it takes you out of the mental frame you were in.
For me, using my mouse while I'm working feels natural, so trying to change my workflow to learn how to navigate everything by keyboard would be a huge amount of extra effort just to maybe possibly save a little bit of time in some situations.
I think this is unhealthy self-handicapping. Your "flow" is just habits, things you've taught yourself to do. You weren't born with the ability to use either a keyboard or a mouse, there is no "natural" or "intuitive" way to operate a computer. It's all 100% learned behaviors that can be altered.
>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 power of the computer behind a set of fixed clickable options. That is a pretty poor interface.
> 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. That is a pretty poor interface.
You continue to argue for my point. OP was claiming that measured efficiency does not matter because it's about "flow". I argue that one can teach oneself to flow differently, the commands can be learned.
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.
>Keyboards require learning
We are not talking about keyboard shortcuts (key combinations that you press to do something) by the way, and about the actual typing of commands in the terminal/shell/repl what ever...
> there is "natural" or "intuitive"
Your argument is sound but this overstates your case a bit. There's a reason we don't type with our toes.
Reaching for the mouse doesn't break my flow. It makes the thing I was doing invisible in the flow. Keyboard shortcuts require me to think, which makes it FEEL like I'm doing something, and that something is in the flow so it feels like I'm productive. However the mouse doesn't even enter into the flow at all, I just do the thing and get on with the real work without breaking flow.
Again, there is no universal correct answer. Sometimes the keyboard really is better. However sometimes the mouse really is better and because I'm proficient in it I don't break my flow to use it.
I have an anecdote to contribute.
I been doing a lot of Bender. Keyboard on left hand and Mouse on right. The keyboard shortcuts in Blender are excellent, but there are _many_.
I know this sounds silly, but what really breaks my flow is moving my mouse from the middle of the screen where my model is, to the top of the screen where the menus is.
I bought a Stream Deck which is a programmable keyboard with 32 buttons and a screen behind them. I've programmed my most common commands there, so I can just reach across with a finger and smash a button rather than move the mouse away from the center of the screen.
It saves about 1 second, but really makes a huge difference.
I use blender a lot too. I bind space to search and then use that instead of shortcuts for pretty much everything that isn't the few shortcuts I've memorised (and g/s/r xyz etc)
Most knowledge about human computer interfaces was obtained through metrics. Groupings, menu bars, corner buttons, context menu orderings, and other things didn't just spawn into existence. There was a time where human pattern recognition and physiology was an active consideration for user interfaces. One of the reasons mouse input became popular is precisely because interfaces were created to be easy to use with it.
All of this brings me to my questions: Why do you reject measuring how good an interface is? Or given your dismay over keyboard based workflows, why do you think they would win most of the time?
I'd wager that if actually tested, in only a few scenarios the keyboard would win, while hybrids (with both mouse and keyboard input) perform best for most people.
> "I'd wager that if actually tested,"
https://danluu.com/keyboard-v-mouse/ - """The widely cited studies on mouse vs. keyboard efficiency are completely bogus ... <testing, reading, etc.> When I look at various tasks myself, the results are mixed, and they’re mixed in the way that most programmers I polled predicted. This result is so boring that it would barely be worth mentioning if not for the large groups of people who believe that either the keyboard is always faster than the mouse or vice versa."""
Sigh, I don't know why a blog-post against micro benchmarks should alter my opinion on this topic. There are more metrics than just "speed" regarding an interface. You also want it to be discoverable and visually distinct.
How someone interacts with your software is absolutely measurable and the results will vary by how a user is likely to use it in frequency and variety of function. Someone that needs to do something specific with your software every day will interact with it quite differently than someone that just hops onto it every now and then to do a different task each time.
All of this requires actual studies and observation of users over time. Micro benchmarks have no space there. Testing how fast a find and replace is is meaningless. In case of software for writing text you'd test a user actually writing prose, changing font sizes, title colors, and maybe replace a word over the file too. You would have commonly used functions mixed in with less commonly used functions over how the software is used under a specific use case. (For example, writing text, revising text, and polishing a graph representation are different use cases)
This is not easy, which probably why it's not done all too often, but it is also most definitely unlike a micro benchmark (which your link argues against).
All that being said, I don't know of any person strictly pitting mouse against keyboard when testing UI for possible improvements.
I think that's a pretty reductive stance to take. Keyboard nagivation is more productive _if_ the primary use of the tool is text-based. In a word processor, an IDE, a file manager, or anything else where the primary mode of interaction is reading, typing, and processing the things you've read and typed, keyboard navigation can be demonstrated to be faster and more natural _only if_ the user has taken the time to learn the shortcuts.
For tools that are mainly for non-text visual information, then the keyboard versus mouse debate is much more heavily weighted in favor of the mouse. Even then, there are times when effective keyboard shortcuts are far more useful than menus and icons. Take any CAD or 3d modeling software as an example. 90% of what a user does will be interacting with visually-presented spatial data, but even then knowing the shortcuts for changing tools or modifying a tool's settings will make you much faster and remove the need to constantly navigate nested menus of options.
Drawing/Painting and Cad modeling is very much like games. One hand on the keyboard and the other on the mouse. This mixture can be also done well in other programs. I only bother learning shortcuts for daily tools, not something I use every blue moon.
What I take issue is with tools that make them hard to use with low contrast between widgets or shortcuts that does not work if a text input is focused. Also tools that forget they have a primary usage and wants me to know everything at once (notifications, big action buttons, guided tours and what not).
> have never measured it
That's because it's practically impossible to collect objective data here, i.e. without confounding factors.
A product where the user spends 99+% of their time reading/consuming is almost certainly easier to use with a GUI. The market settled on thumb-flicking for doom scrolling instead of a button or scroll wheel interface, for a reason.
A product where the user spends 99+% of their time writing is almost certainly easier to use with a keyboard. Most sane people do not write essays on their phones with two thumbs; a keyboard and a proper word processor are preferred.
Most products fall somewhere in the middle. Most products have multiple interfaces, some primarily for consuming information and some primarily for producing it, and thus would find different inputs more productive in different modes. When people claim that they find one input type is more productive than the other, most likely is that their particular use-patterns fall more in-line with the one most aligned with their use-patterns.
[flagged]
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] They might have a personal favourite, sure, but would also be able to tell why other people prefer other tools.
I am afraid this is one of those arguments borne of ignorance whereby one is has never given a proper chance to software they are unfamiliar with.
1: to me the mark of a greybeard that has been around a while is a vague dislike of every software and any promise of improving such software. In the long run, every piece of software tends towards mediocrity.
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 the tool he wanted. His basic point however still stands. If you are making something for someone else to use then making that tool invisible to them is a powerful property.
>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.
The article does say this...
Sorry, I find the Linux desktop thing to be an accurate generalization. There's scarcely any usability advantage over there unless someone has specific requirements. The dominating mindset there isn't to make stuff just work, and it shows.Vim, not so much, maybe I don't know enough who use vim besides myself.
> I am afraid the author confuses familiarity with proof that his tools are better.
Literally NOT what I was implying or even said anywhere. Quote me where I said anything like that.
To quote myself:
> What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great.
This has nothing to do with why I or another person one tool over another, but rather treating the flaws as if they are things to have a puzzle game to work around.
People don't use vim because they enjoy puzzle solving. I don't even know how you got this conception. People use vim because they are effective at editing with vim, period, just like you are effective with Sublime Text.
People don't use Linux because they enjoy tweaking config files and everybody else has too busy a life to do that. That's a silly misconception and veiled attempt at feeling superior at those time-wasters.
> rather treating the flaws as if they are things to have a puzzle game to work around
Case in point.
Good tools are indeed invisible, but the arguments the article is built on are very shaky and honestly just sound from someone that didn't spend much time with other tools, but still has strong opinions about them.
I do know quite a few people who use vim because they do enjoy the puzzle. So there are absolutely people as he describes. Saying that there aren't people like that just undermines your point.
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.
> If people find vim, emacs, or whatever genuinely good and productive, I’m not going to criticize them for using it. People are most comfortable with what they know. But for the people I am discussing, that same familiarity blinds them to their tools’ flaws, and leads them to celebrate those flaws, flaunting them as games.
> People don't use vim because they enjoy puzzle solving.
I didn't say that either nor even imply it, and you know that when you quote me afterwards. So huh?!?!
> People don't use Linux because they enjoy tweaking config files and everybody else has too busy a life to do that.
A lot of people, including younger myself, got into Linux and Android BECAUSE it was configurable and customizable. And even played around with all of the customizations because it was fun to do. But it didn't really make my general experience better because I was forever trying to correct something I should have to correct in the first place.
I am not sure how much clearer I can be in the article or in my replies to comments.
> I didn't say that either nor even imply it, and you know that when you quote me afterwards.
You come across that way when you describe your interactions with Vim users talking about how they use macros. (Which, incidentally, doesn't match my experience at all.) More importantly, your comparison of "Vim users do this with macros" to "I could do this with (proper) multiple cursors" doesn't seem apt.
Perhaps it could possibly make sense if we had at least one concrete example of "this"; but the most obvious thing to do with multiple cursors is patterned editing of multiple matching text fragments, and Vim users would (or I would, at least) normally do that with a /g regex. To the extent that macro is useful, it's because multiple changes are done (such that the dot command wouldn't help), and if that's too complex to do easily with regex then I can't imagine that the simultaneous changes with multiple cursors could actually get it right anyway.
More importantly, though: the real point of a macro is that, having recorded it, you can persist it even across editing sessions. You also mentioned the possibility of writing a script; a macro is that, just in a very small, focused language.
> A lot of people, including younger myself, got into Linux and Android BECAUSE it was configurable and customizable. And even played around with all of the customizations because it was fun to do. But it didn't really make my general experience better because I was forever trying to correct something I should have to correct in the first place.
This doesn't match my experience at all. I play around with customizations because I understand that the default couldn't possibly have anticipated what I wanted. But more importantly: I use multiple user accounts on my system (all for myself; I did this on Windows too) and what I appreciate about Linux is that I can duplicate configuration files instead of having to navigate through UIs again and click a ton of options (perhaps following notes on what to click; I never descended to the AutoHotKey level of madness, though).
[flagged]
You can be less of a coward and reply to my comment, since you are talking about me personally, rather than mentioning me by name elsewhere.
gingerBill and I were disagreeing, sure, but at least we were arguing on topic. I fail to see what is insightful about your comment than just pointing and saying 'get a load of this guy.'
Thanks for your input, you can take a seat now.
I wasn't talking to you.
Flagged.
Casting aspersions at others behind their back, and then claiming "I wasn't talking to you" when called out for it, is not a productive or civil mode of discourse. Please don't.
> In the long run, every piece of software tends towards mediocrity.
Alternative view: Maybe that's okay, and greybeards know that.
Mediocre: "something of only moderate or ordinary quality"
Maybe we don't need the latest and greatest extraordinary technology when coding our next CRUD app.
Well this is a take.
It’s weird how much the author fixates on Vim being “visible” and implies multiple cursors and features in Sublime aren’t. Just because your brain is trained to not think about it anymore doesn’t make it any less visible.
Multiple cursors aren’t a native feature in many tools, it is still something to learn how to use, let alone effectively — just as Vim key bindings are. Plus, vim is more than just a TUI choice for terminal-only users, it’s key bindings for people that have learned that a keyboard is a natural extension of themselves and would rather not jump back and forth to mice repeatedly — just as “multiple cursors” can be to a sublime user of 15 years.
That's not what I was saying. I used vim macros specifically as an example, not Vim as a whole.
> I’ve had people tell me how “fun” it was to build a macro to handle some one-off text-refactoring problem. But when I looked at what they were doing and how long it took, my honest reaction was: I could have done that in Sublime in a minute with multiple cursors, or just written a quick script.
and
> What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great.
If you can affectively use vim macros, then GREAT! But if you cannot, even with using vim for decades, then please don't advertise them as the "fun" part.
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 it (usually tied to the next item in the search list).
Edit (after reading the article).
Both vim and emacs (which have the steep learning curve) are aimed at power users. It’s best to compare them to professional tools like CAD, DAW, industrial appliances,… The friction when learning is because a lot of users don’t know what’s possible to do or even have the kind of problems that experienced users do (or they fail to perceive them as issues). After a while, it becomes like an extension of your thinking and the tool disappears.
Exactly. And I'm no purist - I'm happy to use "dot" with a mouse if I want to easily repeat an edit in tens of places if they're not nicely aligned or searchable.
One of the things about Emacs and Vim is that you have commands that does things. They all have the same conceptual model. In vim, you have the text objects, the motions, and the counts (and more advanced ones like line and pattern addressing). In emacs, you have the point, the mark, and the arguments (including the universal one) (the advanced ones are which modes are currently active). That’s mostly the internal state that matters when you think about an edit which changes A to B.
You think about the evolution of the internal state and the suitable commands just appears, just like you think of an idea and the suitable words appears. Learning commands is like expanding your vocabulary, not learning how to speak. Learning how to speak is internalizing the aforementioned conceptual model.
> 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. So the multiple cursors approach is better not because it's a different mindset, but it produces a different feedback loop to correct mistakes.
If you still prefer the macro approach over the multiple cursors approach, then you do you. But as an example in the article, I have seen people think they are being productive by their own standards, and they really aren't.
You're over-fixating on the misuse of macros and generalize that to make a statement about Vim [1], almost as if that's the only useful feature in Vim. There are more basic editing commands that are much simpler, quicker, and powerful. It's what is actually used most of the time.
Also, getting bulk editing perfect, including the edge cases, is inefficient regardless of the tools you use. For the majority of those cases, I would just combine simple search and replace (cgn), dot repeat (.), and undo plus skip (un) for the edge cases. Then jump back (N) to the edge cases and make manual edits. It's quick, provides instant visual feedback, and requires less cognitive work than trying to process it all at once. And that's the approach people likely have in mind when they mention dot repeat.
[1] Or at least stepping right close to 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
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).
> I’ve had people tell me how “fun” it was to build a macro to handle some one-off text-refactoring problem.
I can't relate, either as a Vim user myself or having heard other users.
To the extent that it happens, it's surely because the macro can be seen as a sort of programming. Vim offers you two esoteric programming languages, if you want to see them that way: vimscript obviously, and the simple concatenation of Vim commands. But any system consisting of a text editor plus a way to record and play back its commands gives you the latter. Vim isn't doing anything special to create that second esolang; it's just bundling the playback mechanism.
But that rather is the point: creating the macro is as much "scripting" as actually using vimscript is. Not only is it recorded in an at-register, but it can be stored as plain text in a vimrc file. It should be compared to "written a quick script" and not to "used multiple cursors"; and any sensible Vim user would have a different approach (commonly powered by :%s/foo/bar/g , perhaps with backreferences) to the cases where Sublime's multiple cursors shine. (Yes, you can use visual-block across multiple lines if everything lines up; and yes, it's inferior to a real multiple-cursor system; and no, I don't think I've ever personally had a use case for it.)
There are people who reach a level of proficiency where they enjoy the challenge of an intentionally difficult to use programming language. Vim macros are accidentally a programming language, and definitely not intentionally difficult. And using them to "handle some one-off text-refactoring problem" is entirely missing the point, and a sign that one has more room to grow in proficiency and a lot more room in wisdom.
In short, the people you've heard this from should not at all be taken as representative of Vim users.
What I find especially weird is that I'm not sure I've ever heard anyone describe vim as a puzzle that's fun to solve. The most common sentiment is that it has a learning curve, but ends up being worth it.
> I'm not sure I've ever heard anyone describe vim as a puzzle that's fun to solve.
Search for “vim puzzle” and you’ll find entire websites dedicated to it. Here’s a random one: https://vimventure.dev/
Specific enthusiasts enjoying something is different from telling beginners that "vim is a fun puzzle to solve".
My intro to vim was a guy using some kind of web browser in vim, or maybe it was a browser with vim controls, and I was like wtf. But I did end up using vim for just code/text editing without any fancy macros, it was worth.
I don't think of vim as a puzzle, but I do use it because I find it fun to use in some ineffable way. Note that I also don't claim that it makes me more productive; I use it because it sparks joy, regardless of however productive it makes me.
From the article:
> multiple cursors really are better than macros 99.999% of the time (since they give direct visual feedback)
I don't know what he means, vim macros also give direct visual feedback while writing them. You just edit as normal while recording, and replay those edits later. I think it is technically possible to write a macro without seeing the live effect on the text as you write it, but I've never done that.
I looked up multiple cursors out of interest, I guess the advantage is that it's one interface that is easy to explain. I would use multiple vim commands to replace it in practice.
I'll agree that multiple cursors are maybe better than macros for most of the things that someone would use multiple cursors for, but usually I wouldn't use macro's.
But I think most of the things I do with macro's cannot be done with multiple cursors.
I would be very interested in being proven wrong, if someone has some examples of "this is where multiple cursors are great, and vim doesn't have a good alternative".
> You just edit as normal while recording, and replay those edits later.
And there is the problem. The first time you do the edit, it might be fine, but when you make a mistake in the edit, you then have to go back and correct all of the cases. With multiple cursors, I am seeing instant visual feedback on all instances of the cursor at once. I am getting literally 2D spatial information, compared to the 1D spatial information per each replay. The multiple cursors approach is better not because it's a different mindset or whatever, but rather it produces a different feedback loop to correct mistakes.
If you still prefer the macro approach over the multiple cursors approach, then you do you. But as an example in the article, I have seen people think they are being productive by their own standards, and they really aren't.
Its weird because vim has multiple cursor mode as well
Agreed. I used to enjoy vim macros, but ever since switching to Helix I reach for its multiple cursors all the time and barely use its macros. But that doesn’t mean multiple cursors don’t have a learning curve, I still need to think of he method to place the cursors in the right places.
I think I noticed halfway through reading that most of this is AI nonsense.
Ginger Bill is not AI-friendly so that's absurd.
> The clearest sign a tool is serving you is that you stop noticing it—it becomes invisible.
It is because you are already very familiar with and accustomed to this tool.
The main meaning of the author probably is (from one article):
We need to remember that the purpose of using tools is to solve specific problems and achieve goals.
No tool is perfect. When using the useful functions of a tool, we also need to tolerate or ignore some of its shortcomings. Don't seek out or switch to a new tool simply because of some insignificant flaws. In the process of selecting and using tools, don't have the perfectionism, and always keep the goal in mind. The important thing is to master the useful functions of the tools to quickly, effectively, and efficiently complete tasks or goals, thereby significantly improving efficiency and productivity, rather than constantly complaining, switching tools, and wasting time and energy.
For the tools we choose, one must become truly familiar with and proficient in their use, continuously customize, modify, and improve them, and strive to use them to the fullest extent, thereby significantly improving efficiency and productivity, and solving practical problems and achieving goals faster and better.
I agree with the premise of the article.
For example I've been using Jujutsu exclusively (as a Git frontend) for years and I don't think about it, I just use it. I reflected on this couple of years. It's existence is completely transparent to me.
I, however, don't agree with sibling commenter that it's a function of time spent with X though. As a counter example: Emacs was my go to editor for 15+ years, last 2 years - because reasons - I was switching between Neovim, Helix, Emacs, Kakoune. 6 months ago I settled with Kakoune.
Even with many years in Emacs, I still tweaked and tuned it. There was always something to do, change, understand. I actively thought about Emacs.
With Kakoune after initial "set me up" phase, it's just as transparent as Jujutsu. Sure, I made complex plugins (for searching, highlighting unbalanced parenthesis and even a GUI wrapper called Kakvide). But the difference is that in Emacs the driver was the tool itself and in Kakoune it's always "I wonder if I can do X".
And so I believe that Kakoune is better tool than Emacs as it's more transparent to me even with a big time difference in usage.
As someone deeply invested in Emacs who had a short fling with Kakoune a few years ago I'm super curious how did you manage the transition? I have lots of notes in org-mode and rely on packages like Magit and so on, due to that I'm always wary of the fact that a lot of my computer use flows through Emacs (for better or worse).
Also one thing that intrigues me about Kakoune is the possibility of writing CLI utils in whatever language and then calling them from Kakoune. The same can be done from Emacs but generally you'd go for Elisp instead.
I've also found I miss fancier text decoration like subscripts, bold, italics, underline and mixing monospace with another font when not using Emacs.
Obviously Kakoune is much simpler than Emacs, so face variability, very interactive UI is not there (though there'd be nothing preventing writing it, but I doubt anyone wants it enough).
As for transition - I always was somewhat of an UNIX guy, so I replaced Swiper/Occur/Consult with delegating to shell. Kakoune has just enough utilities to create a on-keystroke-updated-buffer so I'm happy with that. In some languages I go as much to create "find functions" special mode - composition with shell is easier than Lisp - I rarely have to read documentation.
For Git I use Jujutsu (so I stopped using Magit long time ago) but Kakoune has a very nice "!commmand<ret>" utilities. It's nothing more than a "C-u M-!", but positioning of feature differs.
So the transition is mainly about delegation, not sticking to one application, but instead finding utility that does it and use that instead.
jj required a very weird mind shift in how I work, but since it’s clicked I’d never go back. Occasionally it makes easy things a bit awkward, but the amount of hard things it makes easy is incredible. Several patterns of work have become common for me that I would never have done before.
GUI tools were better in the 90s when interfaces were more standardized, and I think the "invisibility" factor was a big part of it. I don't want to have to learn a company's whole design philosophy system because they thought building a packaged web app was "cooler" than using a standard widget toolkit. I find myself using the terminal more and more as time goes on, because I find the total friction to be less when things are predictable. I'd probably not have left the GUI world if we were all still using some modern equivalent of user32.dll.
A corollary to this I've experienced (and observed in many others) is that maintainers of good tools will very often have a much more negative perception of how users collectively view their tool than how they view it in reality. It can be hard to tell the difference between "10 users complained to me today about bugs/missing features and 9990 used it without issue" and "10 users complained to me today about bugs/missing features and 90 used it without issue", despite there being a huge amount of effort needed to go from having 90% user satisfaction and 99.9%.
I have a strong suspicion that this is a major factor in why so many open source maintainers experience burnout; the unhappy users are going to be more visible than the happy ones, and the fraction unhappy new users needed to produce the same volume of bug reports/feature requests goes down with respect the to rate at which new people start using something. This essentially creates an illusion to the maintainer that no matter how much they work to improve things, nothing they do has made a difference in the overall quality of what people experience, and that saps the motivation to keep going.
I don't really have a good solution to this problem. The only obvious answer is to be more vocal with praise when something works well, but that's the type of collective action problem that tends to not really ever happen in reality. I've personally tried to go out of my way to give frequent and enthusiastic positive feedback when something works well for me, but unless everyone starts doing this, I'm not going to be able to make too much of a difference.
Reminds me of this quote:
"We notice the person who is for ever bowing and fussily servile, and perhaps say, How humble he is! But the truly humble person escapes notice: the world does not know him."
~ Tito Colliander
> The clearest sign a tool is serving you is that you stop noticing it—it becomes invisible. You don’t celebrate its flaws because you’re not turning them into a hobby, rather you just get mildly annoyed and route around them.
I think this is more dependent on the user than on the tool. Surely, different tools will attract different users and we can probably measure strong correlation.
I also think this position lacks balance. Your tool is never perfect, sometimes you realize you could improve it, and you should balance implementing the change with the effect it'd have on your habits. Sure, the longer you use your tool, the smaller those changes are, but your usage evolves throughout your life, and it's only natural that your tools do so to.
Only tangentially related, but this is why I gave up on fountain pens. They are cool and elegant, far too cool to be a practical tool for me. I realized this at one time I was in Bonn; I was thinking deeply about a problem as I was holding this wonderful Sailor Pro Gear in my hand. At some point it slipped, fell on the desk and bent the nib sideways, a total disaster. That broke my stream of thought and ruined my day. Nah. Tools need to cater to me, not vice versa.
Do people have fun building vim macros? Vim macros are awesome because they don't involve reading manuals, memorizing obtuse key commands which you never use on a regular basis, or understanding weird configuration lines - you just use the editor the way you normally would except you're hitting record. Vim's power is that I can be editing, notice I don't have something, make it in 2 minutes, and then get back to more normal work. At least try to understand the thing first before criticizing it?
Running tests is a good example: do you want to run them from your IDE or do you want to run tests in the terminal?
The IDE folks praise the simplicity of having one tool which can run tests quickly without requiring added context and with having other IDE features able to load test context quickly.
The terminal folks praise the modularity, at-will configuration, and transparency. You do things the way the rest of the community does which makes it easier to get support and debug when things go wrong. Tests become a small tool you can reuse in other contexts (git bisect, watch commands, CI)
“memorizing obtuse key commands which you never use on a regular basis” is exactly why I prefer Emacs over vi(m). The default configuration on Emacs works like most other contexts—I can just use the arrow keys to position a cursor and type.
And then, at least on the Mac, some of the basic commands in Emacs carry over not just to the terminal, but to things like text input windows in Safari and other Mac-assed apps so I can almost always use ctrl-a to go the beginning of a line, ctrl-e to go to the end, ctrl-k to delete to the end of the line and sometimes also I get esc-del to delete the previous line although that works in terminal, but not a Safari input window (and escape gets captured in IntelliJ’s terminal which kind of stinks).
I do feel that common config across a team is always a good thing. I’ve been the only IntelliJ guy on an Eclipse team and the only Eclipse guy on an IntelliJ team and both cases were worse than conforming to the convention.
Great article.
Every time there's a post here on git and I read the comments, I keep thinking of all the years I've used fossil and how it's been completely invisible, in the background, letting me get ahead with my work.
I thought about Fossil too, once I read the article. I don't even know what version I'm on and never even think about it.
Invisible work doesnt lead to promotion, hence FAANG companies stopped making invisible+good tools, if things are invisible they get deprecated or stay in KTLO and eventually die
That's true. It's like care work; e.g. taking meeting notes. But instead of stopping it, make them visible.
I think this missed the emotional experience of using a tool.
My kitchen knives are decent knives, but no hand-forged Japanese masterpieces. Using them is a joy though, because I have an ingrained understanding of their ergonomics and how they cut.
I remember how clumsily I handled them at first. I take them to a sharpener regularly.
That experience of built-up familiarity puts me into a state of mind where I feel competent and joyful.
This is also true for my mechanical keyboard and some reference books I keep around my desk.
They are not necessarily the best possible tools, but they’re gateways to who I am at my best in different disciplines.
I think of "invisibility" as a way of removing unnecessary friction and the author doesn't quite drive home that point effectively.
Good invisibility is like well designed roads. Smooth, clear markings, adequately wide or narrow for the desired speed, easy and obvious signs. Unbothersome and pleasant. Drivers simply drive, rather than get bothered by, "gotta avoid the pothole. Here's comes the bumpy part. That blindspot, I gotta slow down for way too much. Unseen pedestrians pop out here."
This is where invisibility in interstate highway regulations are obvious.
When I see TUI vs GUI comparisons, it distills to friction for a given context/workflow.
I worked in a restaurant with a micros system. It was a very easy to use GUI that was touch screen button driven. A 1 person order could easily be entered in 6-7 button pushes in 2-3 seconds to a seasoned operator: drink > coke > dish > steak > medium > a1 > submit
The beauty with micros was that it reduced the typical navigate > select > add > back-to-navigate workflow into 1-2 button presses with a receipt-like tally providing immediate state feedback.
In this scenario, telling a user to get into a terminal console and type "cd Foo; ./add ketchup" would violate the invisibility principle. It has nothing to do with TUI or GUI.
To me, good tools get out of the way, in the given context. Micros did that.
CLI users are in a CLI flow, thus introducing a mouse to a keyboard workflow violates the invisibility workflow. But for a GUI user to hit up the terminal violates their flow.
Ultimately, all workflows are in search of a faster/less-toilsome feedback loop to the desired goal and tools are in service to the loop. Well designed tools with rabid followings understand through usage where to add friction, and where to cut toil and I'd argue this is where CLIs shine with decades of refinement of the same tool chain.
GUIs are a, it depends on how composable or self contained the given problem for a GUI interface is.
But yes, tools should be invisible. How they become invisible depends.
Interesting how all of grep, sed, ls, cp, mv, rm, cat, pwd, chmod etc are well over 50 years old and get used more than ever today. Claude code owes at least some of its success to the well established and solid unix toolchain
What is a good tool that's invisible? I'm genuinely curious. All tools I've used are either simple and heavily limited (so, not "invisible" because hard things are hard) or powerful but heavily specialized (so, not "invisible" because the learning curve is very evident). I feel the trade off is inescapable.
A good tool is invisible such that it is highly opinionated and nails the 80, 90, 99% use cases in terms of making assumptions regarding logical defaults.
Restated, the tool understands the process and what a “good” result/outcome looks like. It correctly presumes relevant and important information (especially given the current stage of your full task), and can “fill the gaps” between start and finish.
A good tool can distinguish between what you wanted, what you thought you wanted, and what you “should have” wanted.
A good tool makes it easy to do the “right” thing and hard to do the “wrong” thing.
A good tool doesn’t function to be understood, but to not be misunderstood.
I have spent a lot of time sitting in this question, having spent years creating design and drafting automation tools for architects, designers, and engineers in the building-design industry.
That's just it though isn't it. Good tools that are invisible to you won't easily come to mind because they tend to be, well, invisible.
It's not until you randomly end up on a system which doesn't have that tool that its usefulness becomes visible; and I mean really visible.
A tilling window manager is a fantastic tool that is close to invisible.
Though I don’t agree with the author. Visibility isn’t what matters, if you get comfortable with a specialized tool like a CAD software, or a game engine studio like Unreal, it’s not invisible at all but your brain will stop focusing on all the noise on your screen and you become pretty focused and productive. I live emacs, but Rider is also a fantastic editor.
Though I would love for things like LLMs to be way more out of your way, more “invisible”, more tool like. I hate the current UX of having to tame a patronizing, annoying fake human just to get things done the way I want them to be done
I think this is really insightful. Every "good and invisible" tool I thought of fit neatly into one of those two categories. Examples:
Powerful and specialized: automatic transmission, display/monitors
Simple and limited: syntax highlighting, deterministic autocomplete
The closest ones imo that bridge the gap: ssh, google search
The eye.
Many definitions of tool explicitly exclude body organs to draw a line between innate mechanisms that are inestricably linked to the body and objects used to extend one's innate physical or mental influence on the environment. The eye is not a tool, according to these definitions, but eyeglasses are.
[flagged]
This has traditionally been one of the points of attraction for the Mac desktop. It has a higher than average number of native applications which conform to platform conventions and are specifically designed to not stand out.
The best apps there acknowledge that they’re just one of a wide variety of tools the users reaches for regularly and avoid the hubris that comes with use of UI as brand identity. They don’t try to hog the user’s attention, vie for mindshare, or unnecessarily force the user to learn new or foreign UI patterns. They try their best to avoid saddling the user with any kind of unpleasant surprise (even if that’s just ensuring that common interactions work as expected) and they just sit quietly in the background until needed, serve the user’s purpose, and recede again.
EDIT: a lot of it comes down to small things which compound. For example, native tree views on macOS (NSOutlineView) expand/collapse entire subtrees when the user Option-clicks a disclosure arrow. This can save a ton of time and I die inside a little every time foreign toolkit apps don’t implement it.
I'd like to pick on the word 'invisible': if the user can get into a flow state with a tool where work becomes the major focus. I can argue that you can get into that state with any tool with enough practice. And sometimes that's only possible if the tool is actually visible to you as in all graphical UI bits you need are exactly where you remember them to be, exactly where your motor reflexes immediately seek and find.
So regarding proficiency. I bet you weren't as proficient with multiple cursors and all the things you can do with it when you first used it. (15 years is a long time to remember how it all started.) I could argue that all the key shortcuts and other bits you need to make multiple cursors work effectively doesn't come to everyone instantly. But with time you could and would hit that level.
Overall tho, vim is an interesting comparison to make also because sublime text also has a 'vintage mode'. I personally use it with vim shortcuts enabled. it lets me use vim motions on top of everything sublime offers. Does sublime + vim make it more 'invisible' to me than it is to you?
I generally have issues with arguments like this. It starts with a sexy phrase that projects some earned wisdom but then the rest of the supporting arguments are forced into the narrative most of the time by selectively ignoring important information. You could have just said I love sublime and I prefer it over vim because of this and that. or it could have been a direct critique of linux desktop. they would all stand on their own, even better I would argue, without being shoehorned into an overarching, simple, catchy phrase.
Well said. I do get the appeal of a somewhat fiddly tool though. Tool gives you a little puzzle each day, then you solve it! A little puzzle solved/accomplishment a day keeps people sane. Plus I think it's just nice to feel like you really understand the tool you're using and know it's 'language' for lack of a better word.
I think I've fallen into the same camp of getting tired of things not 'just working' out of the box. Now I'm always happy to use something with less friction over more.
Would I like to use something with community plugins like VS Code and configure it to be exactly what I want? Sure. But everything where I work was designed for bigger editors like QTCreator and then VS - so that's what I use because it has the least friction with our workflow. Would I like to get the absolute best hi-fi music player application? Sure. But HQPlayer is a pain to learn and configure, so I just went with the far-more-user-friendly MusicBee.
Friction is fun when you're young and have time and energy to burn. Less so once work becomes part of the normal routine.
The article topic is interesting, but the example it picks to illustrate deserve the purpose a bit. There isn’t any text editor that is really invisible. Dæmons/services are invisible. Copy-paste single clipboard is invisible. Switching displayed context is invisible.
Probably becoming skilled at using Sublime afterward become nice in some cases, but personally I never achieved the cumbersome of integrating multiple text pointers in my habits. In the rare occasion it feels like it might be useful, I know I will need to look at what are the keyboard dance moves again, and by the time I go search for it, my brain already generated several ready to go alternative paths to achieve the change. And I don’t even know if it can do things out of the box like `:grep pattern-to-select-buffer | g!:pattern-line-to-exclude:s:initial-string:target-string:g | update`. That’s already awesomely powerful for this level of granularity.
But that’s a rare case where to make the tool shine: most editor deal with full literal substitution just as well (if not better in term of UI), more complex refactors will be better dealt with with whatever decent modern IDE, and whatever more cases that want would want to cover using some more advanced macro is probably going to be just as easy to deal with a bespoke script.
Also Sublime is not everywhere. Nor is Vim or Emacs to be clear (as soon as you are outside of a Unix lineaged box). Though probably if one need to ssh in some remote box `vi` will most likely be an option, even busybox integrate one. But we are no longer talking about whole contemporary project edition here of course.
Still the underlying point is nice to highlight, melting it with editor war didn’t make it a favor.
A piano is not inherently a better musical instrument than a harmonica. You could argue that a piano is more complex and more puzzle like requiring more of an investment to learn for similar results.
A harmonica has a much lower barrier to entry and can be mastered over years of practice. So can a piano but with a lot more effort for more or less the same result. They both make music after all.
Ultimately, it comes down to familiarity and basic preferences. Pianos and harmonicas are basically the same if you've used them for long enough and you can get the same results with both (but a harmonica requires a lot less fuss and "games")
[I wish piano players would stop looking down on harmonica players - stop being so tribal!]
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.
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.
I know the link is by the creator of Odin, but I can speak personally for my passion for seamless tools. I have ever had as seamless, high-flow of a development environment as I do now using Nim with Sublime on Mint at work. Every one of these tools is intended to slide out of the way of your thoughts, and they do so deftly. I'm never fighting the tools; instead, the tools are facilitating me transforming my thoughts into compiled programs. All of my time and energy is spent formulating a sound model rather than fiddling with configs or fighting obtuse features.
> What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great.
I think it’s fine if that’s your hobby, but I agree that in a professional context one should be much more critical of their tools. Even asking “why do I need a tool for this at all?” will reveal shortcomings in processes, data structures or other tools that will reap much greater rewards if effort is put into fixing those instead of optimizing use of a quirky tool.
Theoretically yes, but in reality I have found that often it's much easier to just fix something locally or with a workaround rather than jumping through all hoops required to get somebody in another team or even another company to understand and agree with you on your (or your teams) issues, let alone fix them in a satisfactory way.
"The year of the Linux desktop still isn’t upon us (in 2026), and part of the reason why it has taken so long to get to that point is fundamental: a lot of the people who use Linux love fiddling with configuration files to reshape their system"
"part of the reason", yes, besides people's familiarity with Windows, it being pre-installed, Linux's splintered ecosystem in general, games, drivers for hardware, and so much more...
But what I want to contribute: LLMs like codex can be brilliant for custom setups, maybe not for the layman, but for the now lazy but previously-into-tuning your setup person with an itch remaining. For years I've not been wanting to tune my system, I have actual work to do. A few hours spent configuring a tool for small marginal gains is hours I could spend more productively.
Hence, Default Ubuntu with Gnome, good enough, let's do actual work. But I as I get to work more away from my desk setup (hence away from a docking station and external monitors) and more on my Laptop alone, I recently started to long for my i3 setup from years ago...
A few hours of prompting codex and I have sway set up w/ vim like keybindings, all the information I want in a task bar (I couldn't even tell you which, swaybar I think), a good launcher for applications that I like (it's graphically fancier than the simple default launchers for tiling wms), have kitty as terminal with awesome shortcuts for tab navigation, have bash aliases for saving and loading terminal sessions, no shortcuts (sway versus vim vs kitty) are in conflict, all overlap beautifully and make sense (different modifier keys, but same vim motion like fundamentals). I can simply pull the plug on my docking station or re-attach and everything keeps being fine.
So I have a custom setup, custom to me, that especially on a single screen makes me far more productive, setting it up is 10% the time it used to be, making changes in the future will be 10% it used to be, and I still a) leveraged the capabilities for customization and b) it being simple text based configs I can still leverage that going forward and c) have still the insight if needed (looking at the configs).
Codex on Linux in general feels like a super power. Due to the heavy text-based workflow Linux allows for, the Composability of terminal tools etc, I doubt working together with an LLM on setting up a system could work so well on any other system.
> What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great.
I'm confused by this because I simultaneously agree with Bill by the examples given in the article; things like "ricing" Linux and Vim, but I also advertise Odin as being great due to this friction which may be seen as a limitation.
My favorite example is Odin's approach to metaprogramming and compile-time features. Odin is featureful in this regard, but not nearly to the extent that other languages are (D, Zig, Nim, C++, C) and it may have been the deciding reason I've written far more Odin than any of those other languages.
I _can't_ just do whatever I want at compile-time in Odin. That's a blessing for people like me. I toy with the compiler. I admire languages and language design, and toying with them, learning all of the features, is an expression of that interest. For Odin, there really aren't many novel features for you to toy with. It's just not a toy at all. I don't mean "toy" in then derogatory sense, or to designate others as such. I simply mean that Odin is just not fun to fiddle with, you use it to do something.
I rarely use vi{,m} these days but I sometimes still instinctively type motions or :commands into other terminal editors (which naturally blurts them out into the text buffer). When using something like Sublime or VSCode, I'm always hunting through menus, documentation and search engines to do something simple like ":%!sort -u". Kate is a bit unwieldy—far from invisible—but I've found it to be the most frictionless editor on the market by a wide margin.
If you're always reaching for vim commands, why did you stop using it?
Many small reasons; changing workflows, very strange default settings (may have been fixed a few years ago?), snaggy desktop integration, because it's a pain to use at work on Windows, etc.
“Good tools are invisible” is not an objectionable thing to claim, but the example used is confusing: a power user of vim presumably feels like their flows are invisible, just like the author feels like his Sublime patterns are invisible. It’s not clear at all that there’s any “good tool” quality to tease apart between the two.
(I say this as a long-time Sublime user.)
I find the best features, or mechanics in games too, are ones that fall out of greater architectural design. For example, if you've ever played popular hero shooter games like Overwatch, Marvel Rivals, or Paladins, they all have different physics engines; you can tell as you switch between the games. Which one's the "most correct" is up for personal interpretation, but they all try to grant the player affordances, abilities, and special 'tech' all while staying a simple engine for models and hitboxes to interact in.
Then there's coyote time and networking latency. All these little but meaningful details to consider on top of the base action of making a space for 'things to happen'.
When implementing a feature, I feel I'm always thinking back to when I'd get frustrated with the ways Paladins characters clip on walls more than in Overwatch, or the jarring air mobility difference between games like TF2 and the floaty feel found in the others already mentioned so far. I want the feature to feel like it could emerge as a result of the first natural instinct from play. Like when you enter a game world and you obviously know the keyboard and mouse 'control the world', so you start there and begin mapping your intuition of the experience. It starts with the surface visual communications. The HUD, the world itself, the buttons. Maybe your keyboard lights up and shows you what keys to press (chroma sdk for example). Then gets deeper as your experience grows. And the best features, ui, designs, games, etc. engage people who are curious enough to keep digging without enforcing the digging upon the average user.
One important thing falls out of a design philosophy like that. You never exclude a power user, and never baby a new user. It just... is the tool itself.
The Linux on the desktop one was the biggest “hell, yeah” moment for me. 99% of the desktop preference is familiarity. Since my personal computing has been on a Mac exclusively for the last 24 years and I’ve not used Windows for work more recently than 2018 (and it was sporadically the case in the decade before that), when I do use Windows, it feels like I’m typing in molasses. A Linux desktop feels like I’m typing in molasses with casts on both hands. That the desktop varies depending on the distro and whoever decided on the defaults makes it that much worse.
Meanwhile, I largely use a vanilla setup in MacOS. The only changes in the UI I make beyond the default are installing rectangle and flycut, switching the default keyboard to ABC-Extended and turning off caps lock. Everything else runs with default settings and I’m happier for it, especially when I need to do something on someone else’s machine. Losing those minor customizations doesn’t make the machine unusable or introduce too much friction.
I had a similar experience with macOS a few years ago. After using GNOME for over 15 years, I had to switch to a Mac for work for about two years; and I never fully adapted. Windows, on the other hand, I've never been able to take seriously; every time I use it, the interface feels completely different.
The same goes for tools like Word, Excel, and PowerPoint. I prefer Markdown for creating presentations and documents, and I even use Vim keybindings in VSCode and JetBrains IDEs (because I am lazy and you can use them nearly everywhere). My "TV/Steam" runs a tiling window manager (Sway) and is controlled by a keyboard instead of a remote (and you guest it, you can use Vim keybindings with sway). At one point, I used the right-hand for mouse at work and the left-hand at home. And, of course, there is the classic switch from a native-language keyboard to an English one for programming. What I'm trying to say is, you can adapt if you're motivated. And sometimes you don't.
I'm also a huge friend of trackpoints instead of touchpads. And I avoid to use the mouse and keyboard at the same time. Usually, mouse while planning, reviewing and presenting and keyboard when creating. And I learn keybindings for software that I use daily because of that.
Less GUI, means more Content / Information on the screen. And sometimes you benefit from that.
My takeaway? Do whatever makes you happy. Rewiring your brain from time to time keeps it flexible and sharp; like learning a new language or playing a musical instrument. It's a workout for your mind.
And Productivity isn't just about speed; it's also about quality. Sometimes, slowing down (by using a mouse) to focus on the craft of your work leads to better results than rushing to get things done as quickly as possible.
I really don't understand what everyone does that gets in their way on Linux desktop. I install Debian and the packages I use, I open Gnome, I open the software I'm using, I do my work.
Exactly, not everyone is using Arch, btw. Fedora with Gnome just work to the point it is boring.
I mostly agree with the points made, however I would not call this "invisible" as it was chosen to be called in the title.
Good tools should be obvious, with the main ways to use it being very low friction and low cognitive overhead. That is not the same as them being invisible. It is just a different type of visibility (one that doesn't require users to get a driving license before they can use the tool properly).
When I design such tools, I tend to think about the problem from the users perspective. What is the information they really need to know? In which environment does the rest of the context reside? Which error cases exist, who will have to deal with them and what will they need to know?
Good Editors are Invisible would make more sense. I think this only applies to the class of tools we would call "controllers"
You see this a lot with beginners, because until you’ve done the work long enough to truly know what works, you only really know what you have seen through other people’s performance of the work (to the degree it is even understandable and perceptible to you). Also your social circle is probably mostly other beginners or more experienced people who are evaluating you in terms of basic competency/understanding as someone who knows more than a guy off the street who wants to be or claims to be capable of something.
So the costly/difficult-to-fake signaling of competency through complex setups, or tool fluency, has very high personal value because it positions you as someone who is interested and capable of learning about this stuff. And if you don’t have any real work to do yet, or even know what it is all the work is actually done for, it’s the most obvious place to start.
Once you understand this you can start to understand how developer tools marketing actually works, and why “this completely eliminated that problem entirely!” is NOT what developers get excited about paying for or using unless it’s something they/their social peers don’t value. Conversely, if you create a vessel for them to participate in some kind of social trend/signaling game within their social world it stops mattering as much or not it’s more productive or doesn’t actually save any time.
This applies in almost all social systems, if you’re interested in learning more about it some good terms are “costly signaling”, “mechanism design”, and animal psychology. Just don’t let yourself think you’re too smart to do it yourself - it’s inherent to the act of socializing, so anytime you’re doing that, your perceptible behavioral signals are going to affect the outcome, whether you like it or not
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.
I agree with Odin creator here. I am not sure when or why we have come to a conclusion in our professional industry that "real software engineer uses vim/emacs/insert your CLI editor here" type of mental model. Is it just the testosterone level speaking here?
Decades ago, really. Before IDEs were remotely as capable as they are now, it was just generally assumed you'd advance from a basic text editor like notepad or nano into vim or emacs.
This must be an online thing. In 15+ years of career I haven't yet heard "real software engineer...". If you get your work done no one cares how the hell you accomplish it
I have a methodological explanation why good tools are invisible. Explained it here: https://nextmovetheory.com/library/the-nature-of-product/epi...
"invisible" is something I used to describe emacs magit. It's a thin layer over git output, it pops up, it infers parameters from ui state, call the usual git command, and goes out. Lean and fast (unless large project it seems).
Keybooard and Mouse. Everytime. I have the same question.
How much do you type in a day that moving the hand to the mouse is a productivity loss? I spend a lot of time staring (thinking, planning) than typing. So, moving my hand to the mouse and back barely has any impact.
It has a pretty profound impact on me, since the only way I can use a computer is using a screen reader, which works primarily using a keyboard. It can read things under the mouse, but it is not at all a comfortable way of working.
Thanks for explaining the context. It makes sense in your case where using mouse is a hard constraint. My reaction is more towards people who optimise for productivity.
I was once in a meeting with a guy for a specific purpose and he wasted about 10 minutes lecturing me on why he uses vim, I had no issue with it but honestly that entire world is absurd to me, do what you want as long as it works for you
This is a very interesting idea, partially because I recently wrote about how Svelte is kind of "invisible" as a tool for writing webapps (compared to f.ex. React). Much like gingerBill says here, when I use Svelte the tool "disappears into the background", at least for me.
Something I was hoping this would discuss is why do good tools feel invisible? But doesn't seem like it really went into that.
People use vim because they want to use vim, not because people tell them to use it.
Funny: This title is a classic statement of Martin Heidegger’s. Go programmers!
Finally someone put my thought on this topic into words! (Hopefully the author used a suitably invisible tool to write this.)
How does this apply to non-personal-computer-based tools? Heidegger has some cool commentary on the topic. I think good tools can be invisible, but they also unlock new capabilities, almost like a new bodily sense or a new organ. It's easy to focus on a text editor's removal of friction between thought and text, but I also wonder what new capabilities our tools will unlock.
I live with default wallpaper and default melody on my phone, so yep, having good defaults is fine. But in some huge products, you usually less then 10% features (and everyone is using different 10%), so it's nice to have ability to tweak things and make you need around.
The best tool has just a single button that has already been pressed for you. The mechanical action is there just for satisfaction.
There was an old blog post comparing pianos to text editors.
A "simpler" piano would only have white keys, but to a piano expert the piano appears invisible (and powerful) after the initial learning curve.
I think an important attribute of mastery is related to consistency over time. Microsoft Word '95 vs 2007 (the ribbon) is a great example.
Mostly MS's keyboard shortcuts have been consistent (Alt-F4, Ctrl-B, Alt-F-S), but their UI has been inconsistent (making mastery harder).
In any case: "tools for experts may seem initially awkward to non-experts"
...and: "initially non-awkward tools may hamper capabilities as the operator skill increases"
I'm not sure about this.
One of my favorite tools is my bicycle. To me, the user interface of my bicycle is totally invisible. I just pull it out of the garage, hop on, and away I go. And it's not like I enjoy my bicycle as a "puzzle" either -- I just want it to go somewhere.
But to my 6 year old, the user interface is quite literally fear-inducing. Everything about the tool is very "visible" to him. Does that make it a bad tool?
I think this article might miss the point that tools like vim often have a much higher ceiling than the transparent or conventional alternative. You get good at the puzzle part of it (which goes along with any craft), and you are able to do things faster than your former self could have conceived.
I remember coming up as a programmer and seeing someone who was truly excellent at using their text editor making large sets of changes that would have taken me double or triple the time and having this feeling of, "ohhh that's the payout."
I would also say good tools have better "physics" they've got some coherent internal model that is somewhat easy to intuit about.
I'm building
Inquir Compute - Function as a Service, https://inquir.org
and
Inquir Search - Search as a Service, https://search.inquir.org
considering pretty good services, use them almost on daily basis building some random staff
e.g. deployed
https://aleksandr-kubarskii-0931e2-hn-8439d2.inquir.org/
https://aleksandr-kubarskii-0931e2-psx-d82ded.inquir.org
https://aleksandr-kubarskii-0931e2-anime-42854a.inquir.org/
and some more
Look, I'm sorry to be that guy. But if you're struggling to bulk edit text in vim, you're definitely holding it wrong.
And emacs isn't even in the same category of tools, though I understand why one might think it is.
My retraction aside, I agree that the BEST software is the one you never really think about. Raycast is a great, recent example for me. Or perhaps Keyboard Maestro. It takes some fiddling to get set up, but then it just becomes a part of how I use my Mac. I only notice it when it breaks because my flow breaks.
In the age of agents, I’ve found the headline claim is even more true
I acquire and operate ecommerce companies, and build a lot of workflows with openclaw-like agents (my own stack).
When it’s working really well, there’s literally no interface needed besides iMessage and email. I’ve built a SaaS app interface style largely to show it off for demos because invisible tools don’t make for great demos
"I want the defaults to be good and just work, and when I do need to tweak something minor, it should take seconds."
This is Apple's secret, its strange how so many people can't see this or why no ine has comprehensively replicated it.
Premise makes a ton of sense. Having had a chance to build my own tools for myself, I buy this a lot. Some additional notes here: https://backstory-production-ef74.up.railway.app/b/2xxrr6?ne...
word for word why softwares like herdr, haicue, ampcode is getting adopted for ai tooling where it is hot, although just because its cli bound it doesnt mean you cant have elaborate almost-gui text interfaces... lynx is a good example from past.
Vim is a bad example to use here. I certainly have no hacker-vibe pretensions, I use Xcode almost exclusively, but with the Vim key bindings which have been integrated very well. The productivity gains with Vim commands are impressive.
Progressive disclosure is a good framing. Sane defaults keep common workflows fast, while a well-designed escape hatch lets advanced users solve exceptional cases without making every screen noisy.
> I’ve had people tell me how “fun” it was to build a macro to handle some one-off text-refactoring problem. But when I looked at what they were doing and how long it took, my honest reaction was: I could have done that in Sublime in a minute with multiple cursors, or just written a quick script
I totally agree with the larger point, but there are things you can do with vim macros that are just an absolute PITA to do with the built-in tools in vscode. Or maybe there is a specific tool that can compete (or beat) a specific use case of a vim macro, but macros are a single tool that covers a zillion use cases. So for this specific example I think there’s a tangible difference in capabilities.
Also 99.9% of the time-saving macros that people write on a day to day basis are not being shared with a single other person. It’s just a tool that becomes invisible to people who are comfortable with it. I’d argue that modal editors are particularly good at getting out of your way! Particularly ones with little or no config, like helix (or even vim mode in an IDE)
The problem with the article is that it's two arguments pretending to be one.
The first argument is about people. People romanticize the flaws of their tools, turn vim macros into a personality, and mistake the feeling of cleverness for output. Fine. True. Bill is correct that a lot of tool evangelism is tribal signaling dressed up as productivity advice. However, people join these tribes because they get benefit from it. If the tool wasn't meeting their perceived needs, they wouldn't be passionate.
The second argument, the one in the title, is about tools: that being invisible is what makes a tool good. That one is fundamentally wrong, IMO.
Halfway through, Bill admits the invisibility test "is a personal one." Which means: a tool is good when it disappears for you. Sublime is invisible to him because he's been at it for fifteen years. On day one it was not invisible to anyone. In fact, I remember buying a book and reading it back in the day about how to get better at using Sublime. So "good tools are invisible" reduces to "good tools are tools you've already mastered." That's not a claim about tools; rather, it's a claim about experience. Every powerful tool is bad to the novice and invisible to the expert. So I'll categorize this one as a veiled tautology.
Then there's the metric. Bill's "honest test" is wall-clock time and mistakes made. Anyone who's less familiar with a tool is going to make more mistakes up front. I have a couple of professional-grade sanders that I've used for some projects around the house, and because I use them infrequently, I tend to make mistakes when I get started since it's not my core competency.
The right question for a power tool isn't how fast you did the routine thing, it's what became possible that wasn't before. Git is not invisible to anyone, ever, and it's the most successful version control system ever built, for better or worse. Of course, lots of people also think Git is bad, so I'm not making any particular claims on that front, but it did manage to reach a local maxima that led people to jump ship from SVN et al. SQL has been the standard for fifty years and is famously brutal to master. A profiler demands your full attention every time you open it. These tools are good because they expand the frontier of what you can express. A tool that makes the impossible merely hard beats a tool that makes the easy invisible. Bill's metric scores the median task and is blind to the edge, which IME is where I end up spending more of my time as I grow as a software developer..
The configurability section is where the essay argues against itself. Bill's fix for "highly configurable" cop-outs is "good defaults, plus escape hatches for the rare cases." But the escape hatch is the whole problem with his thesis. The moment a tool has escape hatches, the knowledge to use them is valuable, and the tool isn't invisible even to him. He wants the power and wants to disown the learning it costs. You don't get to do that. The escape hatch and the learning curve that leads to it are the same object. He even admits it. In the learning-curve section he concedes a steep curve "could absolutely be a cost worth paying" if the payoff is real productivity. That's the entire counter-thesis. So I'm not really sure what point he's actually trying to make with this article besides that you should have good defaults for tools.
> Sublime is invisible to him because he's been at it for fifteen years.
It's not perfect and the bugs that have been there for years (and won't be fixed) have annoyed me for years too. The reason I still stick to Sublime is just because the alternatives that are similar are much much slower. I wish Sublime was actually invisible to me, but it isn't. It's just the most invisible I've found out of the alternatives.
> But the escape hatch is the whole problem with his thesis
I understand what you are saying, but the point of an escape hatch is that for the general everyday cases, the defaults should be good and invisible. But there will always be edge cases which you cannot handle nicely, either there hasn't been a way discovered yet which is better or there are other external accidental things which prevent it from being "nice" (not I am talking about tools in general and not just text editors, maybe even programming languages hint).
> The escape hatch and the learning curve that leads to it are the same object. He even admits it. He even admits it. In the learning-curve section he concedes a steep curve "could absolutely be a cost worth paying" if the payoff is real productivity. That's the entire counter-thesis.
I don't agree with your interpretation of my article. I am talking about certain people in particular that are saying the bad aspect of tool is actually good. If there is a high learning curve for a tool, it needs to eb compared to the current alternatives. But sometimes the curve is "essential" and cannot be improved upon, for better or for worse. I have yet to see many "essentially" high learning curves in the domain of programming.
I am not sure how to summarize the entire article other than what I already wrote in the conclusion.
I think you hit on a point with git and sql I made in a different context.
Removing friction from the context and flow. For what git and sql do, they arguably have the most efficient and effective work flows for their purposes.
Managing complexity becomes unavoidable for certain problems, so for challenges of the tool, sometimes, it's simple the challenge of the problem.
I would say his point is not articulated well. Tools should be less toilsome and provide faster feedback loops.
I'm pretty sure he's just finding the most condescending way he can think of to "correct" people who have a lower tolerance for paper cuts than he has.
The author's message is really "You idiots that can't just ignore the friction you can't fix, and change your habits and workflows to match what the corporate overlords know you really need should just STFU with your tips and tricks for how to customize your power tools, because I don't do that, so why should you?"
Sublime is a very good editor indeed.
This is my mentality but when it comes to my company. I want to have clients for which I consistently produce solid work, no flash, no news headlines. Doing the work and quietly building a reputation.
i learned to code primarily from really old guys so i started on vim. i was forced to use vim because i was doing a lot of remote hpc work. now i like vim. use vim/tmux combo to improve my mouseless workflow. i just need a better way to look at all my files and pdfs without touching my mouse. i should try sublime as i cant have any real comparison between the two without having tried both. but i much prefer mouseless workflows.
Take a look at yazi https://yazi-rs.github.io/, I find it pretty good for looking at my files.
An easy to learn UI is not without merit but neither is a complex UI with greater inherent flexibility.
I like old, analogue synthesisers. To pick two very famous examples:
I love the MiniMoog because it's very low friction.
https://en.wikipedia.org/wiki/Minimoog
It's a classic that's simple to learn and quick to get useful sounds. It's a funk bomb.
I prefer the Arp 2600 though (it's the voice of R2D2!).
https://en.wikipedia.org/wiki/ARP_2600
The 2600 makes it really easy to the block signal path so no sound gets out, which can be confusing. Once you learn it though it can do all kinds of tricks the MiniMoog can't.
An Arp 2600 can make two completely different sounds at the same time though and a MiniMoog can't. Bob Moog himself was a fan of the 2600.
Both are classics, still being copied to this day, but for different reasons.
Or to put it another way, a piano is harder to learn than a tambourine. That doesn't make either worse in the right circumstances.
> taking a tool’s shortcomings and reselling them as a “puzzle game” which is “fun” to solve
cough Perl cough
this reminds me of some programmers' blog where he talked about the line between when software does something helpful automatically for a user, vs the line of where it nags you to make decisions it could have made itself.
Obsessive hacker tools like Emacs are not a productivity enhancer. But If you find them fun go for it. You are allowed to have fun. You are allowed to enjoy your environment. If tinkering with Emacs is fun for you go for it. It's prob not replacing mental cycles for "productive" work. It's replacing zoning out with social media or YouTube between productive work times.
I can't justify using Emacs myself on a productivity basis. But working in an environment I think is fun while being productive makes me marginally happier.
Which is kind of what I was arguing. Understand that having "fun" is not necessarily equivalent to being "productive". And even by an individuals own standards, the two can be completely different.
If you are having fun, and it's a hobby: who cares? If it's in the professional setting, make sure what you are doing is not actually wasting time and/or money, i.e. be productive.
If my measured productivity decreases but my ability to find joy in what I do increases, it's probably worth it. Not to mention the second-order productivity boost that comes along with enjoying one's work.
> Obsessive hacker tools like Emacs are not a productivity enhancer.
Emacs wouldn't survive if it didn't provide a net benefit to its users.
This is an objectively idiotic and uninformed take.
Do you people think we spend our weekends tweaking our configs because that is how we get our fun? Some do, sure, the vast majority have created their config once and find themselves more productive compared to whatever alternative you might be suggesting. Configuring vim or eMacs is an investment, as you are likely to still see it around in 20 years. Being familiar with one’s tools is the key to productivity.
Calling it an ‘obsessive hacker tool’ just shows you don’t know what you’re talking about, but come with preconceived notions about why people prefer other tools.
I spend my weekends enjoying life and my family but I guess that’s just part of my objectively idiotic take on life.
> Obsessive hacker tools like Emacs are not a productivity enhancer.
This is intellectually dishonest framing. "obsessive hacker tools" is incoherent -- it's not the tool that is obsessive or a hacker. I don't obsessively hack emacs--I barely know elisp--and emacs is very much a productivity enhancer for me. The main benefit of the hackability of emacs for me is that hackers write useful packages for it that I occasionally run across and install.
Invisibility is in the eye of the (un?)beholder.
I've used vim for decades. Tried using Sublime about 10? years ago. It just got in the way.
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.
Agree that good tool should be invisible. We want essential not accidental complexity in how the tool works.
But good tool should also be fun and makes us feel productive. We can't neglect the emotional aspects of designs. And at the end of the day, if a less productive tool makes us much happier, we will less likely be burned out. That is productivity in the long term.
Maybe only AI Agent doesn't care about the emotional aspects fro tool use, but that's a separate topic.
Also, it's not about steep learning curves. We want low floor, high ceiling tools. Some of the examples the author used are either low floor low ceiling, or high floor high ceiling. Neither is ideal.
Solved problems are invisible.
The very first paragraph about macros taking a while is wrong. They are really useful and once in your muscle memory a near instantly accessible solution to small tedious tasks. This is true in Neovim and Emacs.
I also don't use these editors for identity. That is also dumb. I use them because it's fun and they are invisible tools once mastered.
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.
good luck editing a photo with CLI tools ( though im sure someone has developed something for this lol)
to your point i think there is a lot of merit to having CLI-first development, where if it can be done in a CLI then do it in a CLI. if a GUI is to be built as an assistance tool, great, but let the actions map to commands that could be saved and re-run
> good luck editing a photo with CLI tools
Or good luck editing text with CLI tools, for that matter.
Obviously, those need an interactive UI.
> to your point i think there is a lot of merit to having CLI-first development, where if it can be done in a CLI then do it in a CLI. if a GUI is to be built as an assistance tool, great, but let the actions map to commands that could be saved and re-run
And this is probably why CLIs suck less in practice because the development effort isn't diluted by building multiple frontends.
Well that’s a lot of platitudes for such a short post…
So that's why they are so hard to find!
I get the sentiment and agree with it but vim has multiple cursors. I'm sure gingerbill is aware of this so to use that example is a little strange.
Vim does not have multiple cursors which can be placed ANYWHERE even multiple on the same line and at any offset. You are clearly not aware of what Vim actually offers.
To be fair to the commenter, you didn't provide any details in the example you provided. For all we (the readers) know, Visual Block mode would have worked in the situation you are describing. I have to assume not, but it's not clear from the article.
Vim macros are not that hard to write, but I do agree with you, visual feedback is better. It can be annoying to have to re-record a macro, that's why I tend to use :s (search & replace) or Visual Block mode over using a macro (most of the time I don't need a macro).
I understand you state vim is "just an example", but you use this example as the main backbone of your article. Add more detail. You're arguing with vague anecdotes which requires the reader to read between the lines.
An aside: visual feedback, multi-cursor support and sane defaults is likely what led to new modal editors being created, such as Helix and Kakoune.
Same line edits can be done with search and replace and regex. And your article doesnt specify offsets, in which case you can use a plugin, which you state you already have to do that for sublime's flaws. There's so many other examples you couldve used.
I like TUIs because I can pipe the output of CLIs directly into them, and I don't have to leave my terminal environment. GUIs can't compete with that.
TUI and CLI isn't the same thing. A badly written TUI will fail to check isatty() on stdin and will dump ANSI escape codes, which are not trivial to remove from the output as they follow a format that has different formats, lengths and sentinels that denote the ending.
I'm fully aware they're not the same thing, I'll not sure what gave you the impression I think they are.
I agree that a badly written TUI is... badly written? Obviously I'm referring to well executed TUIs.
For example, I regularly pipe the result of ls, grep or fd into Helix then use multicursor editing to set up a script. You simply can't do that with a GUI.
Those are not TUIs, or rather, when we say TUI we usually mean interactive UI in the terminal.
GP claims:
> I regularly pipe the result of ls, grep or fd into Helix
Helix is being identified as the TUI here. Terminal text editors are very much interactive.
Helix is a TUI.
Perhaps you should read my comments more carefully before writing a reply.
Gvim is a TUI with a GUI taped on top, and whilst the PowerShell you've given there does call a GUI library function as described, I'm pretty sure the author is referring to non trivial examples of a GUI like sublime or VS Code.
So, I think of articles like this that evaluate "software" or "tools" or the value of "coding" so often miss the huge point of "there are a lot of different kinds of software/tools."
It just depends on what you're DOING. It's all so very subjective. And I think the smart direction here would be for us to be clearer and force ourselves to be more specific when we begin to evaluate approaches like this.
Certain types of work NEED invisible tools. Other types of work NEED "legible" complexity. To say nothing of individual preferences.
I just don't see much value in sweeping generalizations like this article.
Newsflash: it’s 2026. Are you editing your assembly code using dinosaur era text editors?
*not true of hammers (jk, great post)
This is truly a high-quality post. I completely agree with it.
Workflow is tied to one's identity.
Regarding the discussion about Linux desktops in this post, I think the reason Linux lacks popularity as an desk operating system is that programmers want their computers to be not a 'product' but their own personal tool. So rather than preferring a unified system, they tend to want more freedom to modify the OS themselves.
In other words, this is about system customizability, and about 14 years ago, Linus Torvalds made a similar point [1].
Personally, I think the TUI vs GUI debate simply depends on the domain you belong to. Those focused on OS or open source work face pressure to become familiar with TUI, while programmers like me who deliver software to factories face pressure toward GUI. The people I deliver to almost always ask for the same thing: 'Make it understandable without reading the manual.'
On the other hand, most of the TUI and low-level work I've encountered has been dominated by the 'Read The Fucking Manual' culture.
I think people see the pros and cons of their environment depending on where they place their identity. I'm a programmer, but honestly, I don't really enjoy looking at a terminal. I look at the logical structure of my code and the logs when it runs, but I'm not really comfortable with the terminal. But the typical end users I deliver to are even less comfortable with terminals than I am. So I don't particularly like terminal culture or memorizing long command strings. They're just more used to clicking buttons. The problem is that the products we develop don't just stay with developers—they also need to be accessible to ordinary consumers. Of course, those who build tools for developers might not think that way, but I believe that even ordinary consumers should be able to easily operate the software
Others, of course, think differently. In the end, as the author of this post said, it's a matter of identity.
[1] https://www.youtube.com/watch?v=ZPUk1yNVeEI
Skill issue.
100%
An invisible hammer would be more prone to land on your toe.
This is why LLMs are shit. They get between you and everything and turn it into a negotiation.
More often than not, good people too. And there are a lot of them. But a single unrepresentative person yelling in the room is all it takes to break stillness of quiet exchanges.
Yeah, I'm so sick of hearing "it's way faster to install app on linux by using terminal than using that bloated gui softare center".
Huh? Facebook mindless scrolling for drones?
Don’t agree especially with Vim. There are tools you have to learn first to use them properly not to harm yourself.
Author picked wrong analogy.
It is like nagging that excavator has some leavers instead of steering wheel.
Someone nagging they can’t quit Vim is far from Vim being example of bad tool.
Year of Linux on desktop is there as most of games actually run on Linux now thanks to Steam and SteamDeck.
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)
[flagged]
[flagged]
[dead]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[dead]
[dead]
[dead]
[dead]