7 ms·

I love Emacs, but I think it’s safe to say that it’s a lot harder to use than Visual Studio Code, which is vastly more popular. I think what made VSCode popular

by jolux 6y ago

I love Emacs, but I think it’s safe to say that it’s a lot harder to use than Visual Studio Code, which is vastly more popular. I think what made VSCode popular was the availability of many high-quality extensions for major languages. Unfortunately, my experience with Elisp packages is that they tend to be much less stable. This is changing some with LSP mode, of course, but I think the Emacs community would do well to focus on improving the story for plug-in stability in the long-term. I already have to install use-package to make handling packages reasonable, which is not something I have to do in other editors. Manually setting up hooks for them is a pain in the ass too. I once submitted a bug to the Emacs mailing list and after determining it was indeed a defect, a flame war ensued between maintainers of different subsystems that were competing over how a specific feature was supposed to be used, which was the source of the bug. It was offputting and felt juvenile. Social problems are inevitable in any open source project, but I can’t help but wonder if the highly dynamic nature of Emacs Lisp causes more problems than a less dynamic language would.

bachmeier 6y ago
> I love Emacs, but I think it’s safe to say that it’s a lot harder to use than Visual Studio Code I actually find the opposite. As much as I dislike the clumsy GUI, I just keep coming back to Emacs for some things, for the sole reason that it's easier in Emacs. I find Emacs to be the easiest way to customize my text editor, and that's what makes it easy to get my work done. I've tried VS Code many times and I just don't see what's special about it.
- dragonwriter 6y ago
  I first used emacs 25ish years before VSCode existed and VSCode was pretty much immediately easier to use and customize; to be fair, it's not like I was using Emacs heavily in the intervening quarter century, but I was using it fairly regularly. OTOH, I have no problem believing someone using Emacs as a daily driver for years would find it easier (but I think most developers, and particularly newer developers—where the JS to Lisp familiarity ratio is much higher than for, say, those who got into coding in the 1980s or earlier—are going to more productive more quickly with VS Code.)
  - d0mine 6y ago
    VSCode will likely get you to 80% productivity compared to Emacs pretty fast. The question how easy is to get from 80% to 100%. It is like a prototype vs. polished code: you can create something that provides 80% of the result over a weekend and then spend 2 years polishing it, to get remaining desired functionality. For example, I'm sure VSCode does git but does it as well as Magit? Everyday things can be done on muscle memory, most other things are much more discoverable than I've seen in any git interface (using other git interfaces is like walking in a office with your eyes closed vs open with magit). http://emacsrocks.com/e17.html http://emacsrocks.com/e17.html I'm sure VSCode does notes too but does it as well as Org mode? Org mode for me is an extension of my brain: it is a working memory that supports executing whatever task I do, it helps organize/automate tasks, it helps focus, etc. For people with ADHD like symptoms, I expect a life changing experience thanks to Org mode -- while other people should just become more productive in it. Every keystroke is a programmable command in Emacs. VSCode is close. I expect parity for programming modes. Most Emacs interactions are likely less pointy-n-clicky compared to VSCode: somehow pressing keychords steals my focus less than doing actions with a mouse for everyday things freeing the conscious brain to work on the task at hand. Emacs provides a unified interface for me e.g., searching/filtering lists https://writequit.org/denver-emacs/presentations/2017-04-11-ivy.html https://writequit.org/denver-emacs/presentations/2017-04-11-... Emacs doesn't do web browsing very well. I have to survive with Vimium. Does VSCode perform better here? VSCode is much more popular today. Emacs is GPL -- I expect it to be there in 20 years too. I won't trust Microsoft long term.
    - jolux 6y ago
      >VSCode is much more popular today. Emacs is GPL -- I expect it to be there in 20 years too. I won't trust Microsoft long term. VSCode is open source, too. There are forks with the Microsoft IP removed from it. I believe Eclipse and RedHat maintain one now as well. Other than that I basically agree with you. I much prefer Emacs to VSCode, but there are annoying things about it that mean I don't want to use it full time.
      - mplanchard 6y ago
