10 ms·

"VSCode is the greatest productivity tool in the history of software engineering" in a world where vi and emacs exist seems like a bit of an exaggeration, and I

"VSCode is the greatest productivity tool in the history of software engineering" in a world where vi and emacs exist seems like a bit of an exaggeration, and I'm not even a fan of either (VS Code is my daily driver; I like my GUI editors and I like them to behave like normal apps on the platform I'm running).

thallada 4y ago
You can run vim and emacs in a gui app. I run neovim in neovide which imo is the best experience for vim these days. Vim's builtin terminal is good enough now that you can ditch running it inside tmux/terminal.
- JonathonW 4y ago
  Vim and emacs do not adhere to platform conventions anywhere, unless your platform happens to be "emacs".
  - satvikpendem 4y ago
    They're all terminal apps so I'm not sure why platform conventions would matter. Sure some people use GUI wrappers but most people primarily use them in terminals which have the same conventions everywhere, generally speaking.
    - p-e-w 4y ago
      Platform conventions matter because uniformity matters. It's a mystery to me why people just accept that in their (terminal) text editor, copying text uses a different shortcut than it does in their web browser. That is terrible usability, consumes brain cycles for no good reason, and is above all else completely unnecessary because modern alternatives exist that actually blend in with the system they're a part of.
      - satvikpendem 4y ago
        You mean like yy versus ctrl+c? You can definitely use a Vim browser/OS extension but Vim does it that way because the creator, I suppose, perceived that his user interface is better than what's already there. And I tend to agree. I don't need uniformity if it'll be inefficient.
        zopa 4y ago
        vi and emacs don’t follow desktop conventions because they predate desktop conventions (and vim of course follows vi)
        deleted 4y ago
        [deleted]
      - nocman 4y ago
        > Platform conventions matter because uniformity matters. There are tradeoffs to using software that has different shortcuts for similar things you might do in other software. Uniformity is nice, but I don't find it to be so essential that there is no room for any different ways of working. > It's a mystery to me why people just accept that in their (terminal) text editor, copying text uses a different shortcut than it does in their web browser. I don't think they "just accept" it. In the case of emacs (and I believe vim also), you can enable a CUA mode if you wish, and have keybindings that are more like the system. However, in my experience, users of both of those text editors (and indeed, I use both) often choose to use the normal keybindings of those editors intentionally. In my opinion, it doesn't "consume brain cycles for no good reason". There are two very different approaches between those two editors, both are perfectly reasonable and valid. The fact that "modern alternatives exist..." is not necessarily relevant. People have been using both of those editors for years, and they are well versed in how they work and can be very efficient using them. Suggesting that they should just switch to a modern alternative makes some broad assumptions. 1) That they would be happier using some "modern alternative". 2) That whatever value they get from using those editors with different keybindings pales in comparison to what they would gain from switching to an editor with bindings more consistent with the system. I don't believe you can assume either of those things for most of the people who choose to continue to use either of those editors after working in them for a significant amount of time. Don't get me wrong, I understand your viewpoint. It's just that not everyone finds that uniformity to be as important as you do. I also think it is important to point out that both vim and emacs are in active development, so it is not as if either of them has been "mothballed". So while their user interface conventions are very different from much "modern" software, it is not as if they are abandoned -- both are still being developed. They obviously both have significant value to a lot of people.
    - donatzsky 4y ago
      Emacs isn't really a terminal app, though. CLI is just one of several frontends. And there are good reasons to prefer the gui version: https://irreal.org/blog/?p=5835 https://irreal.org/blog/?p=5835
  - noufalibrahim 4y ago
    There was a running joke about this on the Emacs irc channels. "I use Linux. One of the libraries that Emacs can use to communicate with the hardware."
  - jen20 4y ago
    Nor does VS Code, thanks to being a web page inside a native frame.
  - prmoustache 4y ago
    Anything running on electron, such as vscode, do not adhere to platform conventions either.
  - Kamq 4y ago
    Do you know any platforms that adhere to vim/emacs conventions? Because that sounds way better than any of the options I'm aware of.
fastball 4y ago
How many daily users do vim and emacs have? How many daily users does VSCode have?
- mosselman 4y ago
  How many people believed the earth was flat at one point? To be clear, I don’t care either way about vim or vscode. I use vim mode in vscode right now, but I might use something else later. All I care about is being able to work pleasantly. What I meant is that numbers of people doing something is not proof for something being better. For instance: How many people listen to Justin Bieber and how many listen to The Doors?
  - fastball 4y ago
    The claim was not that VSCode is a better editor than vim or emacs, but rather that "VSCode is the greatest productivity tool in the history of software engineering". To me, the tool that matches that description is the one which most increases the productivity level for the most people. Emacs or Vim might be better at increasing the productivity of a single individual (super huge might here – I personally found VSCode improved my productivity much more than vim ever did), but once you multiply that out by the number of people impacted, I doubt there is much contest.
