The Atom developers made some technology choices that in retrospect were ill-advised, CoffeeScript being the worst of them and splitting everything into dozens of packages a close second. They tried to backpedal on both of these later on, but by that time VSCode, with its far superior engineering built around TypeScript, was rapidly taking over.

Of course, the GitHub acquisition was the last straw, but to be fair Atom was already pretty dead by then.

While the Atom project ultimately failed, it did give us Electron and Tree-Sitter, two technologies that will certainly outlive it.

That architecture has a major flaw though. A default install was fast, but a real configuration with all the plugins ended up quite slow.

VSCode's architecture worked much better in real world configurations, and it turns out better performance wins in the editor space, even if it meant losing certain customizations (up to a limit). The architecture also allowed seamless remote editing, something Atom never could have done.

The interesting thing has always been that both were built on Electron. Atom's developers had built all the tools and primitives needed, they just didn't have the understanding of the long term ecosystem effects of their design.

VSCode did almost everything right: The choice of TypeScript as the base language (with which VSCode has a symbiotic relationship), the limited, slowly expanding extension API, LSP, the monorepo, the monthly release cadence, the built-in terminal, and the list goes on and on. They turned Electron's strengths into super-strengths, and deftly engineered around Electron's weaknesses. VSCode is the greatest productivity tool in the history of software engineering, and it fully deserves the dominant status it has today.

Compilers, operating systems, browser engines (unfortunately) and reverse engineering proprietary hardware/firmware are all significantly harder challenges than writing an IDE.

in fact there have been excellent IDEs around for decades before VSCode came along. Yes the industry lacked an LSP but that doesn’t mean that languages severs didn’t exist before then, there just wasn’t a standard before so everyone did their own thing.

Having built in terminals isn’t a new innovation either. That is and always has been the norm.

And most of the other accomplishments aren’t any more unique either (eg lots of software projects have monorepos).

It’s ironic that you say VSCode is the greatest productivity tool in the history of software engineering when VSCode is dependent on so many pre-existing technology’s like Electron, web standards, GUI frameworks, compilers, operating systems, device drivers, etc. in the grand scope of the engineering, VSCode occupies a very small fraction of engineering effort and in a niche that was already crowded before it even entered.

Is it the best IDE on the market? some might think so. JetBrains certainly have their fans too. But even if it’s the “best”, it’s extremely hard to argue that it is that far ahead of the competition and that innovative to deserve the accolades you’re describing.

And I would rather say that Atom was an engineering feat in terms of that they developed Electron and tree-sitter.

One also has to take into account that Atom started long before VS Code so for sure the VS Code team could make much more informed decisions and learn from the "failures" of Atom. And things like TypeScript wasn't around when Atom started.

They were very much contemporaries of one another, though obviously TS popularity has surged since 2017/2018.

If my goal is to program in language X then I should be able to grab a product and get started without fuss. VSCode is a whole lot of fussing about.

That being said, it’s very stable and performs well—I will give the devs a massive kudos for that. Also if I did a lot of NodeJS dev work it would probably classify as a proper IDE for that.

