Hacker News new | past | comments | ask | show | jobs | submit login
How I'm still not using GUIs in 2019: A guide to the terminal (lucasfcosta.com)
225 points by lucasfcosta 23 days ago | hide | past | web | favorite | 239 comments



"Not every machine has VSCode, Sublime or Atom installed, but every machine has a terminal."

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.


"Some of which" is actually just one app from the list (iterm2). Iterm2 is just a terminal emulator, so I guess you can sed "s/iterm2/gnome-terminal/g". I must admit that none of these are common default apps.


IIUC, iTerm2 has uniquely good integration with tmux.

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.


I agree. I feel like that argument is better for a different subset of users. I got into terminal multiplexers when Tmux started getting traction. So I chose that after only using Screen briefly. Since then I've met a few old-schoolers who have used Screen for 20+ years who have asked me to pitch them on Tmux. Maybe I'm doing a poor job, but they already have configs they like and aren't really interested in the new features. Plus, Tmux is missing or not installed by default on older or more obscure distros. The only practical thing I could come up with was better support for vertical splits (the more sanely named and organized config wasn't relevant because they hadn't changed theirs in years). Similarly with NeoVim. I can usually get by with vi on those obscure systems since I'm usually reading a log or tweaking a config instead of editing source code.

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.


Using the terminal at least makes you proficient with the lowest common denominator of tools.

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.


Still though, the article feels overkill. I use VSCode for example and I'm still comfortable enough with a terminal to vi/vim, install/update, manipulate files, search, etc. Yet I'm not nearly as productive vim as I am with VSCode.

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"


> 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.

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.


I don't know, with SSH access to a machine, I would edit the remote file with Emacs on my local machine via Tramp or using SSHFS.


>Using the terminal at least makes you proficient with the lowest common denominator of tools.

Why even use a computer then? Aren't rocks and sticks an even lower common denominator?


> 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.

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.


Eh...it's not out of the box, but either busybox or termux will fix that in 30 seconds. The lowest common denominator is extremely portable.


What?

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.


Saying that you should learn the terminal because a machine may not have Atom or Sublime is sort of saying that an advantage of the terminal is that you don't have to install additional software, isn't it?


Nah, that sounds just like short for "I sometimes wear the devops hat" - that is, the author probably has to switch computers regularly. Productivity as a devops/sysadmin has different requirements than regular developer productivity. In the former case, you'd prefer standard terminal apps and default settings. In the latter, you'd customize the hell out of your CLI and editing experience.


Yes that's also key for network admins - ironically I found when doing my CCNA that my experience years ago on PDP's cli came in handy on ios (the Cisco os).


Yes. I wonder though, with proliferation of tools for automating server management, how much does this approach still matter?


Serious sysadmins /network admins only config kit via out of band terminal mode - that's what the AUX and Console ports are for on Cisco kit


Eh, that doesn't scale beyond a few devices. There's out-of-band management, yes, but often it's in the form of an isolated management network, which allows automation quite conveniently. Even the serial console is often accessible over a network using terminal servers. You usually also want to be able to download and archive your device configuration automatically using eg. oxidized.

That said, being able to work with standard tools is extremely relevant for debugging problems, still.


There is a difference between pre-installed only vs being allowed to install apps, and CLI vs GUI.

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.


I'm a game developer mainly writing/reading/debugging C++ on a codebase that's well over a million lines of code. As with most game-dev I'm developing almost entirely using Visual Studio, and I can't imagine trying to navigate code using a terminal based editor.

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.


On the other hand I have worked on code bases in the 50M lines of code that would bring VS on its knees; people ended up just using it as a glorified text editor.

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.


I have nearly the same setup you do but recently switched from ag to ripgrep (with deadgrep emacs plugin). It's a bit faster and allows filtering by files, etc. You may want to give a test


Thanks, I'll give e It a try!


I feel most people that have used a command line workflow that need a GUI for debugging GDB's TUI is generally adequate even with large debugging projects. It's not a perfect 1:1 to the magic that Visual Studio gives you, but it is useful even with very large projects. Then again people who are terminal oriented usually use/look for other styles of debugging compared to people who have a solid IDE where the debugger just has more leverage. There's plenty of projects where all you are going to get from the field is a coredump, so building other methods to triage problems is more important: for instance a reliable replay system to rerun a trapped issue in a test environment.

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.


