Being able to drive an F1 car comes with excellent financial opportunities. Even if I'm not "on the grid" (i.e., actively competing in the GPs), I can be a test driver. Heck the license required to drive an F1 car opens other doors in itself (maybe in other motorsports, but also allegedly the range of vehicles you can drive).
In contrast, if I am proficient in emacs I am...proficient in emacs. I edit code in a manner that is visually impressive to maybe three persons in the CS department. I'd have an ever-so-slightly deeper connection to RMS than your average CRUD-slinger. I am out of advantages to enumerate and I'm trying very hard.
Maybe text editors are about as similar to cars as apples are to buildings.
Actually, vim is not a very good implementation of vi's principles.
Concerning Emacs, as a heavy user I think it needs 4 things to stay relatively popular. I don't think it will be ever super popular, and that's fine:
* Get popular workflows to work with zero configuration. Some packages like AuCTeX, Magit or Notmuch are great at this. But many programming modes require adding too much code to init.el (or .emacs), this code breaks often and it is poorly documented.
* There are too many half-finished packages for some tasks, mostly programming modes. Variety is great, but too much fragmentation is hurting the ecosystem.
* Look at things that other editors are doing better, mostly VS Code. In the past, this approach motivated implementing a package manager (ELPA), which was a huge step forward.
* Get better documentation. It's hard to find up-to-date information for many packages. Besides, the tutorial focuses too much on keybindings and doesn't talk about Emacs core principles. So, to a beginner Emacs looks like a bunch of keystroke tricks that make zero sense.
Vim can be upgraded to IDE with plugins, and Emacs can be downgrade to a plain text editor, so they are comparable, but their primary goals are different: Vim focus is on editing of text, while Emacs focus is on integration of editor with tools.
If you need a development environment, then forget about Vim, JEdit, nano, pico, etc. If you need just a text editor, then forget about Emacs, Eclipse, Idea, VSCode, etc.
The Vim vs. Emacs “war” meme has far surpassed the supposed rivalry itself; the two programs are so different that you might as well be comparing a, I dunno, a megaphone to a woodchipper. (What, the analogy doesn’t make sense, you say? Well exactly.)
The two programs attract not only people with different temperaments but also people with completely different needs and wants.
F1 race cars are literally the least flexible cars available. They are designed for exactly one type of racing and there is hardly anything you are allowed to configure the way you want. There are cars with higher top speeds than F1 cars, and cars that accelerate faster. A $2k second hand Honda Civic will beat the crap out of an F1 car around a gravel track. F1 cars aren't even the fastest design for racing on F1 race tracks. F1 cars are only good for one thing, and that is winning F1 races.
How about in the snow? How about a road with random 2-inch-high debris? How about a road with lanes of uneven pavement? And how's that air conditioning in the F1? Great for transporting kids too.
The F1 is designed to do exactly one thing exceptionally well, at the expense of practically everything else. It is the opposite of flexible.
And none of that will matter after the first time you drive over a 6 inch rock
Well, I can't say that I like cars or enjoy driving them, but the biggest advantage of a car compared to a bike is its roof - at least, when it rains.
I found this a bit confusing. Why is that, do F1 races have a speed limit? I openly admit my ignorance about F1.
The "Formula" in "Formula 1" means there are certain constraints (i.e., the formula) to how you can design your car. Very quick illustration, check out the buzz on the new F1 car spec for next year. It is already touted to be faster than this year's cars mostly because of aero changes.
Even easier illustration: the current (and I assume all future) spec has this halo whose sole purpose is to protect the driver. It's a ~7kg frame that's basically dead weight to the car. You can remove that and instantly gain maybe a few seconds of laptime at the expense of safety (I am in favor of the halo's presence, btw.).
The spec aside, the rules and regulations also try to enforce a competitive line-up so they regulate budget and, next year, wind tunnel testing time. So in theory if teams had carte blanche for car R&D we can have faster cars. But they won't be F1-compliant so they lose by default.
F1 cars are mostly optimised for massive aerodynamic downforce and lightness, which allows for unholy levels of braking, acceleration, and cornering speeds, but eventually the downforce hobbles top speed.
The LMP (Le Mans) formula of a couple of years ago has heavier cars with higher peak outputs, but lower downforce. They're slower around an F1 style track because their cornering and acceleration suffers due to the extra weight, but they have a higher top speed if they're on a long straight.
Your analogy works too, but it's parallel.
In reality though, Emacs is a subpar editor for both everyday and specialized tasks that's fallen into obscurity as its maintainers refuse to implement anything that would make it keep up the pace with superior editors.
Until your Emacs process is hung again, waiting for IO, or can't process a "jump to definition", or chokes on a file with extremely long lines, or the stitched-together macOS dark mode switcher daemon has crashed, ad infinitum.
Yes, it's a race car, but from 1987, and in total disrepair.
The massive flaw in your analogy being that Emacs has more to do with an old and crumbling collection racing car than a F1. Its users constantly need to tinker it to make it somewhat run like a normal car. It’s still slower and less ergonomic but they are blinded by their love and habit to its obvious flaws.
The amount of IDE and editors that just work well with little customisation and have great refactoring features is now so high, it leaves little place for emacs.
What can they do that emacs can't?
They realize that despite the potentially subpar text editing experience, a highly polished modern Integrated Development Environment is a power tool and a productivity machine for the environment it's aimed at.
One simple example, maybe Emacs can do this. Can Emacs through a press of a button, show a tooltip or a hovering window, directly over the text where my cursor is? Not another window to the side of the editing window or below it. I want my eyes to be stationary and I want the tooltip to be easily dismissable.
Plus, IDEs have professional developers writing integrations so I don't have to, and they're paid to do that for tens of thousands of paying customers, so they pretty much are guaranteed to work. They are also pretty much guaranteed to work well with other advanced integrated features.
2. Why would I want to put a tooltip over an emacs window?
3. The things that contemporary IDEs can do that Emacs may be clunkier at are mostly things I'm not interested in doing. They are also often addressable in totally different ways. The speed of tools like ag(1) and their integration into Emacs changes the need for Emacs itself to be able to take me to special places in a codebase, for example.
Why would you want to? I don't know.
But <<I>>'d want to :-)
Let me check...
Yes, it can do it. In org mode at least.
I have spent way more time fighting against the VS Code configuration than I would like, and even comparing it against all the time I've spent customizing Emacs over my lifetime, I don't think VS Code can come out ahead. All this because I'm not building my project with some build system that has a simple, easy integration with the IDE. When VS Code instantly works, it's great. Otherwise, I'm editing JSON configuration files. That doesn't seem like some massive improvement over editing your .emacs file. It's often worse.
Often it comes down to working with larger projects written in multiple languages. If you are working on some bog-standard JavaScript project that runs in the browser, Node.js, or both, maybe you won't run into this stuff.
Emacs is my escape hatch for "damn, VS Code is messed up again, and I just want to work on the code instead of fussing about". I've had major problems getting VS Code to deal with the C or C++ code that I work on, like, at all. I'm hesitant to even try CLion because it sounds like many of the problems are the same there (it has great CMake integration... but I don't use CMake).
> One simple example, maybe Emacs can do this. Can Emacs through a press of a button, show a tooltip or a hovering window, directly over the text where my cursor is?
That's how code completion works in Emacs. Integrates with LSP, if you want, with various fallbacks.
LSP has really leveled the playing field between IDEs and Emacs. It lets you get a lot of the high-quality integrations, and they work well in both Emacs and IDEs. Prior to LSP, I'm going to say that the only easy way to get that kind of tooling was to use an IDE for a specific language, and it only worked well if your build system was integrated with that IDE.
> Plus, IDEs have professional developers writing integrations so I don't have to, and they're paid to do that for tens of thousands of paying customers, so they pretty much are guaranteed to work. They are also pretty much guaranteed to work well with other advanced integrated features.
My experience with C++ mode in VS Code is extremely rough.
This is the age-old problem... I remember reading people making the same complaints about IDEs and text editors on newsgroups in the 1990s. Like, if you are a Mac programmer, you want to use CodeWarrior... if it works. If you have a more complicated build system, then you need MPW. Too bad.
The experience with IDEs is getting better, much better, and I think all that is really happening is that Emacs users occasionally pop their heads over to IDE-land to see if will work for them. Sometimes it does, and you get one of those articles you're talking about.
That's because you're supposed to use Visual Studio for everything VS can do at all.
I'm fairly familiar with it, and how it's integrated with MSBuild, and what the limitations of MSBuild are, and whether I'm comfortable working within those limitations (and porting my code to Windows).
It's flexible to cover maybe 90-95% of development needs for the main language targeted.
And for those clearly defined use cases, modern IDEs generally fly. Which is far from guaranteed with bespoke configurations (Emacs, Vim).
Eclipse has Javascript and Python plugins, for example so you can code in Java, Javascript, Python at the same time.
VS Code has a ton of language plugins you can use all at the same time.
IntelliJ has a ton of language plugins you can also use all at the same time.
No, they don't. Show me the IDEs with Common Lisp, Coq, Ocaml, Haskell, Elm, ... support. That's actually the reason Code is a real alternative to Emacs and Intellij isn't.
Emacs shines when using Coq (with Proof General) or Common Lisp or Clojurescript (I guess Clojure too). But for mainstream languages like JS, Go or Python you're better off with something like Code.
And there are roughly 20 F1 drivers on the planet at a given time, are you suggesting the total audience for emacs is about 20?
Some of us want a car that any of our relatives can just jump in and use.
Both goals make sense.
Yes, the Jeep Wrangler will topple over while trying to go through a ravine (which no other mass-produced four-wheeled vehicle would ever be capable of going through), but that's what after-market rollcages are for.
An F1-analogue editor would be incredibly fragile, narrowly focused, and demand a huge amount of maintenance.
For the last, both this HN discussion and IIRC TFA offer widely varying estimates as to how much people need to tinker with their configuration files. For the others, only being able to run on one kind of track (absolutely flat ones) would be for an editor to only work for one programming language; spinning and flying into bits at the slightest touch would be for the editor to crash as soon as you type in bad syntax or misspell a variable name; and needing the engine rebuilt after each race and replaced every third or fourth would be... I'm not sure, needing to update to a new version of your editor every three or four weeks?
If Emacs is like any sort of car, it's certainly not an F1 one.
If we want to assign a car to emacs, it's more like a Toyota Tacoma, with no body. Rugged, flexible, some basic building blocks that function out of the box.
So going by results, if emacs was so awesome and if it gave such a huge boost, then we would see those results, and it would be trivial to convince anyone to switch to it.
Personally, I don't see editing text as a bottleneck for developer productivity. The vast majority of time is spent reading code, thinking about code, stepping through/debugging code, reading specs, etc. Yes, emacs can do those things to (as can any system that supports plugins), but my point is that we don't see a 'competitive edge' where all the most productive developers use X. What we see is productive developers using a wide variety of tools. Going back to your F1 analogy, there isn't a single sedan winning F1 races.
Rather than an F1 race car, maybe the analogy would be better made to one of those backhoe/front loader combos. While it won't do simple operations like getting you from point 'A' to point 'B' as quickly, you can do more once you get there as compared to the family sedan. Of course, once you do get there you have to invest substantial time learning how to use the backhoe, the front loader, how not to tip it over, how not to inadvertently break stuff with it, etc. But once you've taken all that time and practiced it enough... you can do quite a lot.
That metaphor feels very much more Emacs like.
With regards to obsolete and outdated - I started using vi and emacs back in 1989 (I currently use vi more). The keybindings and such I learned back then are still relevant.
In my day job, I mostly program Android. Before 2014, I programmed with Eclipse and an Android plugin, which is what Google suggested. Then Android Studio was released, which is what Google suggested. As I haven't used Eclipse at all since around 2014-2015, Eclipse, to me any how, has become "obsolete/outdated". Yet I'm still using vi (and emacs) as I have since the 1980s. They have not become outdated, I still use them as I always have.
Most people want a newer car, that's picked up the improvements in safety and performance from the last 30 years.
Maybe it's easier to understand via analogy. Let's consider cars. Of the global population of car users, relatively few of them are F1 racecar drivers. Furthermore, you can easily make the case that the particular features (aerodynamics, speed etc.) that make the F1 a good racecar, would not be useful for the average driver - the time they spend honing their skills to handle such a beast, you could argue, would be better spent on other things. But, at the same time, the F1 car has and will continue to have a place in the car ecosystem.
In the case of developers, you might be right that, for the average developer, working on your run of the mill, mundane, forgotten-in-a-few-years, CRUD web apps, a normal _average_ car (M$ vscode) would be a better investment, but no matter what, you will never be as fast or flexible as an F1 car (GNU Emacs).