Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lucasfcosta.com

Post reply on HN
Print view View original

101–110 of 248 posts

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

#101

Post by rhinoceraptor »

da_chicken wrote: post #32
frou_dh wrote: 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 b…

top would be good to have as a GUI, but I think 99% of people would prefer not to have X11 running on their servers, not least because of how insecure it is.

Also, a surprising amount of TUI apps do have at least some mouse support. Sure, it will never be as good as a GUI app since you can't scroll by less than one row, and depending on the terminal the responsiveness for resizing isn't great, but it is there when you want it.

Also, one of my favorite things in vim is splits. Whenever I use GUI editors the split support seems to be very bad. Some of the Mac OS editors are at least meant to be used with multiple windows, but I think that philosophy of the desktop metaphor is dying out and people are just writing apps to be used full screen.

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

#102

Post by mediocrejoker »

cliff_badger wrote: post #85
plexicle wrote: post #78

"Not every machine has VSCode, Sublime or Atom installed, but every machine has a terminal." I love that the article goes from this sentence immediately to: "These are the main programs I use to make my terminal a complete development environment:" And proceeds to list 5 different programs, some of which are only available on macOS. Brilliant. Edit: One of which are only available*. My point isn't that there isn't a…

What? iterm2 is the only OSX program in that list of five. [edit] Plus, his whole point is that you don't need a GUI to get work done. Not, that you don't need software at all.

Saying that you should learn the terminal because a machine may not have Atom or Sublime is sort of saying that an advantage of the terminal is that you don't have to install additional software, isn't it?

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

#104

Post by dan00 »

olig15 wrote: 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'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.

I'm working with vim on a ~5 million line C++ code base. Thanks to rtags[1] I've all I need: auto completion, goto definition, even semantically correct renaming or finding all locations in code calling a certain function.

I'm certainly not saying that it's as polished as 'Visual Studio', but it works pretty well.

If tooling isn't baked into an IDE - which unfortunately is often the case - then pretty much every editor with some kind of extension mechanism can take advantage of it.

> 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 window, for example) without some horrible ascii node graph.

Yes, most visualization are text based. E.g. for showing the references for a function rtags uses the Quickfix-window of vim, which pretty much is just a list with one entry for every reference. I can now jump to every occurence in the list or even execute an operation on every reference, like I've removed the last parameter of the function call, and now I'm defining a vim substitution command for removing the last parameter and execute it on very item of the Quickfix-window.

Sometimes visualizations are certainly helpful, but I never found them particular useful for software, because the more complex an application gets, the less useful the visualizations become. At some point you're less interested on the class level and more on the system level, but tools can't that easily detect what are the systems in an application.

[1] https://github.com/Andersbakken/rtags

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

#105

Post by 3pt14159 »

olig15 wrote: 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…

For games, especially non-trivial ones, GUIs are fucking great. I couldn't possibly imagine writing game code without them.

Anything else really visual, like CSS, and I need a GUI to feel productive. It's because the changes in the system are dynamic and cascade in unexpected ways. You make a box a little thinner and a heading flows to a new place and now the space between the heading and the image is off, etc.

But I look at that very differently than an overall pronouncement on development. If I'm primarily interacting with data and transformations then GUIs are a disease that do nothing more than slow me down. Only when an analysis is truly one-time does Excel sometimes have an edge, but even there I really miss the adaptability of the terminal. The raw speed. The testability. The sheer maneuverability of it. The permanence.

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

#106

Post by Improvotter »

I want to give vim or emacs a real shot someday. I only really know the basic stuff and am fine with it. But I feel like I really need very good integration with the programming languages I work with like Go and Python.

Besides that, I'm looking forward to see when xi-editor [1] finally becomes a stable alternative to VS Code among others.

[1]: https://github.com/xi-editor/xi-editor

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

#107

Post by giancarlostoro »

estsauver wrote: post #12

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…

My approach is to just setup Emacs once and edit files remotely from my one setup of Emacs. I mostly use Emacs for remote editing, otherwise I use IDE's if resources are limited I go for VIM / Sublime Text. Whatever helps me to work quickly given a situation.

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

#108

Post by wvenable »

nickjj wrote: post #63

I think the biggest win for primarily using a terminal based environment isn't because Vim or other terminal editors lets you write or edit code that much faster. Using command line tools and writing little scripts that you can easily integrate into Vim or another terminal editor really helps you solve your own problems that help make you faster at doing what you're doing. It really opens you up to thinking about how…

Of course, you can bind terminal commands to keys in VSCode (or virtually any other environment) just as easily.

Personally I think these terminal vs. IDE discussions always revolve around straw man arguments and mythical divides. I can chain 5 unix commands together and use my IDE to navigate through code with my mouse. I don't have to choose one or the other and then feel superior about excluding a whole branch of technology.

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

#109

Post by zeveb »

jb3689 wrote: post #15

Title is a bit misleading. Not sure this is "I'm not using GUIs" but rather "I'm using a terminal-based dev environment". I was hoping to find some nice terminal-based tools for browsing and e-mail and all the other annoying real-life things I need to use

I use eww to browse simple web pages when programming, and notmuch-el to read my email. For git I use Magit, and for Slack I use emacs-slack. As you might imagine, that all runs within emacs rather than vim.

In my own case, emacs is running in a GUI frame most of the time, but I often use terminal-displayed frames as well.

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

#110

Post by AnIdiotOnTheNet »

jandrese wrote: post #11
hyperman1 wrote: post #7

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.

This is why defaults matter. People sometimes downplay changes with "well, you can just tweak it if you don't like it", but in the long run tweaking the install every time is effort. Especially when you're working on non-internet connected machines. It's why I get annoyed when for example Ubuntu stops shipping the ability to burn DVDs on the install disk.

Why would you have to tweak it every install? Isn't the whole point of separating the configuration from the application's data so that you can move it around?
Post reply on HN