Hacker News Reader

Visual Studio (not the Code version, though some will include that as well) is arguably once of the best IDEs ever created, so you are not wrong.

But often there are other issues. IntelliJ and its siblings can be very resource intensive -- many complain about the Clion launching your laptop fans, and its RAM usage, for example. And the UI of many IDEs has so much chrome everywhere, the UI often gets in the way for many. You can hide it and deal with it in some IDEs, but not all. There are just a lot of things to consider when selecting an IDE. For example, Emacs avy-jump is a really neat plugin (similar things for vim as well), but you'd have to work hard to configure an IDE for these kinds of features as well, so it goes both ways.

And btw -- Vim macros are perhaps one of the best text editing features ever created, and you can't find that so easy to use and powerful in any IDE.

And just the joy of actually editing text - which we do all day - arguably greater with the vim way of doing things. It just puts you in a certain zone.

I think this really depends on what you work on.

> Not to mention visual debuggers, not to mention remote debugging! The VS IntelliTrace feature alone is worth the cost of the entire IDE.

I use gdb and pudb, which are both CLI based, and have done so for years

> Visual Studio Live Share lets two people concurrently use the entire IDE at the same time, remotely: https://visualstudio.microsoft.com/services/live-share/

Tmux has let me do this for over 10 years

There are things I do not do in vim, but they are few. For example, I've developed a few Android applications as a side project and I used netbeans for it. For rust, go, c, python, I've always used vim.

> Tmux has let me do this for over 10 years

Of course, but is it as easy as two clicks in VSCode? There's so much setup to get it exactly the way you want in the terminal, where as it "just werkz" out of the box for VSCode. I'm a VIM user, but i use vim plugins inside of IDEs for this reason

> I know I'm going against the popular opinion here, but I have never observed anyone using either Vim or Emacs to outperform a competent IDE user, especially Visual Studio or IntelliJ.

> I mean sure, if you think IDEs are just slow, expensive text editors with fewer keyboard shortcuts, then you'll be disappointed, but features like "navigate to any symbol by prefix", "find all usages"

helm-projectile-ag (which I have bound to C-p s s) does this: C-p s s \bSYMBOL shows a list of all usages and enables me to navigate to any of them.

> "Ctrl-click to navigate to definition"

M-. does this in Emacs.

> Not to mention visual debuggers, not to mention remote debugging!

With SLIME I have a full remote REPL and debugger. And it runs in a GUI too …

> Visual Studio Live Share lets two people concurrently use the entire IDE at the same time, remotely

You could do this with multi-tty within Emacs, or with Screen or tmux, or with xpra. It would not be as ergonomic, I grant.

> There's just nothing like any of this in Vim or Emacs … I mean sure, if you futz around with plugins, you might be able to reproduce some small subset of these features, but then you'd have wasted more of your time tinkering with the editor than actually getting work done.

So, Emacs doesn’t have features it clearly has, but even if it does then somehow that is also bad? What is this, a game of ‘heads I win, tails you lose’?

Emacs looks like shit though, requires tons of time requiring to set it up and it still won't have the same insane functionality that Visual Studio does. Are you really trying to compare the two things? If you are then I would suggest it's because you haven't tried VS recently and realized the huge functionality it has...

I mean, does Emacs have a whole UI for handling unit tests which can be made to run automatically anytime code is changed? Does Emacs have contextual right click menus for almost any eventuality? Does Emacs have a visual browser for your code? Can you debug graphics pipelines (with previews of the output images) in Emacs? Does Emacs have built in code performance analysis tools? etc etc etc etc I could go on for ages here.

You try and compare Live Share with multi-tty? What a joke! Have you seen LiveShare and what it actually offers? Easy to use, amazing UI, you can see where the other person is clicking etc etc. The reason people use these tools is because they accessible, easy to use, and "just work."

This is the opposite of Emacs. Yes you can add "some" extra functionality by Frankensteining Emacs but it is about 1% of Visual Studio out of the box and convincing any of your co-workers to go through the pain of trying to emulate VS in Emacs is a fantasy, and then having to keep it updated and not broken... hahaha.

> they accessible, easy to use, and "just work."

..unless you happen to not be on Windows.

You're absolutely right that you pay a price for using Emacs, and that not having some awesome IDE features is part of that price.

Another part is having to look for and install the third-party modules that make it actually work well (most of them are not included in Emacs because of Stallman and the FSF being ideologues).

As you say, keeping it updated and not broken is yet another part of the price.

That said, it's clear from your comment that you have not given Emacs a serious try, at least not recently.

There's no reason you have to, but you probably shouldn't complain about it so vociferously if you haven't.

Right-click menus that cover most use cases (jump to def, find references, format code, etc) are absolutely a thing with lsp-mode (which is not too hard to set up itself - install it via the built-in package installation UI, install language servers, and tell emacs to use lsp-mode in programming languages).