The goal is not to stick to a particular style- it's to use the best tools for the job. why settle for gdb when there is VS Which is light years ahead. just like why use vscode when there is vim which is light speed faster?


I made no indication of 'settling for gdb,' you can use gdb in plenty of places where Visual Studio doesn't make any sense at all and provided some examples. If you haven't looked at the GDB TUI you might be surprised on how competent it is and having a well supported python interface to automate or enhance specific debugging for a project is pretty great. GDB hooking a runaway process in production that's using up a ton of resources is also much easier to do from shell than trying to coerce Visual Studio to do it.

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.


While I agree on the "pick the right tool for the job" part, your comment makes me suspect that you have not had a look at GDB for very long (or at all).

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 a game developer mainly writing/reading/debugging C++ on a codebase that's well over a million lines of code. As with most game-dev I'm developing almost entirely using Visual Studio, and I can't imagine trying to navigate code using a terminal based editor.

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.

[1] https://github.com/Andersbakken/rtags


Code visualisations I agree aren’t that useful, and if I never have to look at UML style diagrams it’ll be too soon.

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.


You certainly wouldn‘t have a node graph like this in vim, because like you are saying, it just doesn‘t work well with text.

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.


> Most of our parallelism is job based. There is a job queue and worker threads are taking jobs from it.

For a game or similar code that's sometimes too much RAM, and usually too much latency.


There is a really nice talk of the game developer Naughty Dog about their job system: https://www.gdcvault.com/play/1022186/Parallelizing-the-Naug...

Can you share your vim setup?


Regarding rtags? I am just using the plugin: https://github.com/lyuts/vim-rtags.


Learning a text editor plus ctags (etags) plus how to integrate your text editor to N compilers (syntastic) will make you equally proficient without fiddling with one IDE for each language.

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...


That's why I use VSCode. Not really terminal, but works on every language.


Some game devs prefer to use VS with an external editor (as shown by Casey Muratori and Jonathan Blow in their live streams).


I watched Casey's earlier streams. The only thing he likes VS for is the debugger. He would say he's looked and hasn't found anything better, but expressed a strong desire to find something else.

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.


For games, especially non-trivial ones, GUIs are fucking great. I couldn't possibly imagine writing game code without them.

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.


> 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.

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.


Slight tangent, but may be interesting.

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.


I was mentioning CSS because it's something that almost everyone here has experience with. I don't know anyone that doesn't use a GUI to tweak or experiment on things when they're broken. I use Chrome Dev tools, but there are many other GUIs out there. It's true that I still write the first pass in emacs, but the first pass isn't often enough.


For CSS i find a text editor and two browsers live showing the changes to be most efficient. I have one or more live real browsers even with a IDE environment.


What kind of navigation are you relying on that could not possibly work faster on a terminal?

Horrible ascii graphs look horrible, but they are arguably more functional in that you can navigate them with your keyboard.


This isn't Starcraft, very few developers are limited by their APM throughput through the UI.


>This isn't Starcraft, very few developers are limited by their APM throughput through the UI.

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.


> 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.


> 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.


Personally, I use pen and paper (and a whiteboard) almost exclusively to draw and jot down very short notes. I do plenty of longer outlining when designing too (much more than drawing), and that happens in my text editor (Emacs, Org Mode).


> 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

Some of us would say well-designed instead of simplified :-)


> 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...


C# has both semantic refactoring and REPL. It might look like Java, but it's a much better designed language. They are even fixing all the horrible crap that was dragging it down with .NET Core.


Navigation is rarely the limiting factor in development speed. I'd take better auto completion / integrated tools over faster navigation every day.


I hope that language servers fully take off. This way, Vim and Emacs can gain semantic autocomplete & navigation. To be clear: it's not that they can't have that in principle, it's just that engines for semantic operations are difficult and expensive to write, so they were made primarily by IDE companies - and until recently, it meant they were tied to those IDEs.

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.


I've never been a big debugger user, but I thought if you like LSP, you might be interested in Microsoft's analogous debugger protocol:

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.


Wow, thanks!

And it turns out, Emacs and vim do implement their own frontends for this - [0], [1]. My wish just literally came true!

[0] - https://github.com/emacs-lsp/dap-mode