- meindnoch 4y ago
  Thankfully neither emacs nor vim have built-in tracking, so we may never know.
- NateEag 4y ago
  The closest thing I know to an actual source for this is the StackOverflow developer survey. 2022 edition says 74% of respondents use VSCode regularly, 23% use Vim regularly, and 4% use Emacs regularly. https://survey.stackoverflow.co/2022/#section-most-popular-technologies-integrated-development-environment https://survey.stackoverflow.co/2022/#section-most-popular-t...
p-e-w 4y ago
Vim and Emacs cannot compare to VSCode when it comes to productivity. With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment for that language ready to go. This is light years ahead of the traditional editors, and saves many hours of time. Not to mention that VSCode has countless other productivity boosters built in which would require plugin hunting or fiddling with configuration files for Vim and Emacs.
- kuratkull 4y ago
  If we're talking about professional tools i'm not sure if setting it up as fast as possible is the best productivity comparison. All good tools need getting to know them, and setting things up yourself (eg. in vim) means you also know how to fix any issues that pop up in the future. Installing a vscode plugin for playing around is great, but it doesn't automatically make you a professional and stable production environment.
  - p-e-w 4y ago
    > All good tools need getting to know them Wrong. Good tools don't require that. Imagine someone showed you a complicated mechanical contraption and told you "it's a type of hammer, much better than the 'non-professional' hammer, but you need to 'get to know it' first". That product would be dead on arrival. Great tools are obvious in their base functionality and have optional additional layers that can be discovered if necessary. When you have to search the web to find out how to close the editor you just opened, because it works differently than every other program running on your system, you know you're using a bad tool.
    - zopa 4y ago
      Step inside a woodworking- or machine shop sometime and see how many of tools there you can instantly use with proficiency, with no instruction. (Please stand back from the table saws while trying this experiment.) It’s wonderful and beautiful that we can get real work done with a heavy thing on a stick, but pretending every tool can be as simple as a hammer is not really arguing in good faith.
rtpg 4y ago
Of course a lot goes on but pre-LSP and post-LSP are day and night. There is now a huge amount of serious language tooling that _isn't_ locked up into one or several editors. Now some might point out that LSP-based stuff is, like, bloat. Sure, OK. But there's a lot of motivation to do work that can pay off across the board. So much language stuff was based off of random regexes! It's hard to overstate how much better of an editor situation we are in than 10 years ago. This isn't even getting into VS Code offering a way for you to put... one? two? files into a git repo and have that mean that opening the editor will spawn a container, _install itself in the container_, and run there while still having a native GUI for the actual usage of the tool. So much incidental complexity, gone! One might point out that containers are a "big ball of mud" solution, but I vastly prefer that to big setup scripts that only half work. Here's to hoping we can shrink the ball of mud.
- Beltalowda 4y ago
  LSP is nice, but it's not an engineering marvel. It's just a text protocol. It's not even a great text protocol; it's okay, but not great. There's been lots of "LSP-like" protocols over the years, even decades, it's just that none of them really became a standard (partly because no one actually invested the time in writing one, and it just used an "ad-hoc protocol"). And of course the general concept of "process A communicates with process B over a text protocol" is all around us. Like I said, I like LSP, but a great exceptional feat of engineering it is not. This applies to most of VSCode as near as I can tell.
  - rtpg 4y ago
    The thing is it successfully had work put in so that it’s a standard. “They did a thing that basically no one succeeded in doing” is, imo, proof of something.
    - krageon 4y ago
      It's proof of nothing but popularity, which isn't indicative of quality in the least.
    - 4y ago
squokko 4y ago
vi and emacs have certainly had more impact to date, but at the current moment VSCode far outcompetes it on every front. That doesn't mean that there aren't people who still prefer vi or emacs, the same way that some people still ride horses despite the fact that cars exist.
- tincholio 4y ago
  You seem to be implying that VSCode is "better" than Emacs or Vim, as cars are better than horses, but other than having wider adoption atm, I'm not sure it's "better" in any meaningful way.
- zeveb 4y ago
  I think it’s more like how some people still wear wool and linen despite the fact that polyester and rayon exist. Popularity does not equal quality.
