How I'm still not using GUIs in 2019: A guide to the terminal
lucasfcosta.com
lucasfcosta.com
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 place for GUI and terminal, it's that "not every machine has x and y software" is a fruitless argument.
If I knew I'd always have Mac as a client, I'd probably switch to using Tmux instead of Gnu Screen just for that reason.
On systems I don't administrate using these fancier new tools are a pain. I either have to bug the sysadmin to install my pet set of tools or try find static compiled versions, or try and build them myself in my homedir. I feel like I've wasted a lot of time jumping through hoops for things to mostly work with old versions of things. AppImage (what neovim offers) requires Fuse. s.minos.io which has a handy app to download static builds, is missing new versions and many packages I'm looking for.
The situation for Terminal apps is often worse than GUI apps.
As an aside, the only things I've seen gain traction with old-school Linux users are alternatives to grep since they're so much faster, have better defaults (like honoring gitignore), and are generally compatible with grep's arguments.
I know I can SSH into any random machine, and edit a config with the copy of vi/vim it has, even if it doesn't have my fancy plugins.
And if I get a new machine, all I have to do is install my tools via Apt/Brew/etc, clone my dotfiles repo, and run an install script.
Basically it doesn't have to be an all-or-nothing sort of deal. Just find the combination that makes you productive, and if you find that your productivity is suffering because of one of your tools then address it accordingly.
So far this article reads more like a zealous hyperbolic "It doesn't matter if you think you're productive. You're deceiving yourself and your tools are trash"
If I get a new machine I only install
- dotnet core
- Visual Studio Code
Finished.
Both are available on all mainstream platforms that you might want to use, including Linux, Windows and Mac.
Why even use a computer then? Aren't rocks and sticks an even lower common denominator?
The android phone I'm currently messing around with had neither vi nor vim...
Yes, knowing the lowest common denominator is great. But doesn't make a great dev environment. OP is describing how to set up a customized one for exactly that reason.
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.
That said, being able to work with standard tools is extremely relevant for debugging problems, still.
There are many environments that are CLI only. That’s what the author is talking about. You’re talking about environments that don’t allow you to install apps. That’s a completely different discussion.
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.
GUI's are definitely more than just bloat. Possibly not for what the author us developing, but there is definitely a use for IDEs/GUIs.
Note I'm not knocking down on IDEs; as an Emacs user I would love reliable semantic indexing and navigation, but all the solutions that I have tried (rtags was the best) consume a lot of time and CPU indexing and switching branches often forces a rebuild. Currently, on a 1M lines code base I get around with projectile (which uses the project git as a file index) for file discovery and ag for brute force search, which at least on linux can search the codebase quickly.
If you are from gamedev land though everything is rigged around working with Visual Studio, so the debugging strategies/workflow I feel are more related to that than anything else. You also (generally) are debugging relatively locally to the problem as opposed to continents away. GDB and TUI stuff is wonderful if you are 6+ timezones away from the problem.
It is also possible that the kind of things you are debugging also don't fit Visual Studio and better served by tools and things like WinDbg. This comes up when you are doing kernel driver debugging or really having to work with lots of symbol server shenanigans when you have kernel dumps from all sorts of random versions of Windows.
There's a lot of tools out there, and Visual Studio is often not the best tool for the job even for debugging. Settling for Visual Studio has its own set of compromises. As I mentioned for gamedev the Visual Studio experience is the current de facto standard for engines like unreal and as far as I am aware many of the SDK's for consoles, and all of the asset creation tooling from Maya, 3dsmax, etc. There are just other things that exist in the world than the primary pipeline that Visual Studio services with fantastic tech.
I have to use the VS debugger at my workplace, and even as someone who has merely dabbled in GDB a bit, I recognize that it's so far out of VS' league, it isn't even funny.
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.
The visualisations I’m talking about are mostly debugger tools. The parallel stacks view is life saving when you’re trying to figure out a deadlock. Having to scroll around this huge viewport with a cursor would just piss me off. I just can’t see how you could navigate a huge (10x screen width) node graph in a text terminal using vim style commands.
I had a look at parallel stacks and it looks nice and seems quite helpful. But I have to think, if you have that many threads that might deadlock and it happens often, if your architecture might be the issue.
Most of our parallelism is job based. There is a job queue and worker threads are taking jobs from it. So deadlocks are pretty much a non issue for us.
I‘m not trying to say that everything you‘re doing is obviously wrong, but the older I get the more suspicious I‘m getting if there‘s a need for „fancy“ debugging tools, because it might mask that there are some more serious issues in the application.
For a game or similar code that's sometimes too much RAM, and usually too much latency.
It sounds lame early in your career, but after a while, switching between C++, java, JavaScript (ok this one requires a little more involvement because the browser is the compiler of sorts), typescript, etc is very easy.
When you switch languages/projects it is just a matter of opening a file with a different extension. All your text editor muscle memory is still there.
If you use IDEs, today you are on a project that only builds in eclipse, tomorrow intellij, then you move back to C++ and have to use visualstudio... and you don't even know the Go To Line keyboard shortcut or Text Search...
Since he started streaming he has moved (from emacs?) to I think http://4coder.net/, which seems to have spawned from his audience. Similarly, a few debuggers have, too. https://remedybg.handmade.network/ https://lysa.handmade.network/ but I think he still uses VS' debugger.
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.
Do you have some GUI for manipulating CSS with click&drag? Otherwise, isn't this use case handled by having an editor and a browser simultaneously open, and connected via live code reload. A web IDE can do this, but any other editor can do this too.
This approach does work in gamedev too, but it's not popular - mainly because languages supporting REPL-driven development on live images are not popular in this sector.
I agree though that there are tasks where GUIs are superior. But we're not talking about "regular" GUIs here, but domain-specific ones. Say, 3D editing. I can't imagine doing that from Emacs - the interface would heavily retard the feedback loop, in the same way GUIs slow you down when writing code. But then, Blender shows how one can apply Vim philosophy to 3D editing, resulting in a tool that embraces power users while still being GUI-driven.
I do a decent amount of CSS / HTML editing live in the chrome dev tools. I even sometimes move elements around by dragging them in the DOM tree UI. It can be a nice way of experimenting with UI design, as the feedback loop has less friction and can be much quicker, in some cases.
One workflow is to write out an initial sketch of the HTML structure, with little to no CSS. The first round of the styling is then done in the dev tools, tweaking until it seems ok, then copying those styles from the inspector stylesheet into my code and saving, and then iterating further as necessary.
Horrible ascii graphs look horrible, but they are arguably more functional in that you can navigate them with your keyboard.
Made me smile. This is a great analogy. Tactics vs strategy. You can become more efficient at low-level tasks by doing faster text editing. However, as you get into actual software engineering, the first time you need to do some semantic refactoring will wipe out any time you saved through low-level efficiency.
That applies to Java and C# only, where the language grammar is so simplified that you can be 99% confident semantic refactoring didn't screw your code up.
> You can become more efficient at low-level tasks by doing faster text editing.
It's not efficiency for efficiency's sake. It's for being able to code at the speed of thought, to tighten your feedback loop to the point where the act of writing & editing happens in your mind in larger syntactical units.
Also, for actual software engineering, nothing beats a pen and a piece of paper.
Sometimes I use pen and paper quite effectively, but between the slowness of writing and the difficulty of editing, I wouldn't describe it as ideal.
Some of us would say well-designed instead of simplified :-)
That's a longer topic. Having worked professionally both with Java (Eclipse, Netbeans, IntelliJ IDEA) and Common Lisp (Emacs + SLIME), I've experienced both sides of the coin. On the one hand, working with a language without a proper REPL and macros is painful to me. On the other hand, I frequently wish it was even possible to have semantic completion and automatic refactoring in Common Lisp, even at 10% of what you get for Java out of the box in an IDE...
With that, the only remaining thing in which IDEs are a better choice than vim or Emacs is debugging. I wish for decent and fully featured debugging TUIs.
https://code.visualstudio.com/api/extension-guides/debugger-...
I imagine Emacs, vim, and friends could implement their own frontends for this, much as has been happening with LSP.
And it turns out, Emacs and vim do implement their own frontends for this - [0], [1]. My wish just literally came true!
Here in spaghetti enterprise land it is. Quite often the biggest challenge to any given story is understanding the impact of a single line change on a code base.
And since we decided to split a single bowl of that spaghetti into nuget packages the more "primitive" tools like ctags are the best way to navigate the project, they don't care about pesky things like dll boundaries.
Isn't that a test coverage issue more than a navigation issue ?
Opening 3 files via keyboard shortcuts vs opening them by clicking on 3 different buttons won't solve spaghetti code and low test coverage.
> Opening 3 files via keyboard shortcuts vs opening them by clicking on 3 different buttons won't solve spaghetti code and low test coverage.
It doesn't solve it, but it makes it quicker and easier to navigate, it's not just the shortcuts but the navigation stack (go to declaration, go to declaration, go to declaration, pop, pop, got to declaration, pop, pop, etc) that make it easy. Tmux and/or vim are also much better at multi-window editing than IDE's which is also handy.
Most navigation is done using keyboard shortcuts, but I can use the mouse to click around menus if I forget where something is.
Visual Assist X is terrible and extremely slow. Also, it is a clutch, showing one of the biggest weak points of Visual Studio.
I use it in a daily basis for more than 7 years, and I just hate it. VS is such a mixed box of feelings, it is so bad for most of it but then there is a very good debugger, arguably the only thing holding VS alive.
I would prefer to switch to a better text based IDE or even vscode and use windbg, if it wasn't for co-workers with Stockholm syndrome that can't see how bad their tools are.
This is only true, firstly, when what you're trying to represent can be accurately, completely, and most concisely represented by plain text. That's actually a fairly narrow range, unless you're a programmer. And secondly, it's only true when you're not interested in using common interface conventions to teach your users how to use your program. While that can certainly be done -- the -? and --help parameters spring to mind -- it's much easier when there are UI guidelines [0] that everybody sticks to simply by virtue of how GUIs tend to work (i.e., there are existing common libraries to describe the interface in predictable ways).
If everything you do deals with text (i.e., you're a programmer), and you never or rarely need to use unknown programs, then the terminal is great.
Think about it this way. Exactly what have you had to do to learn how to use web pages? Like, since the 90s when Mosaic would still render most websites. You haven't. It's point, click, scroll, and type. That user interface has worked, essentially unchanged, for nearly 30 years. You've gone to brand new websites, potentially written by people who don't speak your language, and you've been able to use the site because there's a shared convention that everybody uses. And everybody does use it. There are 4.2 billion users of the world wide web [1], and the interface works for essentially everyone. That's an extremely impressive feat for interface design.
Meanwhile, nearly 50 years after vi was first introduced, it's still notoriously difficult to learn -- even the basics. You might argue that programming is more complicated than browsing the web, but realistically, editing a text document is about as basic a task that you can have on a computer.
[0]: https://docs.microsoft.com/en-us/windows/desktop/appuistart/... [1]: https://internetworldstats.com/stats.htm
Intuitiveness and power are often opposing goals. You often see a way to make an interface more powerful, let the user work more effectively and/or efficiently, at the cost of intuitiveness and having to increase a learning curve.
In your last paragraph, I feel you mean to imply that vi failed in its UI design, but I think it's one of if not THE best UI design I've ever come across. There was a learning curve, yes, but I don't care, it was well worth it given how much it's improved my efficiency of anything text-related in my work. The cherry on top is that shells and any readline-based REPLs implement vi keybindings, so learning how to use its UI has become tremendous leverage, since this means that vi-keybindings become the new main text-editing UI convention system-wide.
I don't understand your point about the web-browser. You say how great it is that its UI has not changed much (although I think it has) in so many years, then you say how bad it is that vi's UI has not changed much in so many years. Also, web-browsing is mostly about text, so I can't see it being much of a contrast with your earlier point about terminals being better for text things.
About having conventions, CLIs probably have more conventions than GUIs, so I don't really get that point either. It's not just about --help, the concept of options, of long ones, and short ones, and them having arguments and all that are conventions. vi and emacs keybindings in many CLI programs are also conventions. If having conventions is great, I think CLI has GUI beat.
I believe that intuitiveness always helps with power. It’s just that the audience when defining intuitiveness shouldn’t only be limited to newbies. Unfortunately, we seem to conflate “intuitiveness” with “intuitiveness for newbies”. However, if you’re creating new power features, those features will always be better served if they are more intuitive for the intended users, I.e. power users. (conversely, they will be worse off for power users if they are designed to be intuitive to newbies).
EDIT:
I think a good example of intuitiveness aiding power would be shortcuts in Vim vs. Emacs. In Vim, shortcuts are created as a grammar, and they're to a great extent consistent. They tend to form "verb modifier(s) object" combinations, and each of the components can be learned separately[0]. Whereas in Emacs, there are bunch of conventions, but beyond that, shortcuts tend to have a form "modifier verb-phrase", with "verb-phrase" mapping directly to some command. This results in much less consistent - and thus much less intuitive - set of keybindings.
--
[0] - See https://medium.com/@rafeco/the-grammar-of-vim-f86482876f46 for elaboration on the topic.
> Unfortunately, we seem to conflate “intuitiveness” with “intuitiveness for newbies”.
I either can't think of another kind of "intuitiveness" or we have different ideas of what constitutes a "newbie".
> However, if you’re creating new power features, those features will always be better served if they are more intuitive for the intended users, I.e. power users. (conversely, they will be worse off for power users if they are designed to be intuitive to newbies).
Ok, yeah we have different ideas of what's a "newbie", and apparently what's a "power user". I think your definitions depend on how much experience they have with computers in general. Actually, no. I think it depends on what kind of programs a user has experience with. Like users of GUI are newbies and users of CLI are power-users. That's the only way making something intuitive for power users makes sense. After all, making something intuitive is about following existing conventions, so we're differentiating "newbies" vs "power-users" based on the conventions they follow. Sorry, if I misunderstood you here.
For me, "newbie" and "power user" do not imply anything about their experience with other related systems, only with the system that is the object of conversation. In that respect, by definition, you can't make something intuitive for power users. Every person on first touching a system (a software program or otherwise) is a newbie, regardless if that newbie is not a newbie anymore in another system.
A "power user", for me, is someone willing to accept a learning curve to best do whatever a system is designed to do. That basically means someone that is willing to read a manual of what he uses, though they can also do other things like practicing and reading the source.
So, on first touching a piece of software, everyone is a newbie, and some become power-users.
Designing for intuitiveness vs power is about favoring those that wouldn't be willing to study a little and become power-users vs those that would.
When I say that, I don't mean that power will always come at the cost of intuitiveness, but I do mean that some design decisions could be made that favor power at the cost of intuitiveness.
An example of this is vi's modal editing and its normal mode language. If you put someone that's never touched a computer before in front of 2 computers, one with Windows's notepad and the other with vi, with no documentation whatsoever of either, which will he be able to use most effectively first? notepad. The user just needs to press any letter key and he'll see the characters appear on screen. He'll be writing paragraphs in seconds (if his lack of touchtyping ability wasn't an issue). In this respect, vi's modal editing is not intuitive. It's a cost vi paid for implementing a mode that allowed a whole keyboard's worth of buttons to communicate to vi different editing and navigation procedures most efficiently.
> I believe that intuitiveness always helps with power.
With the context of the above, getting rid of normal mode would make vi more intuitive, but it would certainly not help with power.
You would be surprised. I encourage you to visit the lands of Emacs at some time. The reason Emacs feels like an OS is because it turns out that quite a lot of tasks can be accurately, completely and concisely represented as text on a 2D grid, and doing so enables interoperability features that are close to impossible to achieve with GUIs.
> And secondly, it's only true when you're not interested in using common interface conventions to teach your users how to use your program.
Well, the difference between a tool and an educational toy is that the former is optimized for productivity, not ease of learning. I'm not saying that productive interfaces need to require a PhD to use; there are ways to make user-friendly advanced UIs - but reducing functionality for the sake of just easing the learning curve is optimizing for popularity, not utility.
> it's much easier when there are UI guidelines [0] that everybody sticks to simply by virtue of how GUIs tend to work (i.e., there are existing common libraries to describe the interface in predictable ways).
Which no one gives a flying fuck about these days, because everything is web driven now, and the no.1 rule of webapps is that everyone invents their own variations of GUI, inconsistent with every other variation, and lacking any interoperability.
> Exactly what have you had to do to learn how to use web pages? Like, since the 90s when Mosaic would still render most websites. You haven't. It's point, click, scroll, and type.
I think you're confusing lack of functionality with lack of learning need. You have to learn to operate almost every website anew. There's just so little you can do on a modern website with modern browser, that it doesn't feel like a chore. Scroll, point, click. Oh, "weather forecast", click. Select city. Click. Select date. Click. They're not even optimized for consumption - just for ad exposure. Your typical experience with CLI/TUI is with tools optimized for providing value to the user. You may need to spend some more time up front figuring things out, but as a reward, you get much faster repeated access, better data, better control over format, _only_ data you need and zero noise. Is this for everyone? No. You do something once every year, point&click is fine. Stuff you do regularly? Web is wasting your life.
> You've gone to brand new websites, potentially written by people who don't speak your language, and you've been able to use the site because there's a shared convention that everybody uses.
That shared convention - "use mouse to click on stuff" - is about as deep as the convention of "pressing buttons on keyboard types letters in". It doesn't make you comprehend websites. It only limits the scope of your initial confusion to "I don't need a keyboard for this (unless there are forms)".
> nearly 50 years after vi was first introduced, it's still notoriously difficult to learn
It's not difficult. It's just people have been trained to have a strong aversion to learning, where it comes to computers. Everything must be easier to use than your hair dryer, or it's garbage.
To anyone who believes this, that vim is hard to learn: I ask you to do this challenge. Fire up vimtutor, spend 10 minutes on it, report back whether it's still hard.
--
I may sound confrontational here, but it's really just out of care. Truth be told, love of GUIs and the web, and allergy to CLI and TUIs is just reducing your own power in using computers. If one has better things to do, that's fair. But if one's spending a lot of time doing stuff on a computer, it's worth learning to do it well.
I'm learning right now - as in, I started on Sunday. It's not hard to learn, but it's hard to use effectively. I could edit code twice as fast if I reverted to my standard keybindings, but I'm waiting for muscle memory to build.
Learning isn't hard, but building muscle memory is a tonne of work. It's like learning to touch type all over again.
Another important point is that one should never try to move around in INSERT mode. If you do, you're limiting yourself to moving around with the arrow keys and also are grouping multiple edits that you may want to undo piece by piece with u. If you need to move around, change to NORMAL mode and then move.
Yes, it's normal to hit Escape a lot. Personally, I like to have CapsLock act as Escape with `setxkbmap -option caps:escape`. If I ever really want to write something in all caps, it's always seemed faster to hold Shift with my left pinky.
> It's like learning to touch type all over again.
A very apt way to put it. Touch typing is like learning a language for your fingers. You do it once for your language (e.g. English), and now you're doing it for vi NORMAL mode, which is basically a language for text editing and navigation.
Like TeMPOraL said though, if you feel the frustration getting to you, you can just relax however much you want, and take things at the pace most comfortable to you.
Muscle memory does take time to build up, but it goes much faster if you don't try to take on too much at the same time. Just focus on small pieces at a time. Spend 30 minutes fully focused on basic semantic navigation (forward/backward by letter, word, paragraph, expression; up/down by line, page). Spend another 30 minutes on navigating via incremental search (an extremely useful trick, it can easily replace half of your navigation). Etc.
(This is my tried&true method I used to master various tricks in Emacs.)
Also relax, and notice that half your frustration comes from the fact that you already know another set of conventions, and it's tempting to just stick to it. But the new one will get easier very quickly :).
Damn right! It's crazy how much people are against learning even a little bit.
I don't know if it's either that greater adoption of computers is exposing this, or if people have actually become less willing to learn, maybe because of what they call "information overload" from consuming so much more information day-by-day through the web.
I used to use git only on command line but after switching to a GUI I find I'm way more productive.
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 substantial IDE integration, it's probably 5x better in Vim/Emacs with a nice configuration.
I think i am more productive in an IDE, faster. Sure if you have this insane VI/EMACS setup that you have tuned for years. Good for you, you probably are a fucking wiz.
My standard right now is a terminal & IDE combo. Working in the cloud era as a data person, you need to be comfortable with terminal & vi/emacs (vi for me but whatevs) as it makes life a ton easier. I hate watching co-workers do terminal shit and write code. Seriously guys if you invest a little time into VI pretty soon you are flying around your code. People literally watch my screen and are like WTF are you doing. I feel like a surgeon with precise incisions, cuts, tweaks. Compare this to spamming down arrow 30 times and then right arrow 80 times to get to a character in your editor...
To share a glimpse of the mindset of us on the editors side: that insane Emacs setup I've been tuning for years enables me to be "a fucking wiz" not just with Lisp. The very same setup lets me work efficiently with Python, Shell, configs, SQL databases, HTML+CSS+JS, running a personal Wiki, organizing tasks, tracking time spent on those tasks, billing customers for that time, reading/writing mail, and a bunch of other things. We love our editors because of compound interest - we get to reapply the same tricks to almost every task done on a computer (and we complain loudly when we can't shoehorn a task into editor-oriented workflow :)).
That said, I'll still grant you're better off with IntelliJ IDEA for Java. For the time being, at least. I'm having high hopes for language servers trend - they're the bridge that could enable vim and Emacs to reach feature parity in all the places they're currently deficient compared to IDEs.
I think that's really the takeaway here. Spending time in your environment allows you to accumulate skills that let you solve pretty much any text based problem you can think of.
Whether that's using emacs with elisp or vim with shell scripts and Unix tools isn't important. It's having that playground of an environment to solve arbitrary problems.
Or uses the mouse to get there. I don’t get that part of vim. Weirdly I do like Vim. The thing is you see something in sublime, you just click on it and you there. You don’t have to solve some vim puzzles to get the cursor on the right spot.
I think you described the base of most arguments in that direction right there. The problem to either side isn't so much what the other side's doing (who cares, really? To each their own…).
Usually, those discussions are fueled by people asserting how obviously the respective other side is inferior without having even had a proper look at it. My bias tells me there's much more of those on the IDE side, but I expect that's due to the way people are introduced to programming (if one "population" tends to be much bigger than the other, I suppose there's a higher chance of someone belonging to it starting a flamewar. And, of course, if it's also prone to have more newbies in it, the probability of… unaware statements also rises).
Personally agree with this part.
For those who need it because they are used to vim style editing most ides (at least on the Java side, + VS Code for everything else) has vim modes.
For those who have never used it and think they need it because it seems so cool and "everybody" uses it: You don't need it, at least not right now. Most great developers I know actually don't use vim for programming high-level languages, even if some of them use vim modes.
Instead I'd recommend:
- Use a decent mainstream IDE
- Memorize shortcuts for selection, search, replace, global search, global search and replace.
- Learn to use the included refactoring tools
- Learn to use the built in VCS tooling (or try and fall back to the console for VCS handling).
I have known several vim purists who are extremely productive in Java/Scala/Kotlin.
I both understand and respect your preference for Intellij. But, your dismissiveness of others is misguided.
By analogy, I don't believe that a chainsaw is either a bad tool or that it's impossible to make good art with a chainsaw, but I do believe most marble sculptures would be better suited to a chisel.
vim is a lot closer to the chisel, while intellij is closer to the chainsaw.
IntelliJ is really great at managing large, statically typed, Java/Scala/Enterprisey frameworks. I have never seen a vim setup that effectively generates and manages javabeans. I have never seen a vim setup that manages an xml spring configuration file correctly (or even understands how to resolve xml namespaces and validate them.)
But vim is very lightweight, it's incredibly customizable, it's adaptable. It is faster for editing text. If you're writing a new language that doesn't have integration with IntelliJ's language protocol, it's probably better. If you need to jump into the source code of other libraries to understand what's going on, Vim tends not to be good at that sort of thing.
Regardless of which you think is the chisel and which is the chainsaw, there are some software engineers trying to cut down trees and some trying to make marble statues. The "all software engineers who don't use my tools are fools!" mentality doesn't make sense.
I've worked directly with several VIM devs on Enterprisey frameworks who were not held back by their lack of Intellij.
Do you recognize the irony in that statement?
"In general it's usually a Sith that speaks in absolutes."
There is some deeper, irrational motivation in people who make this argument.
https://github.com/Ruin0x11/intellij-lsp-server
(Though unfinished, it's at least proof the concept could work.)
Personally I use omnisharp at work for C# projects, on Windows, and am able to accomplish all the tasks I need to do except debugging entirely in emacs, and get refactoring, diagnostics and completion.
I'm not seeing a contradiction, given that config files are trivial to move around. Yes, I have a possibly excessive number of dotfiles, but they work fine on everything from Arch Linux to Termux on Android to OpenBSD and are just a clone away.
That, plus they often break other functionality. Using a Vim plugin with Eclipse made using the refactoring functionality a lot more fiddly, IIRC.
If you use mainly statically typed languages where IDE static analysis, refactor tools proves super useful to you... keep using that set up.
I don't really see the appeal personally.
I think this for me is the gist of the problem... A lot of corporations prefer these large monolithic codebases, with a thousand different interfaces and abstract classes.
I think this is a mistake in design, and prefer simple applications with simple interfaces. They are easy to maintain, and are more reliable as their are less moving pieces.
I'd rather write a small app/service in python, c, JavaScript than work in some horrifically gargantuan and abstract Java code base.
This is a problem with enterprise in general, they'd rather incur technical debt to stuff in new features into legacy monoliths, instead of designing small applications and services with simple interfaces.
A classic example is defining your services in interfaces with a separate class for the actual implementation. This means that even for services that will only be implemented once, you now have the class and an interface. But with an IDE (and since the mappings are clearly defined, I'm sure this wouldn't be a monumental task without a GUI), you write the interface, create a class to implement the interface, and the IDE generates your methods. That's minimal overhead for an IDE, but it require a bit of work on your part to manage in something like vim or emacs.
It really depends on how much resources your company has, what you're trying to do/prove/show, and how long you have to do it. Google gets idolized for their software, but the reason they can have so much perfection in their software is the amount of money their core business throws off, not the other way around.
Why stop there? Most terminal editors are bloatware!
"When I use an editor, I don't want eight extra KILOBYTES of worthless help screens and cursor positioning code! I just want an EDitor!! Not a 'viitor'. Not a 'emacsitor'. Those aren't even WORDS!!!!"[0]
GUI and terminals both have their place. There is no single combination of software that perfectly covers everyone's use cases. By all means, share details about the environment that works best for you, but blanket statements like that just create controversy.
Besides, modern terminals are really just GUIs designed to use the keyboard as the only peripheral. You don't necessarily need a REPL interface to support that use case.
Tabs - That's the way god intended it. Stop trying to force your indentation width on me.
Stable working directory - This is how every text editor I'm aware of works. I can see use cases where you might want to change it manually or automatically, but I don't want to have to guess which directory I'm in every time I open a file.
Even some seeming no brainers like turning syntax highlighting on can be terrible because it doesn't work well with dark backgrounds or other random colour schemes.
vim module/code.cpp
:make
Especially since I have my vim configuration and other dotfiles in Git. Just git clone and I am done.
Off course that is too much when I am only using a machine temporarily (like servers over ssh), but I can be productive with the default as well. It is just that with my configured vim I am more productive.
:help netrwIn my own case, emacs is running in a GUI frame most of the time, but I often use terminal-displayed frames as well.
Fun trick: if you run your terminal in 256 colors, the resulting terminal frame is nigh-indistinguishable from GUI Emacs for like 95% of the tasks. This works amazing over SSH, and allows me to work on heavy applications with full productivity even on a bus, with el-cheapo netbook and a mobile connection.
(I really need to write a blog post about this.)
Emacs has a package for that.
https://www.youtube.com/watch?v=AIWZ_pbLYqQ
Yes, this was way better than punch-cards. But it was incremental and used completely arbitrary technology simply because it was available from somewhere else.
UI as a concept was poisoned by Windows and its shitty derivatives.
Like, there is no real reason you can't compose stuff when using GUIs. In fact, it should be easier than pipelining commands.
There is no real reason the keyboard should be crippled by working in a GUI. It should be easier to learn commands. (But have you noticed that we still don't have dedicated keys for cut, copy, pate, undo and redo? The most common operations present in almost all applications. But we have a Windows key and caps lock.)
Despite what people think, UI is still mostly unexplored territory with tons of potential for improvement.
BTW, my favorite code editor isn't an IDE. It's LINQPad, because it gives me immediate feedback without much noise. Going from it back to REPLs feels like a downgrade.
This might not seem like a big deal for some. But there are two important points to consider:
1. A lot of inexperienced user still go to mouse menu for copy-paste. This is horrible, but kind of natural, since a lot of UIs don't teach shortcuts.
2. Cut/Copy/Paste/Undo/Redo should be treated as fundamental building blocks of user interaction, not some "shortcut" that happens to do a thing. They aren't even UI-specific. You can do all of them in a command line app (although the semantics would much poorer).
When I saw the demo of Xerox Star on YouTube I was both enlightened and depressed by the current state of things. Most people have no idea that icons were supposed to be objects and that interacting with them was supposed to be a way to send and direct messages to and between them.
I wish GUIs would learn from that, but I don't think there's any GUI framework attempting this, besides maybe CLIM (Common Lisp Interface Manager, see[0], and that's not because of being inspired by Emacs, but because of shared historical roots of Lisp philosophy.)
--
I'm currently poking around Smalltalk, which has both GUI and ability to fully customize everything.
>I wish GUIs would learn from that, but I don't think there's any GUI framework attempting this
The very first real GUI (in Xerox Alto) did all that and it was developed several years before Emacs.
Yup, and it all went to dumpster bin of history after mainstream GUIs and then the Web took off.
I also love that I can git clone my dotfiles + an install script and I have my full dev environment on any machine in 2 minutes.
(Interop is straightforward: just save from the IDE, operate on the file from the command line, then reload.)
This probably won't be to all tastes, but I've been happy working like this for years.
I started using your solution out of necessity, but with a little bit of context switching muscle memory found it to actually be a wonderful way to code.
I'm from emacs land, and so generally using terminal over the emacs+GTK has a lot of limitations (ex: can't display or embed images, no drag and drop, copy and paste usually integrates better with the rest of the applications you are using when selecting regions of textual data). On top of that emacs comes with tiling for free where normally you would have to tmux+vim.
Vim 8 also has asynchronous tasks, as well as a builtin terminal emulator. So there is not much of a reason to use Neovim (except Lua scripts, maybe?).
Sometimes a little bit of competition is very well perceived.
Others will probably chime in with the technical merits of neovim but for me, this reason alone is good enough.
Vim has allowed scripting via Lua since before Neovim existed.
Here's the litmus test for whether a program truly belongs there: Would it shit the bed if its stdout was a printer?
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 better if it had a GUI (one more extensive than gVim); that's exactly why SublimeText, Atom, Visual Studio Code, etc. are all so popular. They're vim (they all have vim key extensions), but with the GUI that makes them easier to learn and use. No, they don't have a perfect analog for that one super obscure feature that only you ever use even though you tell other people how great it is all the time, but that's because they're newer programs with fewer features, not because they have a worse interface.
Even programs like top really work better as a GUI. Being able to sort and scroll the list easily, or get contextual information from a process with the mouse is better. Top is good, but it's limited, and not a substitute for a more complete process monitor.
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.
Some jobs are interactive. TUIs ain't bad for those.
It doesn't seem like anyone has tried to build anything like that before. Most recent seems to be Rob Pike's sam from the 1980s, which (at one time in the 2000s at least) was the professed favored programming tool by Brian Kernighan and Bjarne Stroustrup.
Exactly. A printer is an inappropriate output interface for an interactive job, it's not the input interface that's at fault.
So, what benefit do applications like emacs or vim (which are, fundamentally, keyboard-driven GUI applications, even if they're running in text-mode) gain by being stuck in a terminal? It's a simple least-common-denominator that's easy to push over a slow SSH connection, but why wouldn't I want to relax some of those limitations when I'm working locally?
Simple least-common-denominator SSH-style workflow is actually a feature for devops/sysadmins, so that's why I believe you'll find a disproportionate amount of them favouring vim. In Emacs, you can relax limitations of a terminal, while benefiting from its text-based design that enables heavy interoperability and ergonomic workflow (and then you discover that terminal Emacs retains 95% of those features anyway, so you can get them over SSH too).
I kinda wish we'd move beyond the GUI/text dichotomy. I wish we had something more like the Listener on Symbolics Lisp Machines, which could show rich text and images, forms, clickable elements etc from within a console environment.
I guess there is Linux's make config, but make menuconfig seemed so much faster. Basically, text adventures for doing productive tasks, doesn't sound very productive to me, but I'd love to be wrong.
I use plenty of interactive tools in a terminal, but almost all of them are screen oriented, very few are line oriented.
I would say the distinguishing thing to make something usable on a printer / a real teletype is that the paper only moves in one direction.
we should have a curated litmus list.. listmus.com
(besides, I have noticed a tendency in myself that is basically 'yak shaving for vim': the more plugins you have, the more you have to work on their configuration in order to make sure that they all work as expected...while this _feels_ very productive, it is actually the opposite of productivity)
Regarding IDEs and bloatware: here’s a more detailed explanation of that argument
https://lucasfcosta.com/2018/08/05/In-Praise-of-Plaintext.ht...
They’re not always bloatware, they have meaningful use cases, I just don’t think most of them are in the domain of software engineering specifically.
I’ll take some time to go through comments in more detail at another time and address them in the post if they’re relevant to the context.
Thanks again for all the amazing feedback.
Of course there are some things for which Gimp/Photoshop is really necessary, but it turns out that there is a massive amount of image manipulation that is better done on the command line than within Photoshop. The people who were dependent on Photoshop would take endless hours completing the same tasks which can be done in seconds using the command line.
I'd be interested to hear of any other stories from developers that use both terminal for almost everything but also have to have a web browser open for development.
The best I do is have my browser and my terminal open 50/50 on one screen, but this isn't ideal, just a compromise.
In an IDE, I'm done before you can decide whether it's "worth it".
The terminal is my IDE I can open a file with a couple of keystrokes, run bash scripts from inside of my editor and just as easily be back navigating the terminal.
Maybe I'm missing something, but I don't see how intellij improves any of this stuff. I'd rather memorize compose-able bash commands, than intellij keystrokes.
Which for most developers in a corporate or small business environment is 100% worth it. Not ever corporate developer has a nice enough computer to run an IDE, but I bet that at least 95% do.
https://github.com/neoclide/coc.nvim
It uses Language Server Protocol and goes quite deep pulling completions, and can, eg, render function documentation into floating windows (not yet merged into neovim)
Sure, is really usefull to learn the ropes when work from terminal, because sometimes you will need to remote into a server.
Or even, as happened before, people will give me a shit machine to work from. I was prograing in C/C++ in payment terminals (you know, credit card machines), and they give me an old dell with only 4gb to work with.
The default environment was in Eclipse IDE, that usually fell bloated, and was even worst in this pc. So I just installed vim, make a fell changes in the .vimrc and I was read to go.
I fell things: I don`t really care about the whole h,j,k,l on vim. I see no problemas in using the arrow keys. Maybe this was a problem like 20 years ago, but now keyboards pretty much will always have the arrows, and they will work just fine. If you use a keyboard with the arrow keys, I really think you like to complicate things. Sorry, nothing personal.
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 to solve problems in new ways.
Things that might require writing a custom VSCode plugin where you simply default to "fuck that" become chaining together 5 Unix commands and setting up a Vim key bind to solve the problem in 15 minutes to do something that will benefit the next 5 years of editing code or whatever you're writing.
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.
But what if those terminal commands need to interact with your editor?
How would you set up a simple VSCode key bind to take the currently selected text, run a shell script using the selected text as input and then replace your selected text with the output of the shell script?
With Vim, this kind of mentality is baked into how you work with the editor. Even as someone who is very new to Vim (about a month) it only took a minute of Googling to figure it out.
After having used Sublime Text for about half a decade, followed by VSCode for a year I never even thought to do something like that either. I just took the easy way out of thinking "yeah I'm not going to make a custom plugin for this, I'll just settle for some worse implementation that someone else wrote that does 75% of what I want". But just weeks after using Vim, I'm finding myself adding all of these little customizations that are specific to things I do every day. It feels like my editor is working for me, not the other way around.
> I can chain 5 unix commands together and use my IDE to navigate through code with my mouse
I use the mouse in terminal Vim too. I don't really care about what purists have to say. For certain things I find using the mouse easier, so I use it.
Yes, there is a plugin to VSCode to do exactly that. But it doesn't matter. Different software has different features and all features are possible depending on what you care about. Vim is Vim. Vim doesn't have features because of some GUI vs. command line distinction -- it just has different features because it's a different product. Nothing stops a GUI IDE like VSCode from having those same features. And nothing stops you from using GUI windows and mouse in a desktop version of Vim.
Which plugin does that? Link?
But I currently select portions of text with a mouse by highlighting it, and then execute programs that accept that selection as input.
I no longer am limited to entire text that would be written to StdOut or piped or redirected and so could be treated as complete text files.
I can currently select and execute programs in a GUI in just 2 steps, using a mouse.
Admittedly, I integrated the <program to execute> into the GUI, but it was relatively simple.
To do this in Linux it looks like I would need to run a port of Plan9's Acme or the Wily editor.
The port of Plan9 is way more than I need, so I will look at Wily.
Maybe there are some other Linux editors that will do what my GUI currently does?
But it looks like this just replaces the selected text so it may be more for formatting.
I prefer a new window to open so the selected text isn't altered.
I know I can program vEdit+ to do this, but that is not Linux.
Besides that, I'm looking forward to see when xi-editor [1] finally becomes a stable alternative to VS Code among others.
I know about 3 Python TUI libraries available to the date: urwid, npyscreen and picotui (the first 2 using curses and the 3-rd one not using it), neither of them is anything nearly as good as any of the GUI framework I've ever tried.
What I consider the best UI frameworks I've ever tried are WPF, WinForms, JavaFX and Swing - if there was something nearly as convenient to use in Python (or any other reasonably high level language, e.g. I don't mind JVM, Common Lisp or Ruby) but rendering itself via curses I would hardly ever use GUI as there would hardly be many valid reasons to besides watching/editing pictures and videos.
Perhaps if there were a good text-mode web browser featuring full support of modern JavaScript (which I believe is not really much work to implement for a person with experience in the area as they wouldn't have to code the entire JavaScript engine from scratch, all it probably takes is to attach V8 engine libraries properly and/or implement the entire browser on Node, the problem is this hardly has market value) we could use React, Angular or something. Many of the console-dwelling hackers will probably consider this kind of thinking profanity yet it's a fact most of the people (including those who could prefer TUIs) don't have time to debug C code and implement low-level stuff.
I came across WTF but don't know Go or see any documentation about building custom modules.
So I tend to use IDE with good support for Vim key bindings.
So VSCode these days and waiting for a good neo vim based IDE.
How, reasonably, can all these tools beat a thing like Visual Studio? Must limit job opportinities too...?
Respectfully disagree. They've bloated up over time, and lost information density due to trends emphasizing lots of whitespace and hiding options. I liked my GUIs from 10 years ago better, thank you.
> If someone insists on using a CLI and nothing else, after all these years of the world having moved to GUIs, I wonder what prejudice is behind it.
It's not prejudice, it's pragmatism. CLI and vim/Emacs tend to have much higher productivity ceilings (i.e. there is something to master, and that mastery brings rewards). They compose better too, so you can solve more problems without starting to desperately bend the problem into the shape of your tool. They're also lighter, faster, enable easy automation (which is the whole point of this job), and can be used remotely.
> How, reasonably, can all these tools beat a thing like Visual Studio?
Because IDEs can be seen as one particular arrangement of those tools. It tends to cover the most common use cases, but you cannot really step outside it. Whereas "all these tools" used directly can be arranged in different ways, solving more problems.
> Must limit job opportinities too...?
No, it doesn't. With IDEs there's little to no expectation of "proficiency" there - after all, the GUI is there so that you don't have to know your tool.
The world is a big place and there are a variety of programs being written in a number of languages. Not all of them need a GUI. Oh and they don't have to beat Visual Studio. They just need to be the right tool for the job.
Package installation lies right in the middle for me. If I know exactly what I want sudo apt-get install is the quickest and easiest. If I am not sure exactly what I want its easier to browse around using synaptic.
I can do more complex greps on the command line than most GUI tools will allow me to use.
If I'm actually wanting to install a game of some type, but don't know what I want to try out, then I'll load up synaptic.
No prejudice.. I run a dev/comms box on a Raspberry Pi Zero W that has 512Mb of RAM. I originally set it up with a lightweight GUI which would actually start up but was pointless to try and use for anything. Reverting back to CLI meant that I could now "do stuff", and I rarely use more than 70Mb memory even with tmux running.
I personally use it a lot but this arguments have been going on over (and over)+ again. And it won't be the last time :-)
.
And you don't lose time from whatever you do before and after, by taking your fingers off the keyboard.
As far as what is considered to be hard, it depends on the individual.
For many of us that spend a great deal of time on the command line, many multi-step activities, including those related to file manipulation, become like a single action. Consider the difference between touch typing and hunting and pecking. To an experienced secretary, the phrase "to whom it may concern" can become a single action, executed by the fingers without any thought whatsoever, while for an inexperienced typist that's 20 individual actions. Similarly, a whole series of file manipulations, git actions, SSH actions, become hardwired into our muscle memory and we don't even think about the steps. We just decide that we're going to do something, and let our fingers take care of it. This is much easier and faster then manipulating a GUI with a mouse.
It is obvious that touch typing is faster than hunting and pecking for most people who:
- have 10 fingers
- have invested sufficient effort to learn touch typing
To demand sources for this is disingenuous.
Since when?
Editor speaking, I can navigate / open files / select faster with keyboard than it would take to move the hand to the mouse. Not move the mouse and click, just in time it takes to switch the right hand I can launch three of four keystrokes, and that's enough to complete arbitrary operation in vim or Emacs. By the time I'd complete that op by clicking, I could do a dozen more from keyboard. Mousing is that slow.
Terminal speaking, sure, typing even portions of file names + arcane flags may seem a bit slower than pointing and clicking. But then I can type: | some-other-command --flags, and good luck doing that with mouse in reasonable time. And then, satisfied with my result, I can go back to the initial command and shove a "*" somewhere, and now I'm in batch mode, and with one Enter press repeating the same operation on a dozen or thousands of files. At this point, pure-GUI user would have to get on the web to find specialized software...
1) Any command you can issue by clicking or scrolling on something, can also - in principle - be issued by pressing a key on a keyboard. Therefore, any automation you hide under a mouse-activated command doesn't matter, as it can be invoked by keyboard too, and faster.
2) The absolute upper bound on the simplest possible way of aiming at a single pixel of 4K UHD screen with just two keys is 23 key presses. 14 key presses if you're aiming at 16x16 squares (mouse rarely needs to aim better). 12 keypresses for arbitrary pixels with four keys (home row). 8 for 16x16 square with four keys. 5 presses with full set of English letters, for arbitrary pixels. That's an upper limit. It's slower than a mouse, but only by a little bit (within the same order of magnitude).
3) Generalizing this, the upper bound of keypresses you need to touch arbitrary element on the screen is given by log_n(number of elements), where n=how many keys you want to use. +1, if you need some sort of activation key before (to switch between typing and selecting). This quickly drops to 1-3 keys, and you can get even better if there's some structure to the expected workflow (see e.g. tab stops in any sane form in any UI that isn't suffering from acute JavaScriptitis yet).
4) 1-3 random keys are faster to press than clicking a random object on a screen. That you can time for yourself trivially.
Basically, unless you're dragging arbitrary pixels around, for almost[0] any task one could easily design a keyboard-driven UI that's faster. Those kinds of UIs are not omnipresent (with the exception of Windows-style "accelerators" and tab stops, which the web is doing its best to get rid of), but they show up. In fact, properly configured Vim and Emacs are full of these kinds of UIs for programming tasks (see e.g. [1]). Which is exactly why you keep seeing people telling you Vim/Emacs are more efficient to work in.
--
[0] - I'll make concession to visual arts here, but take a good look at Blender to see how far you can go with keyboard-driven efficiency improvements for 3D modeling.
[1] - https://github.com/easymotion/vim-easymotion; Emacs has stuff like this too, but this repo has better screenshots.
Not sure I fully understand 2-4 but the fundamentals still remain, i want to do a git pull i alt tab to my command line, already two presses, then i find my src directory, and pull. Or just right click on my IDE and click pull?
Or you're using Magit, in case of which it's "C-x g" to switch to magit from any buffer associated with project (a file, compilation output, whatever), and then "F p" to issue a pull from origin. Which is 4 key presses (6, counting CTRL and Shift), and likely in your muscle memory. Every other git command is accessible similarly.
Point being, for any mouse interface like this, you could - and in vim/Emacs, often do - have a similar, but more ergonomic keyboard interface. Points 2-4) were about showing that this applies to almost all software in general, not just to editing code.
ls ~
Subsequent refreshes are simply
C-p
Dragging over to that breadcrumb is tedious and time consuming, by comparison
I type about 105 per minute, 3% error rate.
If you can only type 10-15 words per minute, it's probable better to mouse most of the time.
So imho it's a bit clickbaity calling this setup (which had nothing new as far as I' m concernt) "still not using guis".
Maybe the dot files got something interesting...
Edit: Nope they didn't in fact hey are a joke a few alias, neovim, zsh and tmux (mac specific stuff like brew I didn't look at) one "useful" thing thought albeit not for me where the reference to xkcd 530 :)
to my knowledge right now no terminal emulator properly handles
* cjk- specially so called double width chars
* Indic- dependant vowels
* west asia- rtl
that's the entire breadth of Asia for you who cannot use terminals if hey want to write a letter in their own language.
$ printf "1234\n谢谢\n"
1234
谢谢