[1] - https://github.com/puremourning/vimspector


Awesome - glad to be of assistance!


> Navigation is rarely the limiting factor in development speed

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.


> Quite often the biggest challenge to any given story is understanding the impact of a single line change on a code base.

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.


Code coverage is really high, legend has it that code coverage was tied to bonus a decade ago. The tests typically add more mental overhead than reduce it due to this.

> 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.


If anyone told you you can't navigate IDEs with a keyboard, they lied.


Visual Assist X is a VS plugin that everyone I know seems to have pre-installed wherever they work. It allows things like jump to file/symbol using a keyboard shortcut and fuzzy search. I imagine there's equivalent with vim, etc, but I also don't see how a terminal could be better/faster.

Most navigation is done using keyboard shortcuts, but I can use the mouse to click around menus if I forget where something is.


I'm in gamedev too, I basically do debugging for living with eventual actual development.

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.


> GUIs are bloatware.

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


It's common to think that the goal of UI design is always about being as intuitive as possible, to minimize potential learning curves until they're basically non-existent. I don't think that's the only worthy goal, though.

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 largely agree with your post, but disagree with the idea that intuitiveness and power are often opposing.

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).


You're correct, and the world would be much better place if UX design was conscious of that distinction. That said, I think GP was talking strictly about "intuitiveness for newbies" being opposed to power. Unfortunately, even modern developer tools are being designed as "intuitive for 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.


For me, intuitiveness is defined by how quickly a new user (i.e. a newbie) can start using something. You say,

> 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.


> 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.

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.


> 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'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.


Yes, the more your resist that urge, the faster that muscle memory will develop. It's even faster if you take a second to think of the most keyboard efficient way to do things with vi-keybindings and doing that, resisting the urge to use simpler keybindings. For example, `a` instead of `li`, or `A` instead of `lllllllllllla`.

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.


> Learning isn't hard, but building muscle memory is a tonne of work. It's like learning to touch type all over again.

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 :).


You'll get there. I'm at the point where my accidental nano sessions look like jkjkdd:q! because I can't remember how to exit it and I can't stand navigating an editor with arrow keys anymore.


> 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.

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 agree.

I used to use git only on command line but after switching to a GUI I find I'm way more productive.


I always find the benefits of portability to be a rather funny one: It's always immediately followed by 800 lines of dotfiles that do an incredible amount of customization.

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.


Just wait for the vim guy who will be like "but muh java plugins make it more efficient then IntelliJ"...

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...


> Sure if you have this insane VI/EMACS setup that you have tuned for years. Good for you, you probably are a fucking wiz.

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.


> 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.

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.


> Compare this to spamming down arrow 30 times and then right arrow 80 times to get to a character in your editor

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.


GP isn't talking (just) about jumping between files or function definition. The difference between Vim and regular IDEs is this: in Vim, you notice an arbitrary piece of code on your screen, tap tap, you're there, tap tap, you've transposed it with another piece of code somewhere else in the file, tap tap, you're in another file, tap tap, you're back in the previous file, except it now contains half of the code from that other file, tap tap, now with proper namespacing. All done at the speed of thought - an experienced Vim/Emacs user thinks in semantic steps, not shortcuts. In regular keyboard+mouse approach, you either do operations that perfectly align with automated refactoring capabilities, or just have to click a lot.


> Just wait for the vim guy who will be like "but muh java plugins make it more efficient then IntelliJ"...

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).


> I think i am more productive in an IDE, faster.

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).


Only a sith speaks in absolutes.

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.


Sure, there are definitely some folks who are excellent in those languages with Vim. But when you think about the amount of time that's required to make Vim comply, the amount of mental state that's required to manage the things that could have been taken care of by an IDE, I can't help but challenge the idea that there's nothing possibly better than tools.

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.


When comparing vim and intellij,

vim is a lot closer to the chisel, while intellij is closer to the chainsaw.


I think you're missing the point I'm making, they're different tools that serve different purposes:

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.


No, I believe I understood the point you're trying to make, but I disagree with it.

I've worked directly with several VIM devs on Enterprisey frameworks who were not held back by their lack of Intellij.


"Only a sith speaks in absolutes"

Do you recognize the irony in that statement?


OP must have been quoting the King James version, a more accurate translation would be:

"In general it's usually a Sith that speaks in absolutes."