jonnycomputer 4y ago
I appreciate you saying Emacs, and vi, but I don't think we even have to reach out of the Microsoft ecosystem to find an even great achievement of engineering for a productivity app; namely Excel.

thallada 4y ago

You can run vim and emacs in a gui app. I run neovim in neovide which imo is the best experience for vim these days. Vim's builtin terminal is good enough now that you can ditch running it inside tmux/terminal.

JonathonW 4y ago
Vim and emacs do not adhere to platform conventions anywhere, unless your platform happens to be "emacs".
- satvikpendem 4y ago
  They're all terminal apps so I'm not sure why platform conventions would matter. Sure some people use GUI wrappers but most people primarily use them in terminals which have the same conventions everywhere, generally speaking.
  - p-e-w 4y ago
    Platform conventions matter because uniformity matters. It's a mystery to me why people just accept that in their (terminal) text editor, copying text uses a different shortcut than it does in their web browser. That is terrible usability, consumes brain cycles for no good reason, and is above all else completely unnecessary because modern alternatives exist that actually blend in with the system they're a part of.
    - satvikpendem 4y ago
      You mean like yy versus ctrl+c? You can definitely use a Vim browser/OS extension but Vim does it that way because the creator, I suppose, perceived that his user interface is better than what's already there. And I tend to agree. I don't need uniformity if it'll be inefficient.
      - zopa 4y ago
        vi and emacs don’t follow desktop conventions because they predate desktop conventions (and vim of course follows vi)
      - deleted 4y ago
        [deleted]
    - nocman 4y ago
      > Platform conventions matter because uniformity matters. There are tradeoffs to using software that has different shortcuts for similar things you might do in other software. Uniformity is nice, but I don't find it to be so essential that there is no room for any different ways of working. > It's a mystery to me why people just accept that in their (terminal) text editor, copying text uses a different shortcut than it does in their web browser. I don't think they "just accept" it. In the case of emacs (and I believe vim also), you can enable a CUA mode if you wish, and have keybindings that are more like the system. However, in my experience, users of both of those text editors (and indeed, I use both) often choose to use the normal keybindings of those editors intentionally. In my opinion, it doesn't "consume brain cycles for no good reason". There are two very different approaches between those two editors, both are perfectly reasonable and valid. The fact that "modern alternatives exist..." is not necessarily relevant. People have been using both of those editors for years, and they are well versed in how they work and can be very efficient using them. Suggesting that they should just switch to a modern alternative makes some broad assumptions. 1) That they would be happier using some "modern alternative". 2) That whatever value they get from using those editors with different keybindings pales in comparison to what they would gain from switching to an editor with bindings more consistent with the system. I don't believe you can assume either of those things for most of the people who choose to continue to use either of those editors after working in them for a significant amount of time. Don't get me wrong, I understand your viewpoint. It's just that not everyone finds that uniformity to be as important as you do. I also think it is important to point out that both vim and emacs are in active development, so it is not as if either of them has been "mothballed". So while their user interface conventions are very different from much "modern" software, it is not as if they are abandoned -- both are still being developed. They obviously both have significant value to a lot of people.
  - donatzsky 4y ago
    Emacs isn't really a terminal app, though. CLI is just one of several frontends. And there are good reasons to prefer the gui version: https://irreal.org/blog/?p=5835 https://irreal.org/blog/?p=5835
- noufalibrahim 4y ago
  There was a running joke about this on the Emacs irc channels. "I use Linux. One of the libraries that Emacs can use to communicate with the hardware."
- jen20 4y ago
  Nor does VS Code, thanks to being a web page inside a native frame.
- prmoustache 4y ago
  Anything running on electron, such as vscode, do not adhere to platform conventions either.
- Kamq 4y ago
  Do you know any platforms that adhere to vim/emacs conventions? Because that sounds way better than any of the options I'm aware of.

fastball 4y ago

How many daily users do vim and emacs have? How many daily users does VSCode have?

mosselman 4y ago
How many people believed the earth was flat at one point? To be clear, I don’t care either way about vim or vscode. I use vim mode in vscode right now, but I might use something else later. All I care about is being able to work pleasantly. What I meant is that numbers of people doing something is not proof for something being better. For instance: How many people listen to Justin Bieber and how many listen to The Doors?
- fastball 4y ago
  The claim was not that VSCode is a better editor than vim or emacs, but rather that "VSCode is the greatest productivity tool in the history of software engineering". To me, the tool that matches that description is the one which most increases the productivity level for the most people. Emacs or Vim might be better at increasing the productivity of a single individual (super huge might here – I personally found VSCode improved my productivity much more than vim ever did), but once you multiply that out by the number of people impacted, I doubt there is much contest.