- deleted 6y ago
  [deleted]
- oblio 6y ago
  1. How long have you been using Emacs? 2. Did your journey into computing start with CLIs, TUIs, GUIs?
  - bachmeier 6y ago
    1. About a decade probably. 2. It started in the 1980s, back when GUIs were considered a luxury upgrade for the wealthy. This was the first computer I ever owned: https://oldcomputers.net/trs80pc1.html https://oldcomputers.net/trs80pc1.html I'd say the biggest reason for the difference is because (by my understanding) you use JSON for configuration and write functions to extend VS Code using Typescript. I've never been a web developer and I've done very little with Typescript (and not much more with Javascript). OTOH, I've been using Lisp in various forms since forever. For me to pop open my .emacs, add an interactive function, and start using it is usually a couple minutes at most. Now I think most users of VS Code probably feel more comfortable with Typescript and JSON, but Emacs for me is just a dead easy thing due to my ability to customize tasks almost trivially.
clircle 6y ago
At least in my discipline (statistics) the Emacs extensions for R and latex seem to be better than Vim, VSCode, etc. Sample size = 1.
- jolux 6y ago
  Emacs has a lot of amazing extensions! Magit is unparalleled for working with Git. The problem is that they break more frequently, in my experience. The very fact that I have to install a 3rd-party DSL to have a sane package management experience is beyond the pale from a usability perspective.
  - clircle 6y ago
    Thank you for this thoughtful comment. I assume you are talking about use-package? I've been using it for several years. There is a long standing effort to have it merged into emacs/elpa, so we hope the situation will improve. https://github.com/jwiegley/use-package/issues/282 https://github.com/jwiegley/use-package/issues/282
    - jolux 6y ago
      Yes, I think it should be merged. Although the fact that this has been open since 2015 also highlights how the copyright assignment requirement slows down the pace of development.
      - anaerobicover 6y ago
        Honestly, it's kept me from contributing to packages, too. I have no problem with the outcome, my patch being "owned" by the project -- that would be my intention by contributing. I just have a strong dislike of bureaucracy, form-filling, and being "on file" somewhere.
  - jamienicol 6y ago
    Clunky interface aside (a given with emacs), what's wrong with package-list-packages and customize? It's essentially no different to installing and configuring packages in vscode. Why do you think use-package is necessary?
koz_ 6y ago
I agree that VS Code is easier to edit code in, but Emacs is easier to program and extend. Ease of use simply isn't why people use Emacs and I think that at this point it would be hard for it to ever compete with VS Code on that front. VS Code is like the Java of text editors. It relies on a universally understood and accepted model of editing text (non-modal, leveraging the mouse heavily), one that is familiar to all users, even those who might prefer a more idiosyncratic and keyboard-driven interface. This is analogous to how Java facilitates a certain style of OO programming that is familiar to the vast majority of programmers, even those that may prefer and see value in other, less popular / accessible modes of programming. By comparison Emacs would of course be the Lisp of text editors. One could try and make Lisp as accessible and nailed down as Java, after all its extreme customisability lends itself to that, but at that point you'd just be writing a poor man's Java instead of Lisp. This is not to say that Emacs can't or shouldn't be made easier to use, just that I don't think its survival depends on it catching up to editors like VS Code which I perceive as being for a different purpose altogether. I do, however, somewhat suspect that the crucial difficulty of Emacs comes from its messiness, from the huge number of people writing interesting extensions in it, and how they don't always quite play nicely with each other without a bit of glue code. I'd love to be wrong about that, though, and one day get the best of both worlds.
- joseph 6y ago
  > I agree that VS Code is easier to edit code in, but Emacs is easier to program and extend. Ease of use simply isn't why people use Emacs and I think that at this point it would be hard for it to ever compete with VS Code on that front. I don't program in Emacs except to fix bugs or make small modifications to my init.el. I use Emacs because it's the easiest editor to use. The keybindings are ubiquitous: they are standard in the command line of bash and other shells as well as numerous other programs, and all throughout the macOS GUI. By sticking to Emacs as an editor I am using the most widely available keybindings anywhere and that helps me be productive in a multitude of places. Emacs has modes for all the languages I use, and especially now with LSP, they generally Just Work. I start Emacs as a server when I log in, and I can connect to it from any shell on the same machine, and my open files are there waiting for me. I guess you might find VS Code better if you like the mouse, but I don't want my hands to leave the keyboard while editing as I find it counterproductive.