But all-in-all I would prefer something purpose-built with minimal configuration out the gate for development workloads (C/C++, Java, C#) and a more minimal editor (nano, vim, eMacs, notepad++, geany, etc) for editing configs.

> it’s 2022, why not favor GUI configurations?

VSC provides, at all the (four) levels, both GUI and text-based configuration editing.

> JSON is ugly

You can't get any simpler than JSON. The VSC designers have actually been admirably pragmatic, and opted for JSON5-ish, which supports comments and terminal commas (in arrays).

> too powerful to edit simple configs

Editors are complex by nature; other editors are not different.

It is actually quite the opposite; one can edit a subset of options in the GUI, then observe the changed values only in the JSON editor.

> it auto-updates every time I start it

VSC updates once a month, plus once or twice for patch releases in-between. It auto-updates every time if one opens it two/three times per month.

Plugins do auto update, but one can disable this, if they want.

> I should be able to grab a product and get started without fuss. VSCode is a whole lot of fussing about

There is no default configuration that satisfies all the users; this is not specific to VSC.

Actually, the extensions experience is probably the most polished out there, and this matters, because if one makes something easy to use, users will use that feature more.

Actually a plain text file containing a JavaScript object is simpler and prettier than JSON.

Not universal across languages though I suppose.

AFAIK the difference between JSON (as used in VSC) and a Javascript object are minimal (no quoting for keys, possibly minor other differences) and using a JS object should have significant advantages in order to replace a de-facto standard.

some will argue that scripting would thus be possible if the config was simply JS but that is a rabbit hole both on the debate itself and then the potential compexlity of config; there are trade-offs for/against but not a settled matter IMO as there are major projects like neovim that support full fledged config scripting (in the case of neovim they allow use of Lua)

What I "like that much" is the pragmatism (which, again, I didn't write) of the choice to break the JSON standard and introduce features that are significant for configuration files (comments, essentially, and to a very minor extend, trailing newlines in arrays).

I've never seen Deco, but it's not an established standard. Based on the repository, it has no grammar and it even leaves details to the implementations (e.g. multi-line strings). The simplicity comes at a cost, for example, to represent leading whitespaces.

If one asks 10 developers which format they'd use, they'd choose 10 different ones, therefore a certain level of standardization is required.

GUIs can change layout and users have to spend time learning where things are. Someone who is using a text editor is probably comfortable editing text.

Unfortunately, even though we engineer with code, reading long streams of text is actually a terrible user experience by itself.

Good user experience should hold the user’s hand through the process so they don’t need to sift through a haystack of configurations.

VS Code has the power of emacs and an autogenerating UI which maps to the configuration files. To me, that’s the easy way out—make the UI map one-to-one with the data underneath, obviating the burden of considering the UX of each configuration path, and missing out on the benefits of good UX.

With VSCode these wrong decisions are very few and minor compared to the brilliant choices made by the team. That's why it is right to cite it as an engineering excellence project.

Ultimately they’re both very fancy text editors, not ‘the greatest feat of modern software engineering’.

I’d happily switch from Sublime to VScode or EMacs or any of the other umpteen code editors. I’d shudder to have to go back from Git to SVN. Even Mercurial seems milquetoast in comparison.

Similarly, what about the Linux kernel?

What about C?

What are some of the Git features that make a big difference to you? I use them on different projects and I end up using them both in the same very basic way (check out code, make changes, check code in).

One place where Subversion historically did better with respect to merging is avoiding merging by allowing you to lock files. We use this with some binary files in our repository. About a year ago Git added similar functionality but I haven't had the chance to try it yet.

I agree.

Lots of people talk about how great VS Code is. But how many of them would sing that tune if they had to pay for it?

VS Code's killer feature isn't customization or extensibility. Clearly it isn't speed or stability. It's price.

I think it has gained its place in the eternal emacs vs vim discussion, and that's a feat to be reckoned. In 15 years there will be other fancier editors but VS Code will still be there.

I can buy that people like it, I don’t dislike it, but it also isn’t sliced bread. There’s peers in the market that are ahead in various ways, so VS Code isn’t the end all be all, even if it is cool.

I realize sshfs provides something similar, but it has a few rough edges compared to the vs code implementation.

Emacs supports editing remote files via ssh, ftp, or scp; one simply refers to filenames like: /ssh:host:filename or /ssh:user@host:filename. It's pretty simple and transparent. One can browse remote directories, etc.

Likewise editing a local file under a different user id is also supported using paths that look like /sudo::filename.

See section 18.5 Remote Files in the Emacs user manual[1].

[1] https://www.gnu.org/software/emacs/manual/html_mono/emacs.ht...

Something I have yet to try is using an lsp server with a remote project. I'm not sure how some, like the rust lsp, that need the whole project (at least w/ emacs it doesn't yet support isolated files), would work.

The VSCode team didn't have to make Electron. They got to use it, though. Along with the various lessons learned by the Atom project.

And in terms of "well it depends on other technologies for it to work", this describes pretty much any innovation in software since the very earliest computers, including all the examples you listed.

Also I dispute that VS Code is the quickest editor out there. It’s faster than its Electron counterparts but that’s a pretty low bar. This isn’t a dig at VS Code, it’s my default IDE (well that and vim). But the largest part of the reason I use VSCode is because it’s free.

That, for me, is its real advantage. But that’s not an engineering achievement.

> browser engines (unfortunately)

I often wish it wasn't so but the reality is that a shit ton of development has gone into browsers and in many cases other areas just aren't comparable. Even more so considering most resources go into proprietary technologies.

> reverse engineering proprietary hardware/firmware

As as side note reverse engineering hardware can certainly be very hard. It is also something that can gather far more credit than it probably should compared to actually engineering a solution in the first place.

Open source: there’s loads. I’m very surprised to read that comment here of all places. But even if we take your comment at face value, licensing has naff all to do with engineering impressiveness.

Cross platform: again I’d beg to differ there there aren’t many. And again I’d also like to point out that something not being cross platform doesn’t negate it being impressive engineering.

Extensible: this is another metric you’ve added that I disagree is a requirement

Used a modern stack: this absolutely shouldn’t matter when one talks about “of all time” like the GP was. Otherwise you’re intentionally skewing the results to only include recent developments.

> I often wish it wasn't so but the reality is that a shit ton of development has gone into browsers and in many cases other areas just aren't comparable.

The point of the GPs tangent was comparing all software engineering.

Sure, if you say VSCode is the greatest software engineering project of all time then suffix that comment with a dozen footnotes describing a dozen exclusions to the scope, then the claim might be more reasonable. But that wasn’t what the GP said and nor is it then “greatest”.

Frankly though, I wouldn’t even extend that description of his to modern IDEs specifically, let alone the broader context they intended.

Well, that shows the bar for Web Developers these days are so low, that even VSCode could even be on the list of "one of the greatest pieces of engineering of our time."

Web developers are so abstracted away from everything, their understanding of computing and software is really hurting the industry. And the sad part is not only are they the majority in software development, they are also the most well paid and vocal.

Obviously some compilers and OSes and IDEs are larger in scope than others, but all else being equal, if I had to pick one to write and it was really important to deliver something good, I'd rather do one of the former.

(This applies to any kind of GUI program that needs to be very feature-rich in order to meet the needs of power users, and where user productivity is at a premium because those users spend all their time in it. IDEs are just the subcategory of that that we as programmers most often use.)

[1] https://wiki.alopex.li/LetsBeRealAboutDependencies#yeah-but-...

The later was by far the easiest for me.

Maybe you’re brain is wired differently but I can only speak from my own experiences.

The technical issues are also sort of different, fixing latency problems is a totally different type of problem that developing a framework for how an optimizing compiler should do its thing. Both valuable and hard things to do, hard to come up with a metric to rank them.

I wonder what everyone's favorite IDE is. I don't think I could put my finger on a single one and claim that it's the best.

I really liked Lazarus (for Pascal), because it's perhaps one of the snappiest tools I've used for a language that also compiles pretty fast. Though it's certainly not as modern or smart as JetBrains products.

I rather liked NetBeans (for Java and PHP), because it's truly free and can be relatively lightweight. The interface doesn't feel overbearing either, you get some framework/library support out of the box and even projects like jMonkeyEngine built upon NetBeans for their game engine editor. It's like libre JetBrains lite, but struggles with larger projects.

I rather liked MonoDevelop (for C#), because it felt like the .NET equivalent of NetBeans, was lightweight, functional and just worked without getting too much into your way. That said, it never really got as much attention as other products in the space (Visual Studio or JetBrains Rider).

I acknowledge the success of Eclipse (for Java and other languages), because I've seen that platform be used for anything from being an IDE for programming, to niche modeling tools and graphical programs. Some also swear by its incremental compiler (for Java), but personally it feels sluggish to me (like running JetBrains IDEs with low RAM) and its stability is inversely proportional to how many plugins you have.

I acknowledge the success of Visual Studio (for .NET and other languages), because when your platform is a walled garden, you can make sure that the experience is focued on doing things within it decently (like XCode, I guess), even though sometimes the IDE felt similarly heavy to JetBrains offerings and was more opinionated towards what you can do with it, as well as the platform support.

I like JetBrains IDEs (IntelliJ and their other offerings), because they have perhaps the best autocomplete and code refactoring/inspection tools out of any other solution out there. The plugin ecosystem is rich, the language support is pretty great, the experience across various languages is similar enough. Though the obvious downsides are large system requirements (you need enough RAM and project indexing is slow, having 6 Java projects open and 2 front end projects open is a pain), bad run configurations (that making sharing run configurations across Windows/Linux really hard because of interpreter selection for scripts etc.) and confusing menus (due to how much functionality there is, a bit like Visual Studio, though the menu structure changes for different IDEs from them as well). The benefits still outweigh the negatives and so I pay for all their tools.

I like Visual Studio Code as a text editor (for anything really), but it feels like some of the refactoring and code editing support is lacking, especially when working with enterprise codebases. You can get pretty close to a fully fledged IDE with it, but at that point you're also trading some of the performance and lighter footprint away. Regardless, most of my projects have a .workspace file in them and I use Visual Studio Code together with JetBrains products.

I like other attempts at feature filled text editors as well, be it Fleet (though was a bit too unfinished last I tried their preview), CudaText (really interesting project with lots of nice features) or anything else, really.

At the end of the day, there is no single best IDE, just different ones that are suited for different tasks.

Edit: actually decided not to include the nano vs vi/vim discussion, since that's not super relevant to the discussion. Either is fine, I like the simplicity of nano more.

VSCode delivered a fantastic user experience. It reached a product market fit other editors could only dream of (let alone any editor based on browser tech). This, must have required engineering smarts and very thoughtful collaboration between product and engineering.

Hard engineering = delivering the best possible outcome within tight constraints/requirements. I’m sure the VSCode team was trying to hit a very specific number in responsiveness, startup time and memory usage.

Yes, compilers fall in that category as well as modern chip manufacturing (single digit nanometer fab FTW!). Those folks are the unsung heroes. However, we cannot discredit the fantastic product experience of VSCode. It was not possible without some innovation, clever engineering and a well thought out architecture. (I am sure they learned from Atom’s failings)

Update: > The VSCode team didn't have to make Electron. They got to use it, though. Along with the various lessons learned by the Atom project.

Yes! They are progressively a huge leap forward, built on the contributions of others before them. Now the VSCode framework has spawned a new generator of tools (such as Obsidian).

That must be one of the saddest things I read this month.

It’s just free.

What people mean when they say “I can’t believe how good this is” is:

“I can’t believe how good this is for something I got for free”

That’s not engineering excellence. It’s just engineering; being given away as a loss leader.

Vscode is good and well maintained, but that’s because a lot of money is being spent making it so.

Enjoy it; there’s no harm in taking money people are giving away. …just don’t presume they’re either a) doing it for love, or b) going to keep doing it indefinitely.

