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.
This is the same way I feel about CLI only tools. Too much fiddling around with hidden switches and config files for my taste. I'd much rather use a straightforward GUI like VSCode instead of some monstrosity like VI/VIM/Emacs/whatever.
Rote memorization of commands is a ridiculous way to interface with computers in 2019 IMO. I consider it a failure of modern computing every time I have to use a CLI.
Mostly, I blame the automation zealots who have thrown out the discoverability baby with the GUI bathwater. Yes, CLIs are easy to automate. Yay! Why not automate them with a GUI then?
I can't think of a reason why discoverability necessarily needs to be hard in CLI apps. I think all apps, including CLI apps, should have a fuzzy search for all commands.
ZSH takes some steps in the right direction with this, with how it handles tab completion.
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
Yes, defaults are super important! And in my opinion one of the big shortcomings for many cli applications.
I try to keep the defaults when they make sense, and I try to make my configs add to the experience but not change it too much. So it's nice if it's there but I'm still productive on a clean system.
But ^A in tmux is one of those changes, I think ^A is so much more ergonomic (and used alot) that I have it remapped for that reason. But I still have to remember the default binding.
But I think this really depends on your work-enviroment. If you have a lot of different servers I understand that this could get really annoying, especially with all the context-switching. But I just have to work with a few (where I have a minimal setup without zsh) and have all the bells and whistles on my laptop. And I am really a fan of zsh and the spaceship-prompt (the one the author recommends). Easy to set-up and very usefule!
But I think this really depends on your work-enviroment. If you have a lot of different servers I understand that this could get really annoying, especially with all the context-switching.
I wonder why people even work on remote servers? I write the server configuration as a Nix expression and deploy it on a remote machine. This has many benefits - machines become reproducible, you can use your local tools to edit the configuration (I use emacs with nix-mode), and you can deploy the same configuration in a virtual machine for testing with e.g. nixops.
On remote machines that I use interactively for e.g. machine learning, I set up nix + home-manager to have exactly the same configuration and packages as my local machine. On a new machine, I just install nix, checkout my home-manager configuration from git and run home-manager switch.
This setup adds a lot of additional benefits as well, I can always roll back to a previous generation of my configuration, I can use a package that I don't want to install with nix-shell -p <package>, and I can set up local environments with custom packages with nix-shell + direnv.
Nix tackles the problem, but (my impression) requires a complete buy-in and is not really a gradual step. I have also heard bad experiences with mac os.
> 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.
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.’
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.
> 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.
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.
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.
I'm assuming you mean 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 ( 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.
Thanks to Microsoft's LSP (Language Server Protocol), it is now possible to have a decent cross-language IDE experience with any editor that has a LSP plugin such as vim.
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.
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)
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.
Sometimes I feel like it's not vi being so great, but alternatives being not so great. The only other editor you can expect on every shell machine is nano, but sometimes it's such a pain to use. Ctrl-Space to skip a word forwards - ok. Escape-Space to go backwards? Good luck doing that often on TouchBar Macbooks...
Yeah I tried my hand at vim with all its crazy plugins and config to fit in with the other vim gods at work but found myself much more productive with vscode and easyvim
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.
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.
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.
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.
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.
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.
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'.
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)
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.
"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:
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.
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.
"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.
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).