soraminazuki 6y ago
From what I can tell, the relative instability of Emacs comes from two things: the lack of well-supported concurrency primitives and defadvice. The former is the source of UI lockups, and if you're really out of luck, you'd have no other choice but to kill the Emacs process. The latter is a footgun in Elisp that allows you to replace or hook into any function defined in Emacs. I think the concurrency problem is solvable given tremendous time and effort. However, I doubt there is anything that could be done about defadvice. For all its shortcomings, defadvice is a defining feature of Emacs that makes it more extensible than any of the competition.
- TeMPOraL 6y ago
  Yeah, I wouldn't touch defadvice itself. We can talk about reminding elisp developers to use it only as a last resort, but ultimately, it is a very important feature, that lets you make modules cooperate even if they don't want to.
- anaerobicover 6y ago
  I have to disagree -- in part -- about the advice system: used sparingly, I think it's one of the killer features that lets me tweak emacs exactly how I want it. That said, yes, I think packages should be (at least) discouraged from using it. A highly dynamic and patch-able software system is a huge asset IF you're the only person working on it, which is true for my own emacs config. But having third parties simultaneously monkeying with the same component without knowing about each other is certainly a recipe for instability, even indeterminism.
notsureaboutpg 6y ago
I left emacs for vscode. The intellisense and code snippets did it for me.
BeetleB 6y ago
> I love Emacs, but I think it’s safe to say that it’s a lot harder to use than Visual Studio Code Emacs discussions on HN are always unsatisfying, because everyone seems to want to compare it with IDEs or other programming editors. Only a small portion of the article is about SW development. The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is. Comparing it to VSCode is meaningless to them. Kind of like having a discussion about PCs, and having people repeatedly talking about how iPods are better. Yes, lots of people use PCs to listen to music, but the comparison is rather silly.
- jolux 6y ago
  >Only a small portion of the article is about SW development. The article, is, however written by a software developer. >The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is. Do we have any hard data here? Or is this just an anecdote? Sure, Emacs is usable for a lot of stuff outside programming. I personally use it for org-mode and as a general-purpose git client. That doesn't mean that the Emacs usability story could be better overall. Obviously I don't think Emacs should be as narrowly focused as VSCode. Greater usability would benefit users who don't program.
  - BeetleB 6y ago
    > That doesn't mean that the Emacs usability story could be better overall. Obviously I don't think Emacs should be as narrowly focused as VSCode. Greater usability would benefit users who don't program. My comment had nothing to do with usability. I merely find the incessant comparisons with VSCode to be (mostly) noise. I'm not even here to advocate for Emacs (although I love it). People want better usability? Fine. But let's not let SW development be the benchmark for how good Emacs is. It's just one use for Emacs. > Do we have any hard data here? Or is this just an anecdote? Very much an anecdote. Thing is, so is any other perception. There is no hard data out there. Having said that, hang out on places like the Emacs subreddit and quite a lot of submissions are not related to SW development. Looking at it right now, only 3 submissions on the front page are related to coding/SW. If you follow the weekly Emacs news, you'll similarly find that the bulk of it is not related to coding/SW.
