7 ms·

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

by ventana 3mo ago

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.

persedes 3mo ago
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.
necrotic_comp 3mo ago
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.
- iLemming 3mo ago
  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.
MrManatee 3mo ago
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.
- ventana 3mo ago
  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.
  - bch 3mo ago
    > 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.
- pianopatrick 3mo ago
  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.
bogwog 3mo ago
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...).
- rrvsh 3mo ago
  > 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
overgard 3mo ago
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.
- ventana 3mo ago
  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.
  - overgard 3mo ago
    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)
TacticalCoder 3mo ago
> — 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.
- frollogaston 3mo ago
  That and Python. LLMs will use one-off Py scripts for anything on the complicated side.
- jibal 3mo ago
  When appropriate I use M-S-! or M-S-| to run a shell command in emacs.
  - brabel 3mo ago
    Why not eshell?
- slopinthebag 3mo ago
  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?
  - brabel 3mo ago
    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?
touisteur 3mo ago
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.
- bch 3mo ago
  Then your manager asks you to wrap it in a GUI so your coworkers can use it, and the cycle is complete.
dimsuz 3mo ago
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).
frollogaston 3mo ago
vim isn't really something you use in pipelines though, it's a standalone tool.
- notpachet 3mo ago
  `command_a | vim - -c "file /dev/stdout" | command_b` or, assuming vim is your $EDITOR, you can use vipe: `command_a | vipe | command_b`
- iLemming 3mo ago
  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 https://github.com/agzam/mxp
  - frollogaston 3mo ago
    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.
    - iLemming 3mo ago
      > 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=48876315 ² https://news.ycombinator.com/item?id=48869558 https://news.ycombinator.com/item?id=48869558
      - frollogaston 3mo ago
        Kinda is, maybe I found better ways to avoid or deal with those scenarios.
slopinthebag 3mo ago
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.
- brabel 3mo ago
  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.
  - allarm 3mo ago
    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?
    - brabel 3mo ago
      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).
      - allarm 3mo ago
        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.
iLemming 3mo ago
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.

by ventana 3mo ago

persedes 3mo ago

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.

necrotic_comp 3mo ago

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.

iLemming 3mo ago
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.

MrManatee 3mo ago

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.

ventana 3mo ago
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.
- bch 3mo ago
  > 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.
pianopatrick 3mo ago
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.

bogwog 3mo ago

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...).

rrvsh 3mo ago
> 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

overgard 3mo ago

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.

ventana 3mo ago
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.
- overgard 3mo ago
  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)

TacticalCoder 3mo ago

> — 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.

frollogaston 3mo ago
That and Python. LLMs will use one-off Py scripts for anything on the complicated side.
jibal 3mo ago
When appropriate I use M-S-! or M-S-| to run a shell command in emacs.
- brabel 3mo ago
  Why not eshell?
slopinthebag 3mo ago
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?
- brabel 3mo ago
  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?

touisteur 3mo ago

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.

bch 3mo ago
Then your manager asks you to wrap it in a GUI so your coworkers can use it, and the cycle is complete.

dimsuz 3mo ago

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).

frollogaston 3mo ago

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

notpachet 3mo ago
`command_a | vim - -c "file /dev/stdout" | command_b` or, assuming vim is your $EDITOR, you can use vipe: `command_a | vipe | command_b`
iLemming 3mo ago
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 https://github.com/agzam/mxp
- frollogaston 3mo ago
  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.
  - iLemming 3mo ago
    > 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=48876315 ² https://news.ycombinator.com/item?id=48869558 https://news.ycombinator.com/item?id=48869558
    - frollogaston 3mo ago
      Kinda is, maybe I found better ways to avoid or deal with those scenarios.

slopinthebag 3mo ago

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.

brabel 3mo ago
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.
- allarm 3mo ago
  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?
  - brabel 3mo ago
    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).
    - allarm 3mo ago
      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.

iLemming 3mo ago

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.