Live data from Hacker News

How I'm still not using GUIs in 2019: A guide to the terminal

lucasfcosta.com

31–40 of 248 posts

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#31

I always find the benefits of portability to be a rather funny one: It's always immediately followed by 800 lines of dotfiles that do an incredible amount of customization. The IDE vs. vim/emacs purist debate is always crazy to me. There are some places where IDE's are almost certainly better: Java in a large project in IntelliJ has to be 100x better than in Vim. For new languages or languages where there isn't subst…

I’ve recently started opening the large java project at work in emacs because I didn’t want to deal with how many resources IntelliJ uses when I start it up with a huge Java project.

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#32
post #4

I like command-lines. I don't like TUIs. Here's the litmus test for whether a program truly belongs there: Would it shit the bed if its stdout was a printer?

I was going to disagree with you, but after thinking about it I don't think I do.

Vim is a great program that would completely shit the bed if stdout was a printer. However, vim's interface is shit, regardless of how well it works after using it long enough. It's notoriously hard to learn, and the vast majority of non-programming users, IMX, know enough to open a file, make a modification, and save it. Vim would be better if it had a GUI (one more extensive than gVim); that's exactly why SublimeText, Atom, Visual Studio Code, etc. are all so popular. They're vim (they all have vim key extensions), but with the GUI that makes them easier to learn and use. No, they don't have a perfect analog for that one super obscure feature that only you ever use even though you tell other people how great it is all the time, but that's because they're newer programs with fewer features, not because they have a worse interface.

Even programs like top really work better as a GUI. Being able to sort and scroll the list easily, or get contextual information from a process with the mouse is better. Top is good, but it's limited, and not a substitute for a more complete process monitor.

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#33

I always find the benefits of portability to be a rather funny one: It's always immediately followed by 800 lines of dotfiles that do an incredible amount of customization. The IDE vs. vim/emacs purist debate is always crazy to me. There are some places where IDE's are almost certainly better: Java in a large project in IntelliJ has to be 100x better than in Vim. For new languages or languages where there isn't subst…

Or take the best of both worlds with VIM IntelliJ plugin :D.

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#34
post #22

For me, things like VIM where you first have to configure the hell out of it are a pain. Every time you're on some other machine, all your customization is gone. So after switching machines a bazillion times over the years, making the same little tweaks over and over, I've learned to deal with the default config. What I didn't expect: It made me a lot more productive in the long run.

Vim seems like the wrong example. A lot of people use it with just the defaults. Emacs seems to be customized right away by more people.

With emacs, however, people tend to use tramp to edit files on a remote server as if they were local. So, there’s less need for actually using emacs on a server in the first place.

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#35
terminals unfortunately are a complete no-go for "all" Asian languages.

to my knowledge right now no terminal emulator properly handles

* cjk- specially so called double width chars

* Indic- dependant vowels

* west asia- rtl

that's the entire breadth of Asia for you who cannot use terminals if hey want to write a letter in their own language.

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#36
post #18

I'm a game developer mainly writing/reading/debugging C++ on a codebase that's well over a million lines of code. As with most game-dev I'm developing almost entirely using Visual Studio, and I can't imagine trying to navigate code using a terminal based editor. Maybe it's just because this is what I'm used to, however I just don't see how some of the tools would even be displayed in a terminal (parallel stacks windo…

What kind of navigation are you relying on that could not possibly work faster on a terminal?

Horrible ascii graphs look horrible, but they are arguably more functional in that you can navigate them with your keyboard.

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#37
post #18

I'm a game developer mainly writing/reading/debugging C++ on a codebase that's well over a million lines of code. As with most game-dev I'm developing almost entirely using Visual Studio, and I can't imagine trying to navigate code using a terminal based editor. Maybe it's just because this is what I'm used to, however I just don't see how some of the tools would even be displayed in a terminal (parallel stacks windo…

I feel most people that have used a command line workflow that need a GUI for debugging GDB's TUI is generally adequate even with large debugging projects. It's not a perfect 1:1 to the magic that Visual Studio gives you, but it is useful even with very large projects. Then again people who are terminal oriented usually use/look for other styles of debugging compared to people who have a solid IDE where the debugger just has more leverage. There's plenty of projects where all you are going to get from the field is a coredump, so building other methods to triage problems is more important: for instance a reliable replay system to rerun a trapped issue in a test environment.

If you are from gamedev land though everything is rigged around working with Visual Studio, so the debugging strategies/workflow I feel are more related to that than anything else. You also (generally) are debugging relatively locally to the problem as opposed to continents away. GDB and TUI stuff is wonderful if you are 6+ timezones away from the problem.

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#38

Earlier quoted context omitted.

Java in intellij+ideavim is much faster than in (n)vim, and that comes from someone who has been using vim for nearly a decade. Intellij is just too good.

Been using Vim for about the same length of time... And the times I have used those emulators they just haven't been the same. Does the emulator support VimScript? Macros? Plugins? async jobs like vim8? The terminal is my IDE I can open a file with a couple of keystrokes, run bash scripts from inside of my editor and just as easily be back navigating the terminal. Maybe I'm missing something, but I don't see how inte…

What IntelliJ gives you is code generation and automatic refactoring to make writing Java less tedious. That being said, the tradeoff is increased resource usage.

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#39

For me, things like VIM where you first have to configure the hell out of it are a pain. Every time you're on some other machine, all your customization is gone. So after switching machines a bazillion times over the years, making the same little tweaks over and over, I've learned to deal with the default config. What I didn't expect: It made me a lot more productive in the long run.

I would say `git clone` is less painful than downloading and installing an IDE.

Re: How I'm still not using GUIs in 2019: A guide to the terminal

#40

I always find the benefits of portability to be a rather funny one: It's always immediately followed by 800 lines of dotfiles that do an incredible amount of customization. The IDE vs. vim/emacs purist debate is always crazy to me. There are some places where IDE's are almost certainly better: Java in a large project in IntelliJ has to be 100x better than in Vim. For new languages or languages where there isn't subst…

I tend to switch back and forth depending on what I'm doing. I haven't found a Java IDE that can match vim+fzf for speed of editing, and ctrl-n autocomplete is generally good enough. For debugging, refactoring or working with some API where better autocomplete saves looking at the docs constantly I'll switch to IntelliJ.
Post reply on HN