If the current 'trajectories' remain roughly the same, VSCode will leave Visual Studio entirely in the dust in a couple of years.

Someone should write up the story of how it started, and how it got to where it is. The backstory is fascinating.

Literally never would be my answer.

People like vscode because of the time and effort that has been spent making it friendly and approachable, yet still powerful.

Those are not just things that magically happen.

They didn’t happen because it’s free.

Those are things you get from a paid product team that prioritises issues, ux, etc. and a company that pays to implement them.

It's pretty damn seamless with Vim. I code on a Mac these days, but was using Windows (w/ WSL) and Ubuntu about 50/50 before that. The same Vim (neovim) config script followed me everywhere.

This seems like a reflection of your environment. This has happened to me more than once with both Vim and Emacs (and not just at a Vim conference:-D). The environment at the time one was a C++ shop, another was a Ruby conference. For example people were amazed when they heard about how you can call vim APIs with Ruby!

The thing that surprises me most is the fact that people don’t want to learn the tools. I get the point that Emacs/Vim ecosystem is difficult to get used to because of well, multiple reasons. But it worths the time because these tools are amazing. You need to invest a couple of hours in Vim, probably some more in Emacs, but it’s just one time investment and then you have an instrument (or two) to rely on.

That said, the Python IDE market has been sadly underfed for surprisingly long.