I’ve recently started opening the large java project at work in emacs because I didn’t want to deal with how many resources IntelliJ uses when I start it up with a huge Java project.


Sure, but if you're a professional developer, the cost of buying extra RAM to compensate for that is recaptured within hours or days.

There is some deeper, irrational motivation in people who make this argument.


I have 64GB in my laptop... which might be taking it too far.


Or you could connect to IntelliJ from emacs.

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.



My approach is to just setup Emacs once and edit files remotely from my one setup of Emacs. I mostly use Emacs for remote editing, otherwise I use IDE's if resources are limited I go for VIM / Sublime Text. Whatever helps me to work quickly given a situation.


> I always find the benefits of portability to be a rather funny one: It's always immediately followed by 800 lines of dotfiles that do an incredible amount of customization.

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.


I tend to switch back and forth depending on what I'm doing. I haven't found a Java IDE that can match vim+fzf for speed of editing, and ctrl-n autocomplete is generally good enough. For debugging, refactoring or working with some API where better autocomplete saves looking at the docs constantly I'll switch to IntelliJ.


I launch emacs from intelli for text editing.


Or take the best of both worlds with VIM IntelliJ plugin :D.


I normally find that IDE Vim plugins are almost good enough, but not quite. They fall into a kind of uncanny valley where they'll support most of what you need, but that makes the bits that are missing more jarring.

That, plus they often break other functionality. Using a Vim plugin with Eclipse made using the refactoring functionality a lot more fiddly, IIRC.


You are using Java as a convincing argument for using an IDE... Java... ugh..

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 don't think the argument itself is Java. I think the argument is that heavy, corporate projects (typically written in Java or C#) can have lots of benefit from IDEs. This isn't to say that there aren't terminal utils that aren't powerful enough to handle such a project. But being able to Ctrl + Alt + LMB an interface and being taken to the implementation (or shown a list of all implementing classes) or pulling a graph of your DIs is damn delicious. It's those types of creature comforts that makes using an IDE worth it for me.


> "I don't think the argument itself is Java. I think the argument is that heavy, corporate projects (typically written in Java or C#) can have lots of benefit from IDEs."

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.


It's not inherently a problem, but I do think that there are certain measures that can be taken to reduce code bloat, stack size, and development time. Someone else already noted that large business software can be a bit complicated solely based on the business needs. Regulatory rules and the ability to audit certain actions in the financial industry tend to add a bit of complexity to business logic, and those are completely unavoidable by law. However, some of this stuff is good practice that comes with boilerplate.

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.


This has nothing to do with their core point. Yes, Java sucks. This doesn't prove that IDEs suck too. They make Java bearable. They can make editing simpler languages better as well.


I think you misread or I didn't convey my point well enough. I'm not against IDEs. I think they definitely have their place and are a great tool for development.


Managing large businesses is complex, and requires complex software. Spreading the complexity between various codebases does not make the software less complex. Large codebases in COBOL, Java and C# are what make the world go round.


I run a complex business. I can guarantee you that I would really prefer if it was a simple business with simple interfaces, dependencies and rules :)

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.


You seem to be under the impression that Java code bases are inherently "horrifically gargantuan and abstract". I would just like to say that is not the case - they are often like that, but they do not have to be. In my time, I have worked on many Java code bases that are small and simple, and not abstracted-to-hell.


> GUIs are bloatware.

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.

[0]: https://www.gnu.org/fun/jokes/ed-msg.html


For me, things like VIM where you first have to configure the hell out of it are a pain. Every time you're on some other machine, all your customization is gone. So after switching machines a bazillion times over the years, making the same little tweaks over and over, I've learned to deal with the default config. What I didn't expect: It made me a lot more productive in the long run.


This is why defaults matter. People sometimes downplay changes with "well, you can just tweak it if you don't like it", but in the long run tweaking the install every time is effort. Especially when you're working on non-internet connected machines. It's why I get annoyed when for example Ubuntu stops shipping the ability to burn DVDs on the install disk.


I think vanilla VI (basically just modal editing in general) empowers the user enough to make it worth knowing. I'm pretty damn proficient editing code in a project (that I know granted) with hundreds of files using standard VI when i ssh to a VM or AWS machine etc. Still more proficient than people using an IDE locally without VI modal editing :p


