"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).
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.
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.
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.
I don't think anyone tried to really make a standard, as far as I know. But even if they did, there's lots of reasons why some things take off and others don't: putting in the work as you mentioned, whether it's any good, marketing, state of other tooling and tech, zeitgeist at the time ("timing"), etc.
Would something like Go have taken off 20 years ago? I'm not so sure, the zeitgeist at the time was very much in the direction of dynamic languages. And would Python take off if it was released today? Not so sure about that either.
But you know, putting in the work to write down a specification isn't really a marvel of engineering. It's ... just putting in the work.
> But you know, putting in the work to write down a specification isn't really a marvel of engineering. It's ... just putting in the work.
It's no marvel of engineering, but someone did put in the work, and others used it, more that can be said about many other things that might be "better engineered".
I never said they were "better engineered". I only wanted to refute that "VSCode is one of the greatest pieces of engineering of our time", which went to use LSP as an example in this (sub)thread.
I don't know what LSP is or why you'd think it's anything special or game-changing.
It just seems to be a generic interface to describe language bindings, which most text editors have.
In practice it's mostly a bad thing because any advanced language has special needs which will end up difficult to address by funneling everything through a common interface.
It is a generic interface which also helps with many capabilities, including proper refactoring, formatting, and the like. Since VSCode does so much through it, basically all nontrivial interaction with the code base can also be used in other editors.
A far cry from the days of sublime text’s regex-based autocomplete
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.
> Vim and Emacs cannot compare to VSCode when it comes to productivity.
For me you are 100% correct. In either vim or emacs I am at least 10 times more productive than I would ever be in VSCode. No comparison.
> 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.
First, there are distributions of both vim and emacs that come bundled with sets of plugins, if that is the sort of thing you like.
Second, some people enjoy customizing their editor to work exactly the way they want to. You obviously prefer the "set up out of the box" experience, and that is totally fine. Others boost their productivity by customizing their tools. Different people work differently.
Everyone else is not like you. That doesn't make their preferences invalid.
I have known many developers over the years who use both editors, and are extremely productive using their tool of choice. I am certain many of them would not be more productive using VSCode - it simply does not offer them anything significant enough to them to make that big of a difference.
VSCode's out-of-the-box configuration is better suited for the most common modern development contexts (probably?) and its customization, add-on and overall UIs are definitely more aligned with modern conventions, more readily accessible and more exploration-friendly.
But VSCode is also less responsive, more resource heavy and ultimately less flexible or extensible. Vim and emacs have more of a learning curve, and their configuration is more fiddly, but the biggest hurdle is probably that the interfaces they use for this predate modern GUI conventions. Notably the "search by keyword, click install, done" workflow for adding extensions is definitely standard behavior in emacs (and vim too, I assume).
Configuration fiddling aside - and that shouldn't be a daily activity - "Vim and Emacs cannot compare to VSCode when it comes to productivity" is a claim that does not hold up to scrutiny. In the hands of an expert user, emacs (and again, I assume vim too) is definitely more capable and productive than VSCode. I'm fairly confident this could be demonstrated objectively. They just _do more_ and can be made to do it _exactly the way you want_ them to. The learning curve for vi/vim and emacs represents an investment, but one that can pay off handsomely.
The topic of this thread is actually a perfect example of one of the major advantages of these "classic" editors. Atom - and countless editors that have come before - has been sunset. And it will eventually happen to VSCode too. Your Atom customization skills (and mine) are wasted. Now we need to pick up a new editor and climb a new learning curve. But vim or emacs mastery is a skill you'll literally be able to use for the rest of your career.
It's absolutely valid to decide that learning how to use these esoteric tools well is not worth the effort to you personally, but there _is_ a reason these tools have been around for nearly half a century.
You’re definitely not coming in to this having much familiarity with the ecosystem of either other tool. Distributions like LunarVim, Spacemacs, and Doomemacs exist that fill that gap between the basic terminal editors and a ready-for-anything experience. Think, open a source file and get the language server auto detected and suggested for installation, right in vim.
Not to mention IntelliJ which I can’t help but keep coming back to after repeatedly getting frustrated enough trying to adopt VSCode. The git tooling in VSCode’s marketplace is a far cry from what’s available for some of these other tools. Fortunately for me, Fleet (new editor aimed at VSCode segment) is maturing at a rapid enough pace that I’ll likely be able to migrate to it in months/weeks and hopefully have a more zen experience.
>With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment
Very minor feature. It is not usefull unless you are constantly hunting for new languages.
>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.
This is only true if you are comparing default vim/emacs to VSCode, which would be quite unfair. Compare it to some vim/emacs distributions and list the differences.
> Moreover it is supported out-of-the-box in emacs: `M-x list-packages`.
Or just use the menu; click on "Options” → “Manage Emacs Packages”. No need to scare people with “M-x” weirdness right out of the gate when it isn’t necessary since the option is right there in the menu.
Menus? Clicking? That doesn't seem very emacs-y of you. M-x weirdness - up to and including the fact that it refers to a "Meta" key not found on modern keyboards - is exactly the kind of gatekeeping that allows me to feel superior for knowing how to exit emacs gracefully.
But seriously you raise a good point. The OS-native menus in aquaemacs and similar go a long way toward making emacs more accessible and explore-able.
No joke, it is legitimately hard for a newbie to figure out how to close emacs, which is pretty ridiculous. (It's `C-x C-c` btw, but I honestly don't know how a first-time user could figure that out on their own without a menu. You need to be _told_. It's absolutely crazy that you need to consult the manual to know how it exit the program.)
EDIT: It looks like this thread is too deep for me to post a genuine reply, but just to respond to the "it's just plain emacs too" comment. Good point, and I was aware of that but I didn't know what to call the plain-vanilla Windowed/GUI-enabled emacs. I guess it's just "emacs". I actually hesitated on naming aquaemacs for exactly this reason, which is why I hedged with "or similiar".
To be clear, I’m not talking about the menus in some special Emacs port like aquamacs, I mean the regular Emacs, with its menu bar, seen here: https://www.gnu.org/software/emacs/tour/
I think it actually helps to present M-x to new people as being the "command palette" for Emacs. A modern starting Emacs setup should have a vertical completion setup and fuzzy matching, so hitting M-x and a few keys gives you a list of matching commands with their documentation next to them.
It’s also supported out of the box in SublimeText, though probably not as extensive as VSCode. Code completion, for example, is more like guessing in SublimeText. Though I can’t imagine either emacs or VSCode to respond as quickly to input as SublimeText, which is one of the reasons it will remain the text editor of choice for me. At least when writing some code in Lua.
I appreciate that perspective. Launching quickly and no input latency are probably my base demands from a text editor. Not sufficient, but necessary. I may need to give Sublime a closer look.
FWIW you _can_ get emacs to launch as quickly as, say, vi, and to respond to input as quickly as just typing in the terminal (but in my experience the default GUI doesn't have noticeable input latency):
* `emacs -nw` will launch emacs in a terminal rather than a OS-native GUI window. This has surprisingly little impact on the interface or usability, but it does make cosmetic tweaks like font-rendering more difficult.
* `emacs --daemon` will start an "emacs server" process running in the background, and `emacsclient` will connect a UI instance to it (so you don't need to re-process all your .emacs stuff each time)
That said you can probably introduce a lot of input latency by hooking a slow method to the keypress event, but that applies to Atom and VSCode as well as emacs. But all three of them seem to do OK suggesting auto-completions of one kind or another, which must be handled on keydown or similar, so maybe that's not as critical as I assume.
I usually have a text editor open all the time anyway (recently Atom, lately VSCode) so the time-to-launch isn't that big of a deal in practice (and isn't _that_ large to begin with) but I am disproportionately, irrationally annoyed every time I need to wait for the editor to start.
>>With VSCode, you type the name of any programming language in the extension search, click "Install", and you have a world-class development environment
> Very minor feature. It is not usefull unless you are constantly hunting for new languages.
The big advantage isn't just installing but keeping them up to date without any actual effort. I used to know vimscript, used to understand how the vim package managers I used works and all. With VSCode I don't even know in which language are extenssions written.
I work mostly on golang, and now the environment is certainly more stable, but I remember that in order to have go extensions working on vim I used to have to be updating manually the extensions pretty much every release and it was some effort. Now I update the golang version and things just work.
I do agree the Vim plugin ecosystem (and vimscript) sort of sucks. That said, I've been using Vim for 20+ years and generally only mess with my config and plugins once every 2-3 years at most. Since the thing is just supposed to edit text, why would I feel compelled to update them, much less try to figure out what language they're written in?
> I work mostly on golang, and now the environment is certainly more stable, but I remember that in order to have go extensions working on vim I used to have to be updating manually the extensions pretty much every release and it was some effort. Now I update the golang version and things just work.
Most of that is because the Go ecosystem moved ahead. Five years ago something like vim-go would depend on maybe 15 different binaries that operated on the source code. Automatically updating all of that is possible, but somewhat slow and tricky (especially because there were no modules yet, so had to "go get -u" all these different binaries to check for updates).
Now, it's basically just gopls. You don't even need vim-go any more; just Vim + $any_lsp + gopls gives a very similar experience.
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.
On the contrary, working in a professional environment, almost no one I know is using vim or Emacs seriously day to day for coding. We all use VSCode because that is a tool that just works for our team and company. Having a unified tool set works wonders for group productivity, no more messing around with some employees not having a certain package and others needing to customize their vim configs. No, everything simply works, and we can focus on the actual coding rather than messing around with our configs.
My experience of VSCode _is_ messing around with my config, but giving up and going back to a more mature editor because I could never get it to do what I wanted. I suppose capitulation was also an option, but I dislike the characterisation of tooling as something other than ‘actual coding’.
That's very strange, when did you use it? And what config did you need? In our company there really isn't any config we mess around with, just download the language plug-ins and that's it. If someone wants to add more then that's fine but not required.
I have a setup that I maintain and I pop back to it every six months or so. There are probably three classes of things that end up turning me off.
1) VSCode is very UI heavy and doesn’t allow consistent keyboard and text navigation. I want my text editor to be text-based, and it slows me down to have different types of windows (some of which seem impossible to hide permanently) with inconsistent forms of navigation.
2) The terminal window is its own thing, even if you open it in an editor window, which is then ignored by anything that interacts with the terminal. This is more what I want but is very limited and immature:
The lack of an infrastructure like Emacs comint mode also means there’s no good text-based database mode either. I want the same navigation, search and editing functions in every single window I have to interact with.
3) Where analogues to Emacs modes exist, they are universally less featureful, often because of fundamental limitations of the VSCode extension API. REPLs do less and offer less programmability. Edamagit is a fine and welcome effort but not as good as Magit.
If people want an editor with a little bit of auto completion and some squiggly lines to tell them they’ve typed something wrong VSCode is great. I have many mostly happy VSCode users within my organisation. But I think every individual programmer, like every team, should have a regular little retrospectives with themselves. What work did I do today, what would have made it flow better? In every case, I can build that in Emacs, but it’s much more friction in VSCode. This is partly immaturity and partly the APIs not offering as much. Long term I’m rooting for VSCode because it’s snappy and has undeniable market share. But it’s never quite been there for me yet.
Sounds like junior web devs working on Javascript pull-in-the-whole-internet code bases. Not criticising your choice, it might be the best solution to your specific challenges; that just does not sound like the environment I work in. If somebody can't configure their own editor and its dependencies, I wouldn't trust them to handle application dependencies in the supply chain either.
Then again, I might pre-date the which editor to use and how to configure it era.
For seniors, sure that makes sense, use whatever editor you want, but for onboarding juniors, we definitely have a recommended toolset just so we can make sure there aren't incompatibilities and that their productivity is still high, ie having a debugger when needed, using code completion, error checking, linting tools etc.
My point is you could configure all this stuff in Vim or Emacs but it's not as straightforward plus it wastes time when onboarding. We'd rather have an IDE like experience.
I don't understand, what config is necessary to work on the same codebase? Whatever program I use to open source code, eg. emacs or vscode, shouldn't matter should it?
The only time I ever had to use vscode working with other programmers was for pair programming, using the vscode sharing thing. Apart for that, not being able to use emacs would be a deal breaker - using other editors is like wading through quicksand for me.
It's not just the code, we'd want everyone on the team to use the appropriate toolsets including debugging and error checking support. They can set it up in Vim and Emacs if they want but it saves time for the team as a whole if we all use a standardized set of tools.
Yes, that makes perfect sense. If they want to set up an alternative editor, doing it on their own time is a reasonable expectation. No question vscode is millions of times easier for juniors.
These kinds of hyperboles are really really bad. You are stating that if it took 1 minute to install a plugin and get to work in vscode, it would take 694.4 days to do the same in other editors? Please use reasonable numbers if you are trying to make a valid point.
Not just 'other editors', I was thinking about emacs specifically. I think my point was fairly obvious. Maybe not a million times, but probably hundreds. Vscode and other modern editors use key combinations everyone knows by default, eg. C-q, C-c, C-v, etc., have gui directory browsing- so there is essentially no learning curve.
It takes weeks (at least) using emacs/vim until text editing/movement starts to pay off. There's no learning curve for `M-x package-install`, but if there is some variable that needs to be customized, like the path to an executable or something, that's a whole rabbit hole to go down, and at some point you need to learn lisp or you'll waste a lot of time being confused by errors.
During the only programming course I took in college, one in which emacs was required, I spent as much time learning emacs as anything else (it was also the most valuable thing I learned so I'm grateful in the long run).
> Having a unified tool set works wonders for group productivity, no more messing around with some employees not having a certain package and others needing to customize their vim configs.
Completely agree: the entire company should be on a common, future-proof, extensible, free platform: Emacs!
I honestly don’t understand why anyone bothers wasting effort on any other editor.
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.
No, good tools absolutely require learning how to use them.
To think that they don't is a maddening take because it has led to the infantilization of applications in so many areas of the software world.
There is definitely a place for simplistic tools that have no customization, no configuration, a single limited way to do anything and no hooks/APIs to modify their internal behavior. Yes, such tools are easiest to pick up and casually use in the limited way they can be used and that's often all that is needed.
But, the world also need professional tools. In the non-software world this is obvious and such tools exist in every profession. Even your hammer example is wrong as the sibling post noted, there are "professional hammers" (nail guns) that require a bit more care to use but are much better.
There is a place for test lights (that anyone can touch to a wire to see if there's voltage). But we can also buy voltage meters of increasing complexity and capabilities. They start to require a little bit of understanding of volts and amps and ohms, but they are so much more useful. But yes you need to learn a little to use them. There are also things like oscilloscopes which an untrained person wouldn't stand a chance to know how to use at first sight. But of course they are vastly more useful once you learn the tool.
Just one random example of thousands. Yes, good tools absolutely require training.
>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.
You mean like a nail gun? The kind that all professional roofers use?
Considering that nails from a nail gun have a habit of following the grain in surprising ways (possibly causing the nail to do a 180 degree turn and find your finger), yes, it is important for a prospective user to "get to know it".
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.
I’ve seen so many people use a hammer wrong. They don’t swing it effectively, hold it too high on the handle, or even use the wrong type of hammer for the job (yes, there are different types of hammers designed for different types of hammering).
And that’s before you go into all the other technologies invented that are evolutions of the hammer, from nail guns to jackhammers.
So any tool that is complicated enough to use that it requires more than 5 minutes to understand can't be a good tool? That is just false.
Obviously vim is not the tool for you (and emacs probably isn't either). You don't like the way they work, so don't use them. They are not bad tools. They are both very good tools. They are just not tools that fit your preferences. They do fit other people's preferences.
There are more complex problems than "nail" requiring more complex tools than "hammer".
And even the hammer metaphor falls apart pretty quickly: compressor driven nail guns are commonly used.
VSCode is obviously has something going for it, else so many people wouldn't be using it. Vi and Emacs are also extremely popular and have been for decades.
This is completely wrong. Basic tools that solve basic tasks are easy to learn and understand.
I use spectrum analyzers to identify partial discharges in high voltage equipment. Sometimes I use a hammer.
One of them require deep knowledge, with the other one I just give the equipment a whack with to see where the fault lies.
An operating theatre is filled with tools that require decades to master and years to learn to use originally. Even if you forget the surgeon's skill there is still the likes of ECMO (run full time by a perfusionist), EMG/NCS (an electrophysiologist) or the old classic, an anaesthetic machine (anaesthetist). Many of the UIs on these are, to the outside eye, downright janky.
Good tools usually have a beneficial tradeoff - it takes a minute or two to learn how to do it, but you have recurrent measureable gains in productivity after that. That includes closing Vim.
I wouldn't put it that blunt but I do agree. The problem are these nerds with seemingly infinite memory. It is almost impossible for them to make a UI for the rest of us.
I tried editing a txt document in vim one time. After gazing at the UI for much to long I had to ask for help because it wouldn't let me edit the txt.
I'm sure your average vim wizard can see no wrong in forcing new users to learn how to engage edit mode by pressing 12 keys simultaneously.
They simply dont get that our brains are like bookshelves that take only n books. If you push more than that onto the shelve other books are falling off on the other side.
I could certainly learn some of vim's functionality but there would be very little disk space left to write the software. I'm seriously more productive using MS notepad or nano. I can totally see myself forget how to engage edit mode in a week or 2. I'm having visuals of picard ordering enterprise to engage
All i need is a shuttle!
The edit mode feels like a child safety feature where I'm the child.
Human children flying Vulkan space ships, think about it.
If non of this makes sense, that is the whole point.
>It is almost impossible for them to make a UI for the rest of us.
Have you considered that their tool is not necessarily made for you? You'd shudder at emacs yet there's still people there that really want it over vim and are more productive with it than most vim and vscode users.
>I'm sure your average vim wizard can see no wrong in forcing new users to learn how to engage edit mode by pressing 12 keys simultaneously.
it's 1 key. It's not intuitive by default tho that's very much true.
>They simply dont get that our brains are like bookshelves that take only n books. If you push more than that onto the shelve other books are falling off on the other side.
If you use a tool every day you're often expected to know a bit about it regardless of which one you use.
The previous poster compared it to a hammer and someone else mentioned a nailgun.
Similarly a an ax is simple but a chainsaw used more plenty by my father...but he knows how to replace and fix the chain, And even beyond that a nailgun and chainsaw are simple simple machines compared to the tooling you'll find in many workshops.
If you processed wood professionally you'd use room filling machinery instead to make boatloads of planks and whatnot in no time.
The thing is. Much of these issues one would encounter with em and things to know them are relatively simple and easy on their own... But seem difficult if you don't know. They're pretty easy to forget if you do it once. But if you've done it dozens of times you just know. Knowing these things doesn't impact the person's ability to learn other related things much. How a new kind of wood to cut behaves or whatever in the same way that remembering that new face and name doesn't obviously directly makes me forget my existing coworkers.
The key for learning a profession is to dump as much knowledge as possible into your 'muscle memory'. there are many operations in emacs and vi that i can do when i want to, but i might not be able to pull up the key sequence to tell someone. Like a musical instrument, the key is practise, practise, practise.
I don't feel like i have proficiency in a language until i have forced myself to speed run a few projects in it. The ideas are important, but it is the ingrained habits that keep the code clean and consistent.
I mean if you don't want to spend so much time studying a given profession, of course. But the neural positioning of generating this text, or transform this text' is different than the neural positioning of 'should this call to this new to me gRPC server be blocking? Timeout? Retries?'
The latter takes thorough focus. the former can be done by muscle memory with practise, and the limit is more on how many new things your fingers can learn in a month, the total of learned things can be quite high.
Reading such posts really makes me wonder how people wrote UNIX (up to V7) with just ed and an ASR33. And productive, they were.
I've seen some old timers on ACME who dislike even the "distraction" of syntax coloring with modern editor such as vim. I wonder how they would fare with something like MS VSCode.
Don't underestimate the complexity of software built in the seventies either for the business, financial or scientific world. We already had virtual machines, HA, realtime and distributed computing back then.
Some code running at CERN or NASA was far more complex than a bluetooth stack, yet was also written with teletypes or ADM-3A style terminals.
As someone who has worked on both sides of the coin in the finance world in consumer credit processing, I think the person you are replying to is more right than wrong, but it's also a matter of how you view the idea of complexity.
I've worked on 30+ year old systems where the code base is absolutely immense, but the <complexity density> of this stuff is very, very low on average compared to the magical bullshit that happens on a simple UI render of some template react app in 2022.
Folks had very little in the way of abstractions at their fingertips, and the languages themselves weren't nearly so helpful in helping you manage complexity, so applications were usually long, shallow, and operating under a litany of fixed boundaries that define and drive a significant amount of behavior for you.
The biggest source of complexity was having to manage your own unique `personal operating system` of bespoke resources at any given time, where each developer was carved into an incomplete walking repository of both business processes and software practices with the passing of each year.
To put it more simply, software can't be more simple in aggregate because we can trivially rely on insanely complex components others have built and made available. Components which were simply not available back then.
Yes, the glue on top might be trivial, but even that frequently isn't.
And if anything breaks down, the humans at the top are normally expected to handle it, no matter where in the stack it is.
I admire what people built with stone tools, but at the end of the day, a modern skyscraper is a marvel of complex engineering with no rival in that world.
I'm not saying that NASA or CERN people were dumb or anything, they were probably smarter than the average dev today. But even a genius can only go so far with limited tools.
An elite slinger from the Roman times will probably lose at least 8/10 against a Russian mobilized soldier with 2 weeks of training, armed with an AK-47.
That's how progress works, we both learn ourselves, and more than that, we make powerful and accessible tools.
Having worked with a handful of terminal CLI purists I'm convinced most of the people who bang the drum hard for vi and emacs aren't nearly as productive as they think they are, and instead evangelize it largely for some mixture of these reasons:
1) They have a strong preference for keyboard only operation
2) It serves as a cultural cachet, or shibboleth, to signal how elite and pure a developer they are
3) they wish to continue working in the same environment they have been for years or decades, and learning new key binds, trying to find equivalent features and testing new features isn't worth some potential benefit
Everything else, like differences in RAM consumed, total install size, etc seem like post-hoc metric seeking for folks who have already decided what they like.
I find that many people "banging the drum hard" for a text editor are falling for the same kind of faulty thinking.
In my experience, the only situations a colleague has been slowed down in a significant way by their choice of editor seem to boil down to two categories:
- Haven't put in the time to actually learn the tool (i.e. using vim purely in insert mode, or VSCode as a plain text editor, constantly going back to a file manager to find and open files) and get stuck in a particularly horrible workflow.
- Burn hours daily fiddling with their setup, chasing perfection.
Neither of these are typically caused by the tool itself. At the end of the day... I'm confident most devs can be quite effective using just DOS EDIT or Notepad if pressed.
As for me.... unless I'm doing something specialized, I catch myself trying to eke out that last 1% productivity boost from my editor and ask myself... is this really the best thing to be messing with? Usually, it's not. Honestly, writing documentation or doing a quick prototype is much higher return.
> 1) They have a strong preference for keyboard only operation
Sounds like having a strong preference for keyboard only to edit text and code is the natural way.
I don't think most vscode user are using mouse a lot either and if they do that, they are doing it the slow and inefficient way as vscode can be entirely piloted with the keyboard as well.
That is kind of a bad example, because installing extensions is something you do rarely. Making that easy is nice, but not a huge productivity win.
I think Emacs also has a lot of stuff for extensions and such built-in, but I'm not too familiar with Emacs. With Vim it's a bit more manual, but really not all that much work. Basically search "Vim $my_language", usually click the first link, "git clone" in your ~/.vim/pack, and you're ready to do for most plugins, which will work out of the box. That you need to spend "hours" on this is just nonsense.
And the last time I tried VSCode with Go I had to spend some time fiddling around with things to make it work too.
What it comes down to is personal preference. Some people prefer A, others B. I strongly dislike VSCode's default settings and need to spend quite a bit of time fiddling with that too. But ... I don't pawn off my preferred way of doing things as somehow objectively superior to anyone else's. There's just one person why needs to use your editor: you. So ... whatever works for you, ya know. I can't believe it's 2022 and we're still doing this "editor war" bullshit.
>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.
Same with Emacs. `M-x package-install`, type, RET.
I think there's a difference in the approaches. Emacs (and vim though I use the former) is like an old multi tool that has been with you on every programming or technical journey you've ever made. Scars, patches, customizations and everything else. It fits like an old glove and in most (though not all) cases, this comfort and the resulting productivity is far greater than a new editor that does "everything right" out of the box.
But I don't want to click (or not even click) and install random stuff from the internet. It's a security, performance and stability risk. My editor should do what I tell it to, not go solo. While I understand your viewpoints, my priorities are just not aligned.
A whole bunch of people still prefer not to have an Appstores in their apps. It's not like this things are god given improvements. Time safer maybe.
People handle their Emacs config files like little shareable babies. That is not even on the same level as 'click and ready' fully unpersonalized environments.
emacs packages is basically the same UX, tho perhaps there are more packages a given person might want for a language. really most packages don't need much config for base functionality.
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 huge security breach.
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.
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.
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.
> 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.
This isn't even true on virtually any macOS terminal, which use Command-C (just like a web browser). The problem isn't the terminal, it is the operating system.
> Platform conventions matter because uniformity matters
Except just as you noted the conventions change across platforms, contexts and over time, so they aren't really uniform at all.
If you're moving between Windows, macOS, and Linux, or between GUI, command line and remote shell (either within or across any of these) you're already context switching on a regular basis. And if you stick around long enough an OS upgrade will come along that moves the window controls and menu buttons around so you need to retrain your muscle memory (and update your end-user documentation).
If anything some of the long-established, old-school conventions are probably _more_ uniform and consistent. E.g. in vi/vim `:w` will save and `:n` will jump to line n - always and everywhere. In a terminal `find . -name foo` will search the filesystem - (almost) always and everywhere.
That sort of thing isn't comprehensive (i.e. it doesn't cover action you'll need to take) but it's kinda nice when it's available. Maybe we'd be better off if select-then-middle-click worked for copy/paste everywhere.
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.
I have C-f mapped to Find and C-v mapped to Paste on vim. It’s trivial to do (one line per mapping) but yes I would be considered an heretic by some vim purists. They tend to go the other way around, using plugins to make their browser behave like Vim. Which makes more sense than it might seem; if you spend a lot of time on the command line vim bindings are better supported than ctrl c ctrlv
> 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.
M-x cua-mode resolves this in Emacs. I don't use it, because I've been using Emacs for slightly longer than the CUA has existed.
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.
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.
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.
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?
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.