There are unit testing modes that kick off tests automatically on changes and let you know if everything passed (or give you a list of failures when some tests didn't). I've not used those myself so I can't speak to their quality, but they definitely exist.

Further, these tools work for a wide array of languages, with the exact same interface for all of them (and an incredibly discoverable, extensible one).

Some of us like that a lot, as well as the comfort of having all the code to reproduce our setup directly to hand. I probably have several more decades in this game, so losing my environment to an IDE company going broke or getting bought is not a pleasant thought.

Tradeoffs, for sure, but with valid arguments for both sides.

My impression is that most people doesn't even bother to learn the editing part of the IDE properly, and use it mostly like Notepad. Visual Studio editor have ton of shortcuts for faster moving and selecting, Visual Studio Code is even better (vim plugin for most part just introduce modal editing and expose existing functionality), JetBrains IDEs are also full of text editing features. And yet, most people use only cursor keys, enter, backspace/delete and ctrl+x/c/v.

And another unpopular opinion: can we stop talking about hjkl cursor movement like the pinnacle of ergonomics? I get that people are used to that, but the only reason why that keys are chosen is because of that particular terminal used for making ed/vi. If moving the finger to reach movement left is so superior than anything else, default movement keys in games would be asdf, not wasd. hjkl is better than reaching for the arrow keys, but hardly ideal (I remapped arrows to caps lock + ijkl and to me it's way better)

Sorry but as someone that has done both C# in Visual Studio and embedded development in vim/gdb/UNIX, your claims do not hold up...

> have no comparable analogue in traditional text-focused, non-IDE editors.

The same features have been there in TUI editors for many, many years. There is nothing visual about the backend that handles those queries.

Whether the interface is easier to use or not is a different matter, but the features have been there for decades.

> Not to mention visual debuggers

Well, yes, visual debuggers are better with a GUI, that is obvious.

> not to mention remote debugging!

Remote debugging is very common. What you are thinking of is visual ones.

> However, objective tests show that even highly skilled users aren't as fast at completing high-level tasks as mouse-users.

Citation needed.

Blender, for instance, is praised by artists for its hard modeling productivity thanks to all the shortcuts.

A few years ago when I worked in VS, I used all kinds of shortcuts. It does not matter that the tool has a GUI or not to make the keyboard useful. It is orthogonal.

> took days or weeks to solve the same problem! Days!

That is just nonsense. There is no way one takes days/weeks to "debug" something that takes 30 minutes in another general purpose language.

Either the task could be trivially solved using the .NET standard library and not the others (which makes it incomparable), or they picked up participants with no clue in the other languages.

The debugger or the GUI/TUI distinctions have nothing to do with that. A visual debugger is most useful when dealing with very big code bases that you did not write yourself. For a programming puzzle that fits in 100 lines, a visual debugger is irrelevant unless you are new to programming.

Right, but coding is just one specific use of vim. Vim is a tool for a world where everything is a text file, eg:

- focused mode essay writing

- editing ~/.config/thing.json

- formatting a shopping list

- cleaning up scanned text from a PDF into markdown

- opening an encrypted password file and adding your home insurance renewal details

- writing up notes on a job contract

...and that’s just two hours into my day. Vim is general purpose. IDE usage isn’t mutually exclusive. When I need API aware typeaheads then I also reach for REPL.it.

Do you have links to these studies available? My experiences support your claims, but I'd be interested in getting my hands on some objective data.

It was some updated variant of this paper, which is quite dated (year 2000): https://www.researchgate.net/publication/2955345_An_Empirica...

Note some of the Java solutions were over 40 hours, and many are over 8 (one working day)

The version I saw was informal, and included F# and C#. I remember that F# was roughly twice as fast as C#.

I don't know F# but a friend of mine does, and we both solved the sample problem. He did it in under half an hour. It took me just over an hour, but I could have done it in about 45 minutes easily except that I had (embarrassingly) misread the problem statement and wasted a bit of time.

I used Visual Studio's debugger twice, and that did actually help a lot to get the problem solved quickly.

People who are really good at Vim and C remind me of someone who is really good at using a shovel. As impressive it is to watch them work, they can't compete with a backhoe.

I get the impression you're using a study comparing programming languages to back up a claim comparing text editors?

IDE + Vim plugin FTW!!! ;)

Experience with Visual Studio plugin and VSCode, both worked very good.

You can share Vim, Emacs, and your entire terminal with other engineers using Tmux or Screen.

You can remote debug with GDB.

You can navigate to any symbol by prefix in Vim using regex.

You can "find all usages" via :Ag whatever-you-are-looking-for.

Just because you don't know how to do it doesn't mean it cannot be done.

I'm a big user of vim and use the vim plugins in whatever IDE I'm using. But I have to say I don't find this sort of argument very compelling:

> You can share Vim, Emacs, and your entire terminal with other engineers using Tmux or Screen.

I've needed to do that maybe once. People aren't usually very proficient with tmux/screen anyway, and clearly even less with your flavor of emacs or your vim setup. VSCode live share does that too, but whoever you share with will have their own plugins (+ you can share servers, terminals, etc)

> You can navigate to any symbol by prefix in Vim using regex

Any IDE has navigation by symbol built-in, and it's usually faster than typing regexes

> You can "find all usages" via :Ag whatever-you-are-looking-for

Not true, :Ag will find occurrences not usages, it's not aware of the AST (that I know of). IDEs have specific language-aware functionalities like "find implementations", "find declarations", "find usages"...

---

I'm aware these were just example of course and I'm sure there's things that vim does better, but the only real value I got from vim compared to other editors is the text-editing model that's noticeably faster when you're proficient at it