The default vim config is pretty weird: incremental search is off by default for some reason, I think it still defaults to using tabs for indentation, it doesn't change the working directory to the current file's.


Incremental Search - This can be incredibly slow on large files and/or network mounted files. It can also interact with line wrapping and highlight search to slow vim to a crawl. So I think it makes sense to leave it off.

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.


Change working directory seans like the most stupid idea i ever heard... That would make:

  vim module/code.cpp
  :make
Not use the build system on the top level...


Why would you have to tweak it every install? Isn't the whole point of separating the configuration from the application's data so that you can move it around?


Moving in a configuration is tweaking it. And then you're on a machine that is STIGed or is on a standalone network or you're helping someone do something on their account. The end result is you end up back in the default mode a lot so you might as well learn it.


Why not just take your configuration with you? I switched machines multiple times and each time it took me just a few minutes to migrate my vim configuration over to the new one.

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.


Vim seems like the wrong example. A lot of people use it with just the defaults. Emacs seems to be customized right away by more people.


With emacs, however, people tend to use tramp to edit files on a remote server as if they were local. So, there’s less need for actually using emacs on a server in the first place.


You can do the same with vim (in recent versions) out-of-the-box via netrw.

    :help netrw


Yeah, although my experience is that when I use vim, I generally ssh into the box and start vim there while when I use emacs, I use tramp.


I would say `git clone` is less painful than downloading and installing an IDE.


I absolutely agree. On the other hand, repeated fast forwarded rebased merges of issue branches that needs to be squashed might be viewed as more painful than installing Tower.


Title is a bit misleading. Not sure this is "I'm not using GUIs" but rather "I'm using a terminal-based dev environment". I was hoping to find some nice terminal-based tools for browsing and e-mail and all the other annoying real-life things I need to use


I use eww to browse simple web pages when programming, and notmuch-el to read my email. For git I use Magit, and for Slack I use emacs-slack. As you might imagine, that all runs within emacs rather than vim.

In my own case, emacs is running in a GUI frame most of the time, but I often use terminal-displayed frames as well.


> 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.)


> real-life things I need to use

Emacs has a package for that.


the web browser is the only thing for me that is not shell-based... maybe Firefox will come through and create an alternative.


What are the chances that teletype simulation is the best possible way to interact with computers? This is what command line emulates:

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.


"still don't have"? For many years we did. "no longer have" is more correct.

* http://xahlee.info/kbd/i/kb/sun_keyboard_left.jpg


You're right, I should have said "still don't have on PC". I believe Xerox Star also had all those keys and then some.

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 hope that the people who remember the OS/2 Workplace Shell have some idea. (-:


Visit the Emacs land. Embrace the joke that it's an operating system (truth be told, it's not really a joke). What you'll see is something combining the best features of CLI, TUI and GUI. A 2D canvas with various UI primitives, made of text. There's no separation - like in traditional GUIs - between what's accessible to user and programmer (the contents of editable fields) vs. what's just dumb pixels (everything else). If it's displayed, it can be used as an anchor for navigation. It can be copied or interacted with, either manually or by code. The depth of interoperability this enables is unseen in the GUI world.

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.)

--

[0] - https://common-lisp.net/project/mcclim/excite.html


> There's no separation - like in traditional GUIs - between what's accessible to user and programmer

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.


> 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.


Used Atom and other IDEs for 5 years. 3 years ago switched to vim + tmux and love it. I'm very productive with my setup and I can't imaging going back.

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.


You can always run a terminal alongside your IDE, you know! The IDE-type approach is generally very convenient, making your day go past that bit more smoothly, and the terminal is good for all sorts of things that are just a faff to do with a GUI.

