I don't see why people are still using 1970s-era IDEs in 2023. Sure, it's a joke that emacs and vim users are at loggerheads, but name me one user of either who isn't a graybeard at this point. And specifically a graybeard who refuses to use more modern tools.
Long after you've migrated from your current favorite IDE twice over, we'll still be using emacs.
Long after whatever company sponsoring development of your current favorite IDE enshitifies them twice over, we'll still be using emacs.
Long after you relearn your IDE workflows twice over, we'll still be using emacs.
And emacs keeps evolving and can handle modern development just fine (except for the most garden-walled ones, and even then...), while not breaking our brains all the time with so many changes and migrations and trend changes.
We want to keep using our tools and get work done, not keep up with the Joneses.
> Yes, if you're talking about a timeframe of ~50 years, use vim and emacs.
There isn't any compromises that make vim or emacs less useful than those tools with much less longevity. They are just as good as an editor to even those who don't care if they will be around 50 years from now.
I used vim (and still using it for non-coding text editing today) but I just don't feel it's so powerful that it's comparable to IDEA. Of course it's probably because I haven't properly taken time to learn and configure it. I only know how to move cursor around, search/replace and enable syntax highlighting.
But that's the point: I don't want to take a significant amount of time to learn and configure an editor. I want a IDE that works well almost out of box.
Maybe my opinion will change if one day I decide to try a more batteries-included vim/emacs like Doom.
I once saw a guy coding Idris in his VIM, having VIM complete everything one could imagine and more. That thing completed whole functions based on signatures and types. And that was all years before the copilot and whatever came up. From then on I believed it, when someone said they could have IDE features in VIM.
I wouldn't have a counter to this normally. I prefer to heavily customize my editor without the support of a starter pack. But yes, starter packs like Doom Emacs and LunarVim do a great favor to these editors by enhancing their adoptibility for new users.
And you can expect during the next 12 years people will be asking why you use such an ancient piece of software, then you'll understand emacs users (if you don't already) :)
Because it's thought out and polished by decades of use.
Because it's extensible.
Your very question, "why are people using an IDE from 1970s in 2023" should provoke some thought. Assuming that these people are not crazy (a lot of them is rather smart and rational), what us so good about Emacs (or Vim) to make it still a preferred choice?
I'm not sure what you mean by graybeard, but I started developing software 5 years ago. Started using emacs 3 years ago (magit). Wrote my own 1000 line emacs config 1 year ago.
I am in my early 20s and started using Emacs when I was 18. The reason I use Emacs instead of a more "modern" tool is because nothing else comes close in terms of ease of extensibility.
I would be interested to hear if you know of any modern editors where extending my editor is as easy as writing one line and running "eval-buffer".
What should I imagine under term "extending"? Is that adding new extensions (like in vscode)? I never felt that this is something I often enough to need quickest possible way to do it.
Or do you mean more like changing how editor looks, how many windows/panes/tabs are displayed and where are they displayed?
So your editor works exactly the way you want it to? Just yesterday I made a tiny tweak to a package that I use (doom-modeline). I haven't thought about it enough to make a pull request, so that tweak now lives on my fork on GitHub. It took me all of five minutes to find out where to make the change, have the code open, and the change made, loaded into my running Emacs session and uploaded to GitHub. And bear in mind I'd never looked at the code for doom-modeline before.
Good tools change the way you work because they make certain workflows possible. If it was that easy for you to tweak your editor, you would too.
Literally changing the editor code, to do whatever you want. Emacs is a lisp (elisp) environment mostly with a small C based core for performance sensitive primitives. But the user code is at the same "level" as the Emacs core code.
This is very different from most extensible editors, where extensions are sandboxed and have a limited, controlled API to the core editor, which is kept separate.
This makes Emacs very "malleable", and it's likely easier than with most other tool to change it in custom, specific ways. It may seem dangerous, but it comes from a culture where this extensibility is very front and center, with documented design pattern to support it (hooks, customization settings...).
Ok, I should have said relatively, or even better "subjectively", small C source base.
The C base supports many platforms and variants, so only a part of it is used in a running Emacs instance. And to the 1+M lines of elisp one typically had many more extension packages. That's the the "relative".
In practice, when I want to change things I don't hit the C layer. Anytime I had to introspect Emacs to change something I was firmly in the lisp world. I don't remember having been limited by something being at the C level, which are things that cannot be changed dynamically. This is really what I meant: in practice to change Emacs the C level (although big in the absolute, and definitely complex) doesn't show up much and hasn't been a limitation at least to me.
I'm not a graybeard, I'm 28 and I've been using Emacs since I was 15. In that time, in my circle, I've seen notepad++, sublime, atom etc. all come and go. Of course everyone at work uses VS Code, in 2 years it will be New Editor by XYZ Corp.
Being old doesn't imply something is bad. Should we be asking what Emacs and Vim have done right so that they're still being used 50 years later?
I think you probably don't know emacs if you think no one should find it useful.
I highly recommend you give it a go. It may not become your main IDE, but I can guarantee that you'll find it very useful for a multitude of tasks, like a lighter text editor, quick REPL, RSS feed reader, binary file reader, org mode (like an organizer of tasks/notes/literal programming etc), magit (the amazing git client), grepping and navigating easily between search result files... and so many other things.
> I don't see why people are still using 1970s-era IDEs in 2023.
Because it works perfectly fine? So your reasoning is because is old is bad. That software that old still is being heavily used today is a testament that these tools have something that definitely the latest craze out there don't. And no, I'm not a greybeard, I'm in my 40's and been using VIM since I don't know when, probably more than 15 years for sure.
I'm not an old greybeard (in my 20s) and I solely use Emacs. What's "modern tools"? Emacs has everything; with the Language Server Protocol it is exactly like VS Code and the like, with autocomplete, find definitions, native tree-sitter support. It can even read PDFs, images, man/info pages, browse the web. I don't see any advantage that VS Code has over Emacs.
Been using Vim for a few months now but I was checking out eww the other day (along with learning more about emacs in general) and it’s certainly interesting…
I have never given emacs a fair shot, so I can't compare the two. Neovim makes it easier to get modern editor features like treesitter and lsp support integrated into the editor. The Lua api seems to have been very well received, so the plugin ecosystem for neovim is thriving. It has also attracted a lot of people outside of the original vim niche (including me!) recently, which means there are more plugin developers who care about how things look and feel to use.
There are certainly some constrains on what plugins can achieve due to nvim being exclusively a TUI, but in my opinion the pros of the editor outweigh the cons.
As to what makes me choose neovim over vscode with a vim plugin, it's a combination of things. One thing I love is that neovim is extremely easy to configure. I also enjoy that everything follows vim rules, rather than some things like file trees or consoles having their own unique rules. I have also become dependent on some vim plugins that don't exist in vscode.
Maybe for whatever work you do your IDE works better for you.
In my case, I mostly code in C++. I've tried JetBrains' IDEs and it drives me insane how slow they are to index and I often get freezes when working on really large codebases.
The same applies to Visual Studio (not vscode).
vscode drives me insane with the amount of dumb notifications it keeps popping up. But I can concede that for most people it works well enough. It also doesn't perform nearly as well as Sublime Text. Working on really large codebases is a PITA with vscode.
If I need autocomplete (which I actually don't like that much), LSP works well for my needs.
The availability of vim in some systems is not reliable. Often only either vi or nano is available. Containers may not have even that (not that it's a good practice to edit files inside containers. It's just for experiments). Emacs meanwhile, has tramp. It lets you edit files remotely and transparently - even inside Kubernetes pods. And you still get to use all your Emacs customization.
You say that, I remember when my team lead was managing a Solaris box and he asked me to take a look as Vim was not working correctly. So I moseyed over and turns out it was Vi instead of Vim. He got confused by c$ not deleting everything to the end of the line.
I would ssh into remote systems, start emacs as my first command, and do everything inside of that emacs window - editing (scripts, config files, code), running shell scripts and programs, reading man pages, executing make, compiling, etc.)
Others would use tramp mode, and open multiple remote sessions within a single emacs. This makes it easy to cut and paste between systems.