rcdwealth 6y ago
> I once submitted a bug to the Emacs mailing list and after determining > it was indeed a defect, a flame war ensued between maintainers of > different subsystems that were competing over how a specific feature > was supposed to be used, which was the source of the bug. It was > offputting and felt juvenile. Social problems are inevitable in any > open source project, but I can’t help but wonder if the highly dynamic > nature of Emacs Lisp causes more problems than a less dynamic language > would. Commercial developers have many internal discussions, with the difference that they will not show it to you.
uncletaco 6y ago
This happened all the time at a couple of companies I worked for. The advantage there however was the customer who filed the bug report couldn’t see all the emails bouncing around between teams over who was to blame and who needed to fix the problem.

by jolux 6y ago

bachmeier 6y ago

> I love Emacs, but I think it’s safe to say that it’s a lot harder to use than Visual Studio Code I actually find the opposite. As much as I dislike the clumsy GUI, I just keep coming back to Emacs for some things, for the sole reason that it's easier in Emacs. I find Emacs to be the easiest way to customize my text editor, and that's what makes it easy to get my work done. I've tried VS Code many times and I just don't see what's special about it.

dragonwriter 6y ago
I first used emacs 25ish years before VSCode existed and VSCode was pretty much immediately easier to use and customize; to be fair, it's not like I was using Emacs heavily in the intervening quarter century, but I was using it fairly regularly. OTOH, I have no problem believing someone using Emacs as a daily driver for years would find it easier (but I think most developers, and particularly newer developers—where the JS to Lisp familiarity ratio is much higher than for, say, those who got into coding in the 1980s or earlier—are going to more productive more quickly with VS Code.)
- d0mine 6y ago
  VSCode will likely get you to 80% productivity compared to Emacs pretty fast. The question how easy is to get from 80% to 100%. It is like a prototype vs. polished code: you can create something that provides 80% of the result over a weekend and then spend 2 years polishing it, to get remaining desired functionality. For example, I'm sure VSCode does git but does it as well as Magit? Everyday things can be done on muscle memory, most other things are much more discoverable than I've seen in any git interface (using other git interfaces is like walking in a office with your eyes closed vs open with magit). http://emacsrocks.com/e17.html http://emacsrocks.com/e17.html I'm sure VSCode does notes too but does it as well as Org mode? Org mode for me is an extension of my brain: it is a working memory that supports executing whatever task I do, it helps organize/automate tasks, it helps focus, etc. For people with ADHD like symptoms, I expect a life changing experience thanks to Org mode -- while other people should just become more productive in it. Every keystroke is a programmable command in Emacs. VSCode is close. I expect parity for programming modes. Most Emacs interactions are likely less pointy-n-clicky compared to VSCode: somehow pressing keychords steals my focus less than doing actions with a mouse for everyday things freeing the conscious brain to work on the task at hand. Emacs provides a unified interface for me e.g., searching/filtering lists https://writequit.org/denver-emacs/presentations/2017-04-11-ivy.html https://writequit.org/denver-emacs/presentations/2017-04-11-... Emacs doesn't do web browsing very well. I have to survive with Vimium. Does VSCode perform better here? VSCode is much more popular today. Emacs is GPL -- I expect it to be there in 20 years too. I won't trust Microsoft long term.
  - jolux 6y ago
    >VSCode is much more popular today. Emacs is GPL -- I expect it to be there in 20 years too. I won't trust Microsoft long term. VSCode is open source, too. There are forks with the Microsoft IP removed from it. I believe Eclipse and RedHat maintain one now as well. Other than that I basically agree with you. I much prefer Emacs to VSCode, but there are annoying things about it that mean I don't want to use it full time.
    - mplanchard 6y ago