meindnoch 4y ago
Thankfully neither emacs nor vim have built-in tracking, so we may never know.
NateEag 4y ago
The closest thing I know to an actual source for this is the StackOverflow developer survey. 2022 edition says 74% of respondents use VSCode regularly, 23% use Vim regularly, and 4% use Emacs regularly. https://survey.stackoverflow.co/2022/#section-most-popular-technologies-integrated-development-environment https://survey.stackoverflow.co/2022/#section-most-popular-t...

p-e-w 4y ago

Vim and Emacs cannot compare to VSCode when it comes to productivity. With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment for that language ready to go. This is light years ahead of the traditional editors, and saves many hours of time. Not to mention that VSCode has countless other productivity boosters built in which would require plugin hunting or fiddling with configuration files for Vim and Emacs.

kuratkull 4y ago
If we're talking about professional tools i'm not sure if setting it up as fast as possible is the best productivity comparison. All good tools need getting to know them, and setting things up yourself (eg. in vim) means you also know how to fix any issues that pop up in the future. Installing a vscode plugin for playing around is great, but it doesn't automatically make you a professional and stable production environment.
- p-e-w 4y ago
  > All good tools need getting to know them Wrong. Good tools don't require that. Imagine someone showed you a complicated mechanical contraption and told you "it's a type of hammer, much better than the 'non-professional' hammer, but you need to 'get to know it' first". That product would be dead on arrival. Great tools are obvious in their base functionality and have optional additional layers that can be discovered if necessary. When you have to search the web to find out how to close the editor you just opened, because it works differently than every other program running on your system, you know you're using a bad tool.
  - zopa 4y ago
    Step inside a woodworking- or machine shop sometime and see how many of tools there you can instantly use with proficiency, with no instruction. (Please stand back from the table saws while trying this experiment.) It’s wonderful and beautiful that we can get real work done with a heavy thing on a stick, but pretending every tool can be as simple as a hammer is not really arguing in good faith.

rtpg 4y ago

Of course a lot goes on but pre-LSP and post-LSP are day and night. There is now a huge amount of serious language tooling that _isn't_ locked up into one or several editors. Now some might point out that LSP-based stuff is, like, bloat. Sure, OK. But there's a lot of motivation to do work that can pay off across the board. So much language stuff was based off of random regexes! It's hard to overstate how much better of an editor situation we are in than 10 years ago. This isn't even getting into VS Code offering a way for you to put... one? two? files into a git repo and have that mean that opening the editor will spawn a container, _install itself in the container_, and run there while still having a native GUI for the actual usage of the tool. So much incidental complexity, gone! One might point out that containers are a "big ball of mud" solution, but I vastly prefer that to big setup scripts that only half work. Here's to hoping we can shrink the ball of mud.

Beltalowda 4y ago
LSP is nice, but it's not an engineering marvel. It's just a text protocol. It's not even a great text protocol; it's okay, but not great. There's been lots of "LSP-like" protocols over the years, even decades, it's just that none of them really became a standard (partly because no one actually invested the time in writing one, and it just used an "ad-hoc protocol"). And of course the general concept of "process A communicates with process B over a text protocol" is all around us. Like I said, I like LSP, but a great exceptional feat of engineering it is not. This applies to most of VSCode as near as I can tell.
- rtpg 4y ago
  The thing is it successfully had work put in so that it’s a standard. “They did a thing that basically no one succeeded in doing” is, imo, proof of something.
  - krageon 4y ago
    It's proof of nothing but popularity, which isn't indicative of quality in the least.
  - 4y ago

squokko 4y ago

vi and emacs have certainly had more impact to date, but at the current moment VSCode far outcompetes it on every front. That doesn't mean that there aren't people who still prefer vi or emacs, the same way that some people still ride horses despite the fact that cars exist.

tincholio 4y ago
You seem to be implying that VSCode is "better" than Emacs or Vim, as cars are better than horses, but other than having wider adoption atm, I'm not sure it's "better" in any meaningful way.
zeveb 4y ago
I think it’s more like how some people still wear wool and linen despite the fact that polyester and rayon exist. Popularity does not equal quality.

jonnycomputer 4y ago

I appreciate you saying Emacs, and vi, but I don't think we even have to reach out of the Microsoft ecosystem to find an even great achievement of engineering for a productivity app; namely Excel.