20 ms·

I see many people on here (likely non-emacs users) claiming that Emacs is obsolete/outdated/dying by completely misunderstanding its position in the ecosystem.

• btreecat 5y ago
  There is no world, in which "flexible" and "F1 Car" belong in the same sentence. By design, a track car gets rid of anything "flexible" for highly optimized choices. 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.
• bch 5y ago
  I just love that for a moment here we’ve put aside our differences about emacs vs vi and focused our efforts on bike shedding which car analogy best fits. Peak computing culture.
  • skytreader 5y ago
    I wouldn't waste keystrokes on the classic religious war being waged in this thread so I'm gonna throw my hat in this arena instead. I agree with you---that analogy sucks. 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.
    • nextos 5y ago
      I think the right POV is that Emacs is a text-mode Lisp VM, or at least the remains of one. Whereas vi is just a (great) modal editing interface. They are not comparable. 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.
      • goohle 5y ago
        VI is modal text editor (think JEdit). Emacs is IDE (think Eclipse). 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.
    • avgcorrection 5y ago
      My eyes roll so hard at mentions of the “religious war” that my eye doctor has had to put them back in their sockets multiple times. 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.
• mjh2539 5y ago
  I think a better analogy would be comparing a Mercedes W123 (Vim/Neovim) with a Toyota Camry or Honda Accord (VSCode/Jetbrains) with a Jeep Wrangler (Emacs). 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.
  • lpcvoid 5y ago
    In my opinion Jetbrains products are vastly superior to VSCode in every metric except price.
• mnd999 5y ago
  That’s a terrible analogy. An F1 car isn’t flexible, it’s highly specialised. 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?
  • FredPret 5y ago
    I know right, are there actually 20 people who want to use Emacs!?
    • medo-bear 5y ago
      21
      • asah 5y ago
        22
        • npmaile 5y ago
          21
          • masterof0 5y ago
            22
    • donio 5y ago
      Yeah, that sounds about right. And not to mention that with the 5K+ packages currently on MELPA we each had to write 250 of them. It's rough.
      • FredPret 5y ago
        At least you had Emacs!
• kqr 5y ago
  It sounds like you know very little about either F1 cars or Emacs. Emacs is more like an older Toyota pickup truck – been around for a long time, ubiquitous, flexible, can carry a load, simple, there's an abundance of spare parts, and there's no problem with it that a good mechanic cannot fix – most problems can be fixed even by improvisation in the field.
  • pkulak 5y ago
    I still like the idea that professional tools, while too much work for most, are worth the effort to master, in a professional setting. Your analogy works too, but it's parallel.
• GhettoComputers 5y ago
  A better analogy is a non fuel injector vehicle that doesn’t need electronics to fix, is old and consistent, that works the same. It’s like x.org, you can rely on it to not change the UI constantly (like gnome breaking something in every version).
• agarren 5y ago
  The VS Code/normal car and emacs/F1 racer analogy seems weak. VS Code can bring most of the functionality of a relatively well tuned and customized vim or emacs setup to a much broader range of developers, and with very little investment. Less time spent gold-plating and polishing an editor's configuration is more time spent solving actual problems.
• WastingMyTime89 5y ago
  > but no matter what, you will never be as fast or flexible as an F1 car (GNU Emacs). 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.
  • klodolph 5y ago
    I would love to meet this mythical Emacs programmer which is blinded to its flaws, I don't think they're common.
    • WastingMyTime89 5y ago
      There are people in this thread talking positively of ELisp (a shameful language even by the low standards set by other Lisp) and who thinks the emacs GUI experience is acceptable in 2021. Some are even arguing that having to write 1000 lines of the previously cited terrible language to get the UX behaviours everyone has been expecting from a text editor in the past three decades is a worthwhile time investment. I would argue that apparently they are numerous.
      • klodolph 5y ago
        It sounds like you are saying that people who don't share your opinion on ELisp are blinded to its flaws... but that doesn't make sense. Are you saying that?
      • throwaway2331 5y ago
        I'm thinking about converting to a modern IDE away from emacs-nox. What can they do that emacs can't?
        • klodolph 5y ago
• bitwize 5y ago
  Emacs is more like a car from a Mad Max film than it is an F1 racer: each instance of Emacs has been so heavily modified (often in haphazard, kitbash fashion) that it's only ever supposed to be driven by one person: its owner.
  • PaulDavisThe1st 5y ago
    Some of us want a car that is intimately adapted to how and where we drive. Some of us want a car that any of our relatives can just jump in and use. Both goals make sense.
• deworms 5y ago
  There's that condescending attitude again. In your fantasy land Emacs is an F1 race car, and everyone else is a CRUD-writing code monkey that drives a cheap sedan. 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.
  • rollcat 5y ago
    With 15+ years of daily Emacs usage, I couldn't agree more. It's 50% force of habit, and 50% the few commands (align-regexp! kill-rectangle!), packages (magit! tramp!), or custom Lisp snippets that make every other editor feel inadequate... 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.
• Zababa 5y ago
  I don't want to sound rude but I've never seen a well executed car analogy, especially when they use F1 racecars. Your analogy doesn't make the position of Emacs easier to understand at all.
  • CRConrad 5y ago
    > I've never seen a well executed car analogy, especially when they use F1 racecars. 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.
• drumhead 5y ago
  I used Emacs, its a lot more than just a simple text editor, its more powerful than a text editor or even many IDEs. But the learning curve is too steep for most people. With VScode I can just install it and start working straight away, I cant really do that with Emacs. I dont want Emacs to die out or fade away, but lets be honest its for a much smaller group of users. It they want it to be be popular it would have to change, but then it wouldnt be Emacs anymore.
  • sigzero 5y ago
    That about sums it up.
• dagw 5y ago
  you will never be as fast or flexible as an F1 car 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.
  • f00zz 5y ago
    > F1 cars aren't even the fastest design for racing on F1 race tracks. I found this a bit confusing. Why is that, do F1 races have a speed limit? I openly admit my ignorance about F1.
    • windthrown 5y ago
      There isn't a speed limit but by placing strict limitations on the engine design, they indirectly limit the speed of the cars.
    • skytreader 5y ago
      I'll defer to someone better informed than me but I understood that as a reference to the rules and regulations around F1 cars. 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.
    • AtNightWeCode 5y ago
• Ologn 5y ago
  > claiming that Emacs is obsolete/outdated/dying > run of the mill, mundane, forgotten-in-a-few-years, CRUD web apps, a normal _average_ car (M$ vscode) 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.
• sbuttgereit 5y ago
  Hmmm... I agree that Emacs is specialist, but at least half the reason I don't use it is that it tends to be fairly sluggish if you start really configuring it and using it. 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.
• passivate 5y ago
  I don't think your analogy holds up. If you race an F1 car alongside a commuter sedan, it is obvious to anyone observing the differences in performance, handling, traction, etc. 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.
• CJefferson 5y ago
  If you want to continue this analogy, I don't want a 30 year old F1 car. Also, as with old cars there is a bunch of people who are determined everything invented in the last 30 years is stupid, and we should stick with "good old reliable" things. Most people want a newer car, that's picked up the improvements in safety and performance from the last 30 years.