deleted 6y ago
[deleted]
oblio 6y ago
1. How long have you been using Emacs? 2. Did your journey into computing start with CLIs, TUIs, GUIs?
- bachmeier 6y ago
  1. About a decade probably. 2. It started in the 1980s, back when GUIs were considered a luxury upgrade for the wealthy. This was the first computer I ever owned: https://oldcomputers.net/trs80pc1.html https://oldcomputers.net/trs80pc1.html I'd say the biggest reason for the difference is because (by my understanding) you use JSON for configuration and write functions to extend VS Code using Typescript. I've never been a web developer and I've done very little with Typescript (and not much more with Javascript). OTOH, I've been using Lisp in various forms since forever. For me to pop open my .emacs, add an interactive function, and start using it is usually a couple minutes at most. Now I think most users of VS Code probably feel more comfortable with Typescript and JSON, but Emacs for me is just a dead easy thing due to my ability to customize tasks almost trivially.

clircle 6y ago

At least in my discipline (statistics) the Emacs extensions for R and latex seem to be better than Vim, VSCode, etc. Sample size = 1.

jolux 6y ago
Emacs has a lot of amazing extensions! Magit is unparalleled for working with Git. The problem is that they break more frequently, in my experience. The very fact that I have to install a 3rd-party DSL to have a sane package management experience is beyond the pale from a usability perspective.
- clircle 6y ago
  Thank you for this thoughtful comment. I assume you are talking about use-package? I've been using it for several years. There is a long standing effort to have it merged into emacs/elpa, so we hope the situation will improve. https://github.com/jwiegley/use-package/issues/282 https://github.com/jwiegley/use-package/issues/282
  - jolux 6y ago
    Yes, I think it should be merged. Although the fact that this has been open since 2015 also highlights how the copyright assignment requirement slows down the pace of development.
    - anaerobicover 6y ago
      Honestly, it's kept me from contributing to packages, too. I have no problem with the outcome, my patch being "owned" by the project -- that would be my intention by contributing. I just have a strong dislike of bureaucracy, form-filling, and being "on file" somewhere.
- jamienicol 6y ago
  Clunky interface aside (a given with emacs), what's wrong with package-list-packages and customize? It's essentially no different to installing and configuring packages in vscode. Why do you think use-package is necessary?

koz_ 6y ago

I agree that VS Code is easier to edit code in, but Emacs is easier to program and extend. Ease of use simply isn't why people use Emacs and I think that at this point it would be hard for it to ever compete with VS Code on that front. VS Code is like the Java of text editors. It relies on a universally understood and accepted model of editing text (non-modal, leveraging the mouse heavily), one that is familiar to all users, even those who might prefer a more idiosyncratic and keyboard-driven interface. This is analogous to how Java facilitates a certain style of OO programming that is familiar to the vast majority of programmers, even those that may prefer and see value in other, less popular / accessible modes of programming. By comparison Emacs would of course be the Lisp of text editors. One could try and make Lisp as accessible and nailed down as Java, after all its extreme customisability lends itself to that, but at that point you'd just be writing a poor man's Java instead of Lisp. This is not to say that Emacs can't or shouldn't be made easier to use, just that I don't think its survival depends on it catching up to editors like VS Code which I perceive as being for a different purpose altogether. I do, however, somewhat suspect that the crucial difficulty of Emacs comes from its messiness, from the huge number of people writing interesting extensions in it, and how they don't always quite play nicely with each other without a bit of glue code. I'd love to be wrong about that, though, and one day get the best of both worlds.

joseph 6y ago
> I agree that VS Code is easier to edit code in, but Emacs is easier to program and extend. Ease of use simply isn't why people use Emacs and I think that at this point it would be hard for it to ever compete with VS Code on that front. I don't program in Emacs except to fix bugs or make small modifications to my init.el. I use Emacs because it's the easiest editor to use. The keybindings are ubiquitous: they are standard in the command line of bash and other shells as well as numerous other programs, and all throughout the macOS GUI. By sticking to Emacs as an editor I am using the most widely available keybindings anywhere and that helps me be productive in a multitude of places. Emacs has modes for all the languages I use, and especially now with LSP, they generally Just Work. I start Emacs as a server when I log in, and I can connect to it from any shell on the same machine, and my open files are there waiting for me. I guess you might find VS Code better if you like the mouse, but I don't want my hands to leave the keyboard while editing as I find it counterproductive.

