
I'm still not using GUIs in 2019: A guide to the terminal - wheresvic1
https://lucasfcosta.com/2019/02/10/terminal-guide-2019.html
======
JdeBP
Discussion is currently still open at
[https://news.ycombinator.com/item?id=19270527](https://news.ycombinator.com/item?id=19270527)
.

------
crehn
Way too many configs, too many dependencies, too much fiddling around for my
taste. I work on a lot of different servers and nowadays prefer no plugins,
none to absolute minimal configs, and defaults everywhere.

Unless it's a first-class, integral part of the experience (like VS Code), I
don't even bother with any visual adjustments. It just adds cognitive
dependencies and would only be there to satisfy some arbitrary aesthetic
sensitivity. That's no good when things in the wild are rough and dirty. I
don't want to be conditioned to some fragile setup of plugins upon plugins
upon minute adjustments that only works perfectly in some certain pristine
environment.

I enjoy having zero friction when moving around computers. I enjoy getting
things done anywhere without anything ever getting in my way. It's very
liberating.

~~~
ktjfi
That reminds me of myself. I remember when I moved from screen to tmux and the
default "master" key changed from ^A to ^B. All the time lost changing it back
to ^A in .tmux.conf. In the end I simply got used to ^B and that's what I
have.

I've gone as far as to open bug tickets for open source projects arguing that
the defaults should be changed so I don't have to configure as much software
when I move to another computer :D

~~~
pawal
The problem I have with ^B is that the b is too far away from ctrl. A is much
closer, which makes it a much faster one-hand press.

------
Const-me
I use terminals but I generally prefer GUI.

> In Unix, one tries to design programs to operate not specifically with each
> other, but with programs as yet unthought of.

That's what Microsoft did with Word, Excel and most parts of Windows. They all
expose very large API surface allowing them to be controlled by other
programs, or embedded into other programs. No intimate knowledge is required,
both human-readable documentation and machine-readable type info are
available.

> but the more you get used to plain-text, the easier it becomes to type
> commands rather than to search for options or buttons.

Well designed GUI programs use both mouse and keyboard. Users willing to
invest their time getting used to a particular program aren't searching, they
are using keyboard shortcuts. The upside is users not willing to invest time
can still use program, slowly but surely.

> The first is that all this abstraction makes people utterly unaware of what
> the computer is doing.

Even if you know which processes are compiling and linking your code, how
they're launched and how they exchange data, you're still unaware what the
computer is doing. There's an OS underneath all that, managing memory and
scheduling threads. Underneath there're drivers and multiple stacks of
hardware, high-level stuff like USB and PCIe on top of other things eventually
on top of NAND. There's quantum physics underneath.

Thinking about all that might be interesting, but useless with regards to
getting things done. To get things done, you have to stop somewhere. Stopping
at IDE level is not that bad. If it's a good IDE and suitable language, the
abstraction might be almost watertight.

Since the OP talks about programming, here're some GUI-related features I like
a lot. (1) Wavy red lines under spelling errors. (2) Built-in image viewer (3)
GUI-based debugging tools, i.e. live element picker, live property inspector
(4) Profiler: data collection doesn't need GUI, visualization does, to view
these graphs and dynamically adjust what's on them.

~~~
chrisseaton
I don’t understand why going to an option in a GUI counts as ‘searching’ but
setting a text option in a terminal, which I’ll have to look up in a manual as
I’m not going to guess it am I, doesn’t count as ‘searching.’

------
Too
Another of those articles assuming a program with a GUI can't have keyboard
shortcuts, configuration stored in human readable config files or composition
with other external programs...

> An IDE limits you to the extent of what their creators envisioned you would
> want to do.

10000+ VSCode plugins disagree with you
[https://marketplace.visualstudio.com/vscode](https://marketplace.visualstudio.com/vscode)

> Being comfortable in a terminal means speaking the same language as the
> machine does.

No, the terminal and all the programs you start in it usually run on the same
abstraction level as a GUI.

> Configuration for terminal programs is also extremely portable

And GUI application configurations are inherently not?? VSCode config is
stored in a single json file?

> Dotfiles are human readable and contain plain-text. They also become much
> less coupled with your projects than IDE configurations would be. When you
> use an IDE configuration file to describe how the computer should build your
> code you enforce everyone in your team to use the same tool.

Another invalid assumption that an IDE specific config file is not human
readable, so let's replace it with a vim specific config file instead!
(because vim is not an IDE?) Anyway, best practice nowadays is for IDEs to
simply open the standard build-description file out of the box, eg
CMakeList.txt or build.gradle.

> Finally, being proficient with a terminal is a “learn-once-use-everywhere”

Hold on a minute, i just have to copy all my vim-config files, plugins,
bashrc-files and workarounds for even basic functionality such as copy-paste
in tmux to work? Also good luck using PowerShell or cmd on Windows if you are
a die hard linux user. VSCode, Sublime and IntelliJ behaves much more alike
across Win/Linux/Mac than respective terminals. While true that being
productive on a remote ssh shell is an important skill it has very little to
do with what the article describes.

------
Aeolun
I have yet to find a terminal application that can replicate the contextual
awareness and refactoring abilities of the Jetbrains family.

Sorry, but I don’t think I’m ready to switch to using solely the terminal.

~~~
keithnz
They incorporate a pretty decent vim emulator as well.

When I've watched people use terminals on Twitch it feels there's big periods
of times spent swapping around everywhere and a whole lot of mucking around.
Watching people coding real things and dealing with the various normal
problems is a pretty good test of an environment, I've never seen anyone do it
in compelling way where I didn't think it would be faster in an IDE. That
doesn't mean it can't be done, I just haven't seen it and I've been coding for
decades and have a bit of an addiction to watching people code online!

There are, however, many times where it's better to go into a terminal rather
than try and get things done within the IDE, but most IDEs offer the terminal
as part of the experience.

The only downfall of some IDEs is they have little corners of the IDE where
driving them through the keyboard isn't the best experience or not fully
implemented.

~~~
s_m_t
The way I do it in vim is to have one terminal window with vim open, and one
terminal with a couple of tabs for git, compiling, and flashing for embedded
stuff or server for web stuff.

The important part in vim is for me to start it by opening ALL the files in my
project directory and then just have two side by side windows. I never muck
around with the file viewer or creating new windows. So other than the
commands you expect from general text editing, searching, and swapping buffers
(fuzzy search plus ctags makes this comparable to the ide's I've seen) the
only vim commands I use are... Focus window right, focus window left, and
save.

I used to waste time mucking about as you say until I saw Casey Muratori
coding for handmade hero in emacs with pretty much the same setup. He takes it
a step further by not even having separate buffers, he just seems to put all
his code in one big file.

~~~
keithnz
I'm assuming you mean
[https://www.youtube.com/watch?v=hbmV1bnQ-i0](https://www.youtube.com/watch?v=hbmV1bnQ-i0)
? If he's putting code into one file because it is easier to manage while
using terminal based editing, that doesn't make a good case for using those
tools.

I've seen similar demos of peoples "enviroment", but they are all demos, not
actually doing real dev.

I did see [https://www.twitch.tv/curlhacker](https://www.twitch.tv/curlhacker)
( guy who made curl ) and he worked on real issues, he worked pretty well, but
I didn't see that it was any better than using an IDE...sometimes it seemed
more awkward Unfortunately his coding videos have been deleted, there is one
still image which shows his multi terminal setup

What I like seeing is, project setup, debugging, acquiring packages, API
discovery, refactoring, unit testing, navigating code / multi file management,
git management, etc. Seeing developers struggle with the natural frictions
that occur is much more interesting I find.

------
therealmarv
All this points are good but I tend not to invest too much overhead time in my
work programs.

\- tmux (easy)

\- iterm (easy)

Using zsh, no. Too much bloat and configuration for me. Fish shell (plus
something like Fisherman) is from the start much easier to (pre-)configure.
The same with neovim. Nothing against it but I started my career with
Notepad++, Ultraedit going to Sublimetext (in between some IntelliJ) and
nowadays vscode which again is with less configuration a really productive
tool. I never had too much time to spare to invest into a new editor concept
and I also disagree with vim keybindings for daily work (python and web
developer mostly). The terminal is nice but not the only productive solution.

~~~
dijit
I think anyone that says there is “one true way” to be productive is probably
selling something (or they’re suffering from some kind of sunk cost fallacy).

If you have something that works for you then that’s great, personally I see
the appeal of intellij IDEs (I’m a very light user of PyCharm)- but most of
the time I end up in the terminal.

My personal belief is that terminal programs have a much higher learning curve
in the beginning but can be much more powerful in the mid to long term, and
the constraints of not using graphical elements or being able to place
anything anywhere actually leads to a more cut down and consistent experience.

I’d be using Mutt if it weren’t for the extreme prolificaction of html in
emails.

But yes, YMMV and I dont think we have to be zealots about how we work unless
you put constraints on other people for working much different. (For instance
if I tried to force everyone to send text-only emails)

~~~
ijelenic
I still use Mutt, combined with offlineimap (due to exchange mail server), w3m
for for converting mails from HTML, using markdown to write email, and pandoc
to format back to HTML... Works like a charm!

Did not find any other mail client (although tried mailspring etc) with such
powerfull customizations, nothing even close to Mutt.

------
eponeponepon
I don't really get the way terminal usage gets framed as outdated, or GUIs as
unnecessary depending on one's preference.

They're each for very separate use cases - tasks that are easier done in a
terminal belong in a terminal and those that are easier in a windowed idiom
belong there.

~~~
danieldk
I fully agree. There is a place for both. Even though I use TikZ every once in
a while, if I need to draw some graphs really quickly, nothing beats a GUI
program like OmniGraffle. Or if you need to touch up a photo, you could spend
a lot of time tinkering with Imagemagick, but it's much easier to just fire up
Lightroom or Pixelmator.

Even for editing, I sometimes prefer GUIs. E.g. X11/Cocoa emacs can render
LaTeX equations inline in AUCTeX or org-mode. This is sometimes very
convenient for quickly verifying whether equations are correct during writing.
Similarly, with org-mode, you can show R or gnuplot graphs inline.

On the other hand, when you are automating a build, doing some custom data
extraction, configuring a server, etc. nothing beats the command-line.

A skilled person knows what to use when.

------
hestefisk
Interesting read. I do find it ironic though that the author starts out by
dismissing Vim plugins as bloat (praising vanilla config), praises the need to
never stick stuff in a config file you don’t underhand, and the goes onto
inatalling oh-my-zsh. That makes no sense.

~~~
chewz
Agreed. Getting rid of oh-my-zsh had been one of the best decision in my life
within terminal. Over years I must have gained hours and days of cumulative
productive time from this single decision.

------
k24883
This posts pretty much outlines all the things that I do as well. It is true
that in going this route there needs to be a time investment at first (and
some fiddleing throughout) but once you're set, there is no need to jump on to
the next hot editor and learn new keybindings.

Where I disagree is the notion that a dev environment based on the terminal
beats an IDE. If you are using a language with a huge (type-sensitive) API or
a complicated framework, nothing beats an IDE for its auto-completion.
Especially if you don't have a black belt in that language/framework yet. You
can use ctags and auto-completion plugins but nothing beats the code-
introspection developed for IDEs.

If you don't code against complicated APIs, there is nothing that beats long-
term productivity with a deep understanding of the terminal and an editor that
is with you for many years.

Even if an IDE is the better choice for day to day work, it is beneficial to
be comfortable in the terminal. I sometimes find it hard to believe how
uncomfortable coworkers are when they have to do some work on a remote server
and what length they go through not to use the terminal.

------
zokier
Ncurses is just a crappy GUI toolkit.

For local work, vast majority of the benefits of using ncurses based
applications over X11 ones are cultural and not technical. In similar vein
using terminal vim over gvim, or using tmux over just tiling wm does not
really gain you much.

------
0x38B
>duck-duck-go it

DuckDuckGo is my primary search engine, and I like this. If I said this, most
of my friends would go 'Huh?' \- good way to spread awareness. Even if it's
more awkward to say than 'google it'.

~~~
timbit42
Three syllables versus two. This must be one of the reasons Microsoft went
with Bing.

------
aldanor
Could anyone recommend a good “terminal/shel guide” for people not familiar
with the shell and gnu tools at all? Like ls, cp, less, find, grep etc and why
is it all needed? (not for myself; for some friends who are learning coding on
macs)

~~~
knolan
This is an excellent start once you get over the mage conceit:

[http://unixmages.com/wp-
content/uploads/2018/12/ufbm.pdf](http://unixmages.com/wp-
content/uploads/2018/12/ufbm.pdf)

~~~
aldanor
Thanks a million, never seen this one, looks quite awesome!

------
xwvvvvwx
When I was working in a large codebase (hundreds of thousands of lines) then I
needed an IDE just to be productive.

No I work on way smaller programs (hundreds of lines), and vim is totally
sufficient.

Different tools for different jobs ¯\\_(ツ)_/¯

------
shams93
With emacs I can run eslint from the terminal, also other things like gcc
debugging you get the advantages of an ide's interactivity without needing a
gui to run it.

------
hutzlibu
"but the more you get used to plain-text, the easier it becomes to type
commands rather than to search for options or buttons. The hard part is to
remember which commands to type."

And this is where terminals suck and IDE's are strong. Integrated autocomplete
and documentation. I do not need to remember every function or parameter, but
I can directly look them up, while I type. Is there something like this for
terminals? I have not seen it, yet ... so, to put it in a picture:

[https://xkcd.com/1168/](https://xkcd.com/1168/)

But yes there is man and --help, but it is not really straightforward and
fast, like a modern IDE. And usually I never find in time in --help what I am
looking for, so am faster with googling anyway.

~~~
turbinerneiter
There is a whole bunch of shells with all kinds of autocomplete. Terminal
editors like vim have plugins for autocomplete and integrated documentation.
CLI programs typically have -h or --help.

The whole "Terminal vs. IDE" argument is kinda weird. You can have an IDE in a
terminal. This whole thing is about CLI/TUI vs. GUI, not terminal vs. IDE.

~~~
hutzlibu
"this whole thing is about CLI/TUI vs. GUI, not terminal vs. IDE. "

Good point.

But can you recommend a vim setup with plugins? It has been a while since I
tried it, and it was not to my liking, but I was more GUI adopted at that
time.

~~~
turbinerneiter
I'm the wrong guy to ask, I kinda dislike IDEs. I use vscode sometimes,
exactly for the code completion and integrated documentation you mentioned.
But I often use vim for the lack of that. Every helper can also be a
distraction, every functionality is an interface you have to learn.

Right now, I only have formatters (which also work as syntax checkers).