(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.


Before Android Studio, I found eclipse to be a laggy, buggy, slow-moving mess, but still I relied on it heavily for a variety of functions.

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.


terminals unfortunately are a complete no-go for "all" Asian languages.

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.


With urxvt and hassle to install the correct font, it is doable to edit cjk using vim. Though it is less usable than using English, since you have to go back and forth to input cjk for input, and switch back to English for navigation and vim tricks. Some binding like f[some cjk work] becomes pointless since you are effectively typing f + (ctrl + shift) + (cjk word input) + (Ctrl + Space). You would rather use nano for extensive editing cjk. However, one or two words in cjk in some codebase is okay and not that bad.


Terminal.app on the mac appears to handle cjk characters as expected (both lines output are the same length):

    $ printf "1234\n谢谢\n"
    1234
    谢谢


I kind of wish this article was deeper on what benefits the OP was seeing from the plugins or what have you. I just was left hoping for something more from something that claimed to be a 'guide to the terminal' which usually is much more in depth to a particular workflow and you can usually glean one or two things you can add for yourself.

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.


I generally agree with Lucas' sentiments re GUIs and in his other article "In Praise of Plain Text."

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?


Answering my own question, Geany has "Sending text through custom commands" and ability to add custom commands via "Send Selection to->Set Custom Commands"

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.


You need to look at TUIs (Text User Interfaces).

> To avoid the annoying seconds in which vIM would freeze during tasks like syntax-checks, neovim lets you run jobs asynchronously.

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?).


Without neovim, there would probably still be no asynchronous tasks in vim.

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.


"there is not much of a reason to use Neovim (except Lua scripts, maybe?)"

Vim has allowed scripting via Lua since before Neovim existed.


It's faster, which I discovered after switching to it for Javascript/Typescript development. Also has better autocomplete plugins. Vim plugins just don't seem to have taken advantage of the async features yet.


Most of the nvim autocomplete plugins work on vim too.


Not for TypeScript, and not as fast (in my experience).


I like command-lines. I don't like TUIs.

Here's the litmus test for whether a program truly belongs there: Would it shit the bed if its stdout was a printer?


I was going to disagree with you, but after thinking about it I don't think I do.

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.


You are missing the point. How do you integrate existing programs into a new program using GUIs? Terminals and text are great for that.


top would be good to have as a GUI, but I think 99% of people would prefer not to have X11 running on their servers, not least because of how insecure it is.

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.


So you edit with ed? :). Also anything wrapped inside tmux would definitely defecate if hooked up to printer.

Some jobs are interactive. TUIs ain't bad for those.


That got to me brainstorming what someone might do if they were trying to write a modern line editor, targeting developers writing in... maybe not Java, but perhaps Go.

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.


I have an intuition that any line editor would find its limits quite fast for most existing code. (After having used ed a bit on regular files I came across, it's often both surprisingly useful and surprisingly obtuse compared with Vim.) Now, maybe a semantic structured language would find an amazing CLI editor. I'm vaguely thinking something like a lisp, or something with tagged structures. I guess the goal would be repurposing Vim's text objects to generic programming structures. That's as much as I can muster right now!


> Some jobs are interactive. TUIs ain't bad for those.

Exactly. A printer is an inappropriate output interface for an interactive job, it's not the input interface that's at fault.


If it "defecates if hooked up to a printer", it's not going to be useful in a Unix-style text pipeline, either.

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?


Vim benefits from being in a terminal because you can use things like tmux to improve its workflow. Terminal Emacs can be used like this too, but Emacs can also handle this by itself - its philosophy is actually the opposite. Emacs will consume the stuff you're doing in terminal, but in a much deeper way than other GUI editors/IDEs.

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).


The Amiga was like that. It didn't physically have a text mode, so there was no point to TUIs. The console (a GUI app that displayed text) was primarily command based. Anything screen oriented (even the first version of Vim) was a GUI app.

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.


Do people write programs that work like that anymore?

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.


TUI text editors, debuggers, pagers, music players are still very much used, if maybe not very actively developed. I guess even style escape codes would break line printers? This would discard a vast amount of tools I personally use daily. I would be happy to receive UNIX-philosophy arguments, but until such tools that bring the same functionality appear, TUIs are often the best of all worlds for me.


Most of the debuggers I use would be fine with a line printer, at the level of sophistication I'm capable of using them. A pager would be ok, as long as you're using more and not less.

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.


reminds me my litmus test for website design: elinks

we should have a curated litmus list.. listmus.com


an elinks lover here! It is an amazing web browser.


One of the most important take-aways of this article: you do not need tons of plugins! I see this very often in motivated and bright developers who want to start using `vim`. They copy a humongous config file, install tons of plugins, and suddenly, something breaks or does not work as expected. In my opinion, it is much better to start from scratch.

(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)


Hello everyone, thanks for all your feedback!

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.


This is why I'm creating a command-line alternative to Photoshop.


