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.
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?
ZSH takes some steps in the right direction with this, with how it handles tab completion.
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
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.
I sort of feel like there should be something like a POSIX compliance standard for keybindings. But the Vim/Emacs divide is pretty big.
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.
> 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.
> 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
> 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.
Sorry, but I don’t think I’m ready to switch to using solely the terminal.
In the future language services may get most of the way there but I think jetbrains will stay ahead.
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 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'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.
- 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.
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)
Did not find any other mail client (although tried mailspring etc) with such powerfull customizations, nothing even close to Mutt.
Sounds like you're using oh my zsh which is seriously bloated.
Zsh and my 20 line .zshrc is basically equivalent to fish. (Only takes 5 or so to get it there)
That said, I have started toying with fish on one server simply because I'm annoyed by the 20 lines.
Similarly slowly moving to vscose but I find the configuration overhead a bit high. Why do I have to specify the same excludes for every plugin?
The main blocker for vscose is that it's just slow. Sublime text feels snappy, even plugin less vscode is sluggish.
8 times out of 10, there is at least vi there.
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.
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.
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'.
No I work on way smaller programs (hundreds of lines), and vim is totally sufficient.
Different tools for different jobs ¯\_(ツ)_/¯
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.
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.
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.
Right now, I only have formatters (which also work as syntax checkers).