soraminazuki 6y ago

From what I can tell, the relative instability of Emacs comes from two things: the lack of well-supported concurrency primitives and defadvice. The former is the source of UI lockups, and if you're really out of luck, you'd have no other choice but to kill the Emacs process. The latter is a footgun in Elisp that allows you to replace or hook into any function defined in Emacs. I think the concurrency problem is solvable given tremendous time and effort. However, I doubt there is anything that could be done about defadvice. For all its shortcomings, defadvice is a defining feature of Emacs that makes it more extensible than any of the competition.

TeMPOraL 6y ago
Yeah, I wouldn't touch defadvice itself. We can talk about reminding elisp developers to use it only as a last resort, but ultimately, it is a very important feature, that lets you make modules cooperate even if they don't want to.
anaerobicover 6y ago
I have to disagree -- in part -- about the advice system: used sparingly, I think it's one of the killer features that lets me tweak emacs exactly how I want it. That said, yes, I think packages should be (at least) discouraged from using it. A highly dynamic and patch-able software system is a huge asset IF you're the only person working on it, which is true for my own emacs config. But having third parties simultaneously monkeying with the same component without knowing about each other is certainly a recipe for instability, even indeterminism.

notsureaboutpg 6y ago

I left emacs for vscode. The intellisense and code snippets did it for me.

BeetleB 6y ago

> I love Emacs, but I think it’s safe to say that it’s a lot harder to use than Visual Studio Code Emacs discussions on HN are always unsatisfying, because everyone seems to want to compare it with IDEs or other programming editors. Only a small portion of the article is about SW development. The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is. Comparing it to VSCode is meaningless to them. Kind of like having a discussion about PCs, and having people repeatedly talking about how iPods are better. Yes, lots of people use PCs to listen to music, but the comparison is rather silly.

jolux 6y ago
>Only a small portion of the article is about SW development. The article, is, however written by a software developer. >The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is. Do we have any hard data here? Or is this just an anecdote? Sure, Emacs is usable for a lot of stuff outside programming. I personally use it for org-mode and as a general-purpose git client. That doesn't mean that the Emacs usability story could be better overall. Obviously I don't think Emacs should be as narrowly focused as VSCode. Greater usability would benefit users who don't program.
- BeetleB 6y ago
  > That doesn't mean that the Emacs usability story could be better overall. Obviously I don't think Emacs should be as narrowly focused as VSCode. Greater usability would benefit users who don't program. My comment had nothing to do with usability. I merely find the incessant comparisons with VSCode to be (mostly) noise. I'm not even here to advocate for Emacs (although I love it). People want better usability? Fine. But let's not let SW development be the benchmark for how good Emacs is. It's just one use for Emacs. > Do we have any hard data here? Or is this just an anecdote? Very much an anecdote. Thing is, so is any other perception. There is no hard data out there. Having said that, hang out on places like the Emacs subreddit and quite a lot of submissions are not related to SW development. Looking at it right now, only 3 submissions on the front page are related to coding/SW. If you follow the weekly Emacs news, you'll similarly find that the bulk of it is not related to coding/SW.

rcdwealth 6y ago

> I once submitted a bug to the Emacs mailing list and after determining > it was indeed a defect, a flame war ensued between maintainers of > different subsystems that were competing over how a specific feature > was supposed to be used, which was the source of the bug. It was > offputting and felt juvenile. Social problems are inevitable in any > open source project, but I can’t help but wonder if the highly dynamic > nature of Emacs Lisp causes more problems than a less dynamic language > would. Commercial developers have many internal discussions, with the difference that they will not show it to you.

uncletaco 6y ago

This happened all the time at a couple of companies I worked for. The advantage there however was the customer who filed the bug report couldn’t see all the emails bouncing around between teams over who was to blame and who needed to fix the problem.