Discussion is currently still open at <a href="https://news.ycombinator.com/item?id=19270527" rel="nofollow">https://news.ycombinator.com/item?id=19270527</a> .
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.<p>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.<p>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.
I use terminals but I generally prefer GUI.<p>> In Unix, one tries to design programs to operate not specifically with each other, but with programs as yet unthought of.<p>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.<p>> but the more you get used to plain-text, the easier it becomes to type commands rather than to search for options or buttons.<p>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.<p>> The first is that all this abstraction makes people utterly unaware of what the computer is doing.<p>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.<p>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.<p>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.
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...<p>> An IDE limits you to the extent of what their creators envisioned you would want to do.<p>10000+ VSCode plugins disagree with you <a href="https://marketplace.visualstudio.com/vscode" rel="nofollow">https://marketplace.visualstudio.com/vscode</a><p>> Being comfortable in a terminal means speaking the same language as the machine does.<p>No, the terminal and all the programs you start in it usually run on the same abstraction level as a GUI.<p>> Configuration for terminal programs is also extremely portable<p>And GUI application configurations are inherently not?? VSCode config is stored in a single json file?<p>> 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.<p>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.<p>> Finally, being proficient with a terminal is a “learn-once-use-everywhere”<p>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.
I have yet to find a terminal application that can replicate the contextual awareness and refactoring abilities of the Jetbrains family.<p>Sorry, but I don’t think I’m ready to switch to using solely the terminal.
All this points are good but I tend not to invest too much overhead time in my work programs.<p>- tmux (easy)<p>- iterm (easy)<p>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 don't really get the way terminal usage gets framed as outdated, or GUIs as unnecessary depending on one's preference.<p>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.
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.
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.<p>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.<p>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.<p>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.
Ncurses is just a crappy GUI toolkit.<p>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.
>duck-duck-go it<p>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)
When I was working in a large codebase (hundreds of thousands of lines) then I needed an IDE just to be productive.<p>No I work on way smaller programs (hundreds of lines), and vim is totally sufficient.<p>Different tools for different jobs ¯\_(ツ)_/¯
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."<p>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:<p><a href="https://xkcd.com/1168/" rel="nofollow">https://xkcd.com/1168/</a><p>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.