I once worked as part of a team which had graphics people who were allergic to the command line.

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.


some crazy image-magick fu here.


I love using nvim as my daily editor, but one thing I get from posts like this are that the authors rarely have to develop any kind of UI themselves, this author states they work in JS, but it looks like it's backend node work.

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.


I'm one of the few people who agree with you. I'll bet I can do most things in vim faster than intellicode or whatever the new hotness is.


Rename a class in Java. This includes renaming the files (including git mv) and fixing up all references to it (not simple text-matching - actual parsed declarations).

In an IDE, I'm done before you can decide whether it's "worth it".


Java in intellij+ideavim is much faster than in (n)vim, and that comes from someone who has been using vim for nearly a decade. Intellij is just too good.


Been using Vim for about the same length of time... And the times I have used those emulators they just haven't been the same. Does the emulator support VimScript? Macros? Plugins? async jobs like vim8?

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.


What IntelliJ gives you is code generation and automatic refactoring to make writing Java less tedious. That being said, the tradeoff is increased resource usage.


> That being said, the tradeoff is increased resource usage.

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.


(Just in case I didn't make myself very clear: I'm talking about Java; any other language is another story, and for that I use tmux+vim) It's true that there are a lot of small things that slowly add up that make the experience less positive (especially if you have used it for a long time), and I often have vim opened in the background precisely because certain things are easier in vim (ideaVim does have macros, although I haven't used them enough to really say how good they are). Ultimately, I've realized that I miss Intellij more when I go from Intellij to vim than the opposite.


For people using neovim, I've been impressed by this completion engine:

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)


Personally I reall like VScode debugger, and pretty much centered my workflow around it.

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.


I think the biggest win for primarily using a terminal based environment isn't because Vim or other terminal editors lets you write or edit code that much faster.

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.


Of course, you can bind terminal commands to keys in VSCode (or virtually any other environment) just as easily.

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.


> Of course, you can bind terminal commands to keys in VSCode (or virtually any other environment) just as easily.

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.


This is what I mean about straw men and mythical divides.

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.


> Yes, there is a plugin to VSCode to do exactly that.

Which plugin does that? Link?



This dead argument seems to re-animate itself once a year or so. But my question is this: Why not learn both the IDE of your choice and how to use your terminal/vim? No need to arbitrarily limit your own knowledge and abilities. It just makes you stronger.


The good development environments now-adays allow you to do everything from the keyboard and not click on anything. PyCharm being a good example.


I want to give vim or emacs a real shot someday. I only really know the basic stuff and am fine with it. But I feel like I really need very good integration with the programming languages I work with like Go and Python.

Besides that, I'm looking forward to see when xi-editor [1] finally becomes a stable alternative to VS Code among others.

[1]: https://github.com/xi-editor/xi-editor


I bloody wish there were a really good TUI toolkit for Python, something like Visual Basic for DOS but with a bigger selection of more advanced widgets.



What about ncurses?


As far as I know it neither does window management nor provides widgets (perhaps it can as Wikipedia says it's "added the form and menu libraries written by Juergen Pfeifer" in 1.8.8 (M1995) yet there is not a single example doing this with curses in Python), it just makes it slightly easier to build your own TUI toolkit on top of it rather than without it.

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.


Narcissism of small differences. Pointless blogspam. Also, Neovim is much closer to visual studio than it is to something like nano or whatever.


Not specifically related to the article but related to the theme of the article. I have a web-based dashboard that I created using a ruby gem called Dashing that was created by Shopify but since discontinued. I'd like to use a terminal based dashboard instead. Any suggestions?

I came across WTF but don't know Go or see any documentation about building custom modules.


I am sure the author is a power user of his tools. I tried to use Vim for more than a simple text editor for few days. I realised that it would very hard to replicate the productivity of a special purpose IDE(IntelliJ in my case) using Vim. tmux is great but if you are used to multiple windows or tabs that is fine as well.


After years of using Vim I gave up on the idea of using it as an IDE. It's really powerful for editing (navigation, searching, etc) but I am too dumb to do any debugging with it (xdebug, gdb, etc.). Too many panes, not enough memory slots for shortcuts.

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.


The world moved from CLIs to GUIs. Guis have not only persisted, they've improved. 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.

How, reasonably, can all these tools beat a thing like Visual Studio? Must limit job opportinities too...?


> Guis have not only persisted, they've improved.

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 moved from CLIs to GUIs. Guis have not only persisted, they've improved. 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.

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.


Some tasks are better suited to the command line. Others are better in the terminal.

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.


I tend to use apt-cache search a lot if I know generally what I want but don't know the exact package name. It lets you use regular expressions when searching and you can restrict it to just the package names by giving it the --names-only switch.

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.


> 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.

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.


That's nothing, I do BASIC on a Commodore 64. 70mb of RAM -- pssah! The average developer workstation probably has 32GB of RAM, a fast SSD, and huge monitors but 64k is all you really need.


Bah, my 1KB Timex Sinclair 1000 has labels on its "keyboard" with every BASIC keyword. I don't even have to type the whole word. Productivity!


I mean .. use whatever you feel comfortable with, make sure you understand what you're doing, the terminal is the closest interface to the OS.

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 :-)

