Posted by theanonymousone 1 day ago
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.
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.
This helps being as invisible as possible.
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.
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.
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.
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.
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.
I don't have anything else to add but I thought this was a wonderfully evocative phrase.
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".
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 is a visionary but as an actual software developer he's pretty mid.
Tell me what Carmack has written that’s still widely used but did not start with the same “problems” as emacs.
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?
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
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.
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.
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.
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.
— 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.
cat packages.json | jq .scripts
ctrl-p -> packages.json <enter> -> ctrl-f -> scr
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.
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.
> 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.
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)
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.
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.
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!
...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.
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.
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.
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 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 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.
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.
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.
or, assuming vim is your $EDITOR, you can use vipe:
`command_a | vipe | command_b`
> 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.
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.
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.
Also thanks confirming the multiple cursor YAGNI for vim, could never wrap my head around needing it in the first place.
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.
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.
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.
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.
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.
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.
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.
There is more than selecting options. Selecting text is normally better with a mouse.
Your argument is sound but this overstates your case a bit. There's a reason we don't type with our toes.
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.
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."""
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.
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.
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).
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.
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.
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.
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.
Vim, not so much, maybe I don't know enough who use vim besides myself.
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 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 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.
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.
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.
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!]
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.
> 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.
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.
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.
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.
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.
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).
Search for “vim puzzle” and you’ll find entire websites dedicated to it. Here’s a random one: https://vimventure.dev/
> 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".
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.