> Maybe she is more than a president. Maybe she is an idea, a world-historical heroine, light itself.

No criticism meant of either VSCode or Hillary Clinton, but sometimes fans take things a bit too far.

Of course, this is an earlier generation. But if the commenter is correct that VS Code is one of the greatest pieces of engineering of our time, then what the heck are we doing. And if the commenter is incorrect, then what the heck are we doing as a community in our duty to educate to the extent that the commenter doesn't realize that massive projects like this have been implemented, and continue to be implemented.

We have rockets that land by themselves, trucks making cross-country autonomous trips without intervention, multiple systems that can securely run arbitrary sandboxed code from anywhere in the world by simply typing a URL. I'd want someone to be excited not by an IDE for an IDE's sake, but what they can build with their IDE.

On the other hand, an equally valid measure of impact is utility * number of people. While things like self-driving trucks are extremely cool, as of today their overall impact is quite small. VSCode impacts an enormous amount of people every single day and saves them a ton of time.

So while VSCode is nice, it's not even the most impressive piece of software bearing the Visual Studio branding.

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.

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.

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.

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".

A far cry from the days of sublime text’s regex-based autocomplete

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.

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.

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.

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.

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`.

I think `:packadd` or something may be the equivalent for vim.

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.

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".

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.

> 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.

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.

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:

https://marketplace.visualstudio.com/items?itemName=jeffgran...

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.

Then again, I might pre-date the which editor to use and how to configure it era.

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.

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.

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).

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.

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.

You mean like a nail gun? The kind that all professional roofers use?

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.

And that’s before you go into all the other technologies invented that are evolutions of the hammer, from nail guns to jackhammers.

> Wrong. Good tools don't require that.

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.

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.

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.

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.

of course it could always be more conplex but there is no need to expose that in the ui by default

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.

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.

Their constraints were much harsher, but the fact of the matter is the end result was rather simple by today's standards.

I think just the Bluetooth stack in a modern OS contains as much code as an entire Unix kernel from any time up to 1990 or so.

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.

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.

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'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.

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.

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.

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.

Also known as "spitzensparken blinkenlichten"

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.

Same with Emacs. `M-x package-install`, type, RET.

That is true but not in the way you think ;)

"I use Linux. One of the libraries that Emacs can use to communicate with the hardware."

Because that sounds way better than any of the options I'm aware of.

And there are good reasons to prefer the gui version: https://irreal.org/blog/?p=5835

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.

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.

On macOS there's an extra set of keys so Cmd-v is paste and Cmd-c is copy.

I think I committed that to muscle memory so long ago that I never really think about it unless someone asks.

Not sure about Windows as I haven't used it professionally since 2006 but I'd guess it's the same as Linux.

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.

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-t...

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?

It's not. It's not even the greatest piece of engineering to come out of Microsoft - that's probably Windows NT. But here are just a few examples of things I think are better:

* Millau Viaduct

* The Linux Kernel

* The Bugatti Veyron

* Pretty much any NASA Mars mission

That's not to say VSCode is a bad editior, it certainly isn't. But lets have some perspective.

Its good, but not that good. There are still some pretty basic features that full fledged IDEs have - like multi window/display setup. And before someone suggests opening another instance - no, that is not enough and creates some synchronization issues that are no-go.

It also handles huge files very badly - try opening up 1-2gb XML files. It will either ask for more RAM, and crash. Or open it and disable all formatting options. Mind you that other editors can handle such files.

Or try to do a complex multiline regex find and replace - it will just sometimes crash outright on bigger files.

VSCode does this already, if it detects a new language it suggests installing a new plugin. I don't know the criteria it follows to recommend a plugin, perhaps it only does it with some official plugins, but it has showed me this a few times.

While Emacs isn't quite as heavyweight as it was 25 years ago (hooray for Moore's Law), it still makes me grin to see Emacs fans sneer at the resource usage of a modern Electron-based editor.

One such example was the cursor blinking causing hight cpu usage - https://github.com/Microsoft/vscode/issues/22900 I'm assuming they've fixed it?

Electron in general continues to be a bloated memory hog and inefficient. I think the real interesting thing is how good it is despite the runtimes/frameworks they are using, not because of them. It's more an example of there's no such thing as the "right tool".

I don’t know… things like vertically landing rockets, the Large Hadron Collider, inflating space stations, CRISPR, mRNA vaccines come to mind among many other things that surely surpass VS Code when it comes to engineering marvels.

edit: Seems it was not.

peoples lives are more important than a few hours of a programmers life getting used to vim (or any other non VSCode editor)

EDIT: Even millions, and thats only one of thousand technologies that improve our life (expectancy)

Software runs the world. It runs your healthcare. It runs medical research. It runs space exploration. It runs every science megaproject. None of the engineering feats mentioned above would have been remotely possible without modern software.

And modern software is built with tools like VSCode. In fact, I can pretty much guarantee that VSCode was and is involved in the development and maintenance of every single project listed above.

Software controls lives. Software saves lives. Software is every single bit as important as medicine. If all software suddenly stopped working, civilization would collapse and hundreds of millions, if not billions, of people would die.

It wasn't always so. But it certainly is today.

https://www.cidrap.umn.edu/covid-19-vaccines-saved-estimated...

That's too obvious of a troll, please, stop here for a second, take a deep breath and reconsider. It's okay, you can let go of your past mistake, nobody will blame you.

https://news.ycombinator.com/item?id=33995265

Emacs would like a word with you.

Emacs has around 6000 packages available from the most common repositories. Nine years ago Emacs had over 1.6 Million lines of code. It would be much larger now. How many lines of code in VSCode? I don't know.

However, consider really large projects in lines of code (see [1]):

     Average iPhone app: .... 40,000

     Space Shuttle: ........ 400,000

     Windows 3.1: ........ 2,300,000

     World of Warcraft: .. 5,250,000

     Android OS: ........ 11,800,000

     F35: ............... 24,700,000

     Windows 7: ......... 39,300,000

     Facebook: .......... 61,000,000

     Google: ......... 2,000,000,000

[1] https://thenextweb.com/news/google-requires-5000-times-code-...

Even if it would be running natively, the statement'd be still highly debatable.

But it's Electron based and using TypeScript, which means it uses a lot more electricity than a native solution would (about 20 times [1]), wasting precious resources. Now consider the fact that this is a product of a company that states "to ensure that technology is inclusive, trusted, and increases sustainability."

The only amazing thing here is the level of hypocrisy, IMHO.

[1] https://thenewstack.io/which-programming-languages-use-the-l...

> VSCode is the greatest productivity tool in the history of software engineering

VSCode just seems like an IDE to me. Here's some things that are either better feats of engineering or better for software productivity:

- moving from line-based editing to screen-based editing

- any mainstream database

- any mainstream browser

- compilers

- linters

- any mainstream OS

- continuous integration

- headphones

- big monitors

- stack overflow

- any graphics driver

- any mainstream 3D platform (Unity, Unreal)

- version control (edit: added, how could I have left it out??)

I'm team Vim so I'm obviously salty, but even so I think you're going a little overboard here haha. I don't even think this about Vim!

Plus it's freeeee... because as a software behemoth with 1 trill marketcap you have to ruin smaller companies, because why not.

Surely that honor goes to compilers, right (take your pick which one is the greatest)?

Sure, VSCode starts faster than Visual Studio, and has better IDE features than (pre-lsp) Emacs, but all of that dwarfs compared to the productivity increase of not writing assembly.

LOL. Do you work for MS? This is a bit thick, even for hyperbole. Personally I find IntelliJ to be superior to VS Code.

According to whom? Personally, I find Jetbrains products a far superior experience.

I feel this is a slight overestimation of VSCode’s design.

Really?

Sorry, this was the bit I was responding to. I should have quoted it in the original.

This statement is false.

lmao

There is nothing they've done with it that is notable or new, typical micro$oft nonsense.

Atom wasn't just "built on" Electron, they made Electron.

Electron was made from Atom, literally. Electron was originally called Atom Shell https://www.electronjs.org/blog/electron

One could have created a library which conformed to some specification, written the library a single time, then compiled it for different platforms. Editors could then have loaded that shared library and used it just as they wrote in support for a language server. There's no need to get a network server involved.

You still have the majority of development effort in the library, instead of individual text editors. You still have the joy of a nearly pure piece of code, without OS-specific paradigms like networking which impede progress. You still have a simple interface with the editor.

I see exactly zero benefits of having a language server over a traditional shared library, except with a network server you make a trade off where you gain latency and other networking problems, and you gain absolutely nothing.

I don't even know of any central language servers, which were one of the core benefits of the LSP design. "ooh we can all share a language server which is kept up to date independently of our editors! squeeee!" Where's that? Why is that a benefit at all? Presumably you'd still need to shut it down to update it, and someone has to manage it.

The experience that people using editors got when aeditor developers started thinking about how to do something better is what the users love, not the LSP itself. LSP triggered this change in thinking, but anything could have, and I'm honestly surprised that nothing else did prior to LSP.

> A central server uses an Objectstore database to tightly integrate compiler(Lucid C++ Compiler), editor(emacs), debugger(gdb), and browsers

https://www.desy.de/user/projects/C++/products/lucid.html

https://en.m.wikipedia.org/wiki/VHS

https://en.m.wikipedia.org/wiki/Betamax