.


I got the feeling that articles like that are multiplying? And many of them are using a Mac. Up until now I haven't seen anyone having a good setup with text-browser, office-suite (not ide I mean libreoffi e for the tty), image viewer (and I know there are quiet a few), pdf viewer,...

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 :)


Even your terminal emulator is a GUI app itself. Don't say you are not using GUI app unless you boot to a command line interface directly.


I'm not being funny but why do people prefer writing out lines of command line text versus right click and select in two clicks?


For many people, writing out the command text is faster. Fantastically faster, when you take advantage of the efficiency improvements like tab completion, readline hotkeys, aliases, scripts, etc.

And you don't lose time from whatever you do before and after, by taking your fingers off the keyboard.


With wireless mice you can move your hand nearer than they keyboard and even with tab completion navigation between files is hard compared to just a couple of clicks?


No no, the problem isn't reaching across the desktop. The problem is literally taking your fingers off of home row. It's fine if you're in a phase of your activity where you're moving slowly, contemplatively. But if there's a series of tasks that we want to accomplish and we already know what they are, lifting your fingers off of home row will slow us down! Wireless vs wired mice have nothing to do with this.

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.


I would like to see data on this, any studies done?


A healthy skeptic doesn't demand data for claims like "touch typing is faster than hunt-and-peck".


A healthy skeptic? Lol what? Anyone who feels they have a point should be able to back it up with sources or data


No. Reality is not established by publication. You can, and should, observe some things for yourself.

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.


I can observe the sun is hot, but doesn't mean I can tell what temperature it is. I think without data of timings across different applications and uses, it's hard to prove either side. I am open to both sides having the possibility of being quicker


> and even with tab completion navigation between files is hard compared to just a couple of clicks?

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...


I would like to see data on this, any studies done?


You need studies for something you can trivially test for yourself with a stopwatch?


One use case does not prove this is true, it might be for one person for a particular task (say using Eclipse or Vs Code or Linux etc) but not for all in general across multiple applications.


Let me sketch you something of a theoretical proof here, then.

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.


For your point in 1) that won't apply on any kind of navigation. I have to ls -l / dir multiple times to view whats in my folder and go back up with various key presses, versus just hitting the breadcrumb in windows explorer.

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?


> 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.


If I want a refreshed list of my homedir, the first time is simply

ls ~

Subsequent refreshes are simply

C-p

Dragging over to that breadcrumb is tedious and time consuming, by comparison


Blender is an amazing example. I was daunted by the thought of learning the rich set of hotkeys until I saw it compared to vim. Learning vim or emacs is well worth the effort, inspiring confidence that blender is as well.


Of course this isn't true for everyone. For example, some people don't have any fingers.

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.


Take a look at fish shell if you are in the terminal. It can almost read your mind.


What's with capitalizing it vIM? Website, man page, :help, none of those have it capitalized that way.


Weird, right? You'd think it was a typo, but it was a very consistent typo. Maybe they did it lowercase, then they `s/vim/vIM/`, hitting CapsLock and Shift at the same time when they wrote that.


Yeah, there was that and "LUA". Some people just have their own ideas about capitalization, I guess?


Dah, What's the point?


[flagged]


That's basically a content-free insult.


> That's basically a content-free insult.

Agreed. Totally not necessary. Possibly a result of carelessness as opposed to malice :-)




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: