Hacker News Reader

Comment by pierrebai | Hacker News Reader

Which is exactly the reason why... VSCode is winning the editors war.

The main difference is that it chose javascript instead of lisp as its universal language, which, in the current world, is a much better choice for adoption.

Also, saying app can share data easily because the format is text buffer is either a tautology or a non-sequitur: not having a defined format can't be broken, sure, but it also cannot be reliably used. ask anyone who had to maintain bash/awk/perl labyrinthine assemblies...

View on HN

> The main difference is that it chose javascript instead of lisp as its universal language,

That is not the main difference. The main difference is that Emacs can be extended on the fly. While VS follows the traditional plugin approach.

For VSCode to the have the same kind of extensibility it would have to allow opening an inspector on the _running_ instance. Click an element, jump to its source edit the source on the fly and have that change persisted. Or allowing your settings to patch (which by the nature of ES6 modules is not something you will be able to do).

The on the fly extension is crucial for quick QoL improvements to your workflow. You can spend 5 minutes writing a function instead of having to setup a project/plugin to something as trivial as say, copying a .env file and updating some values when you create a [git] worktree.

> Which is exactly the reason why... VSCode is winning the editors war.

The main reason why VSCode is 'winning' the 'editor' wars is because Microsoft is spending tons of money to build a great product. Emacs, vim, and other open source projects can't compete as they don't have nearly the same amount of resources. They have healthy communities and are thriving FLOSS communities but people who are scratching an itch won't be writing monthly tours of new features like https://code.visualstudio.com/updates/v1_52 f/e.

> ask anyone who had to maintain bash/awk/perl labyrinthine assemblies...

Text in Emacs is richer than plain-text. You have overlays to annotate it with metadata, text properties, you can attach callbacks to it, etc. It is only at the boundaries that you have to resort to plain-text for interoperability purposes.

This means it is easy to inter-op with CLI utils but present a richer, more powerful interface. Ej. dired uses ls.

> The main reason why VSCode is 'winning' the 'editor' wars is because Microsoft is spending tons of money to build a great product. Emacs, vim, and other open source projects can't compete as they don't have nearly the same amount of resources

It doesn't seem to be the main reason, otherwise how can you explain Sublime text popularity prior to VSCode?

Sublime scratched an itch for a lightweight batteries-included text editor. As such, it competed with vim more than with Emacs. VS Code, on the other hand, tries to be your one-stop shop for code-related things, which makes it play in Emacs's sandbox.

> The main difference is that it chose javascript instead of lisp as its universal language, which, in the current world, is a much better choice for adoption.

That at best bifurcates the community (possibly along the age lines). I for one consider it to be a bad choice for me personally. JavaScript ain't a particularly pretty language. And it's nowhere as nice as Emacs Lisp.

> saying app can share data easily because the format is text buffer is either a tautology or a non-sequitur

I'd agree, though with caveat that an Emacs buffer is not just an array of text. It's an array of text with bells, whistles, and a semantically well-designed API layer. This lets extensions to mostly compose nicely.

But I'd say the more important feature is that nothing is sandboxed. That means extensions can detect and work around potential conflicts with other extensions, up to the point of extending or replacing any function such conflicting extension uses (though with proper extension design - which is by this point a part of Emacs culture - this is rarely needed). It's easy for any extension to expose an API layer for interop, and Emacs itself provides enough of an API surface that usually you don't even need to do that explicitly.

More importantly, I myself can trivially extend or fix extensions as well. Something conflicts and errors out? Flip a debugger trap, wait for it to error again, poke around the source, find the culprit, patch it in your config. Granted, you need a passing familiarity with Emacs Lisp for that (though IMO, one should consider getting comfortable with Emacs Lisp a part of becoming a power user of Emacs). But you can do that, quite easily, and the entire environment supports you in doing this.

> The main difference is that it chose javascript instead of lisp as its universal language

The main reason is that it's backed by Microsoft, both because of the investment that provides and the visibility it provides.

JavaScript over Lisp probably helps, but if VSCode had Visual Basic as it's extension language it would still be doing strong, and not because VB is a good or popular language independently.

I just want to underline your point on it having corporate backing.

Commentary on our industry seems bent on the idea that things succeed in inherent quality. Reality seems to be full of contrary examples.

Programming languages too. It seems to me that popularity of programming languages is directly tied to amount of corporate backing behind them. There's plenty of popular languages that have a large company sponsoring its development and marketing.

Agreed. I've taken to this idea even stronger. "Simple" languages are believed to be simple mainly off the propaganda that pushes that they are simple.

> VSCode is winning the editors war

In what sense is there a "war"? That's a serious question. Emacs, VS Code, and quite a few of the other popular editors are open source. You can download them and use them. I have both Emacs and VS Code on my machine, and I use both of them, but for different purposes.

Now, if you wanted to talk about a war between open source and traditional closed-up-tight, walled-garden commercial software, I could get on board. It's really hard for me to understand your framing when you have freely available products that are not in any way exclusive.

On your other point, if I were to speculate, I'd say VS Code's main advantage is that it doesn't have a 1970's graphical interface. Port GNU Emacs to Monaco, give it some good default settings, and see what happens to adoption.

War as a metaphor? I mean, have you ever seen two editors battling out in the field? No.

The war is in usage % among users. VSCode is the most widely used editor by far now, reaching over 51%. [1] Usage converts into further growth, having more and better support from extension developers.

[1] https://blog.robenkleene.com/2020/09/21/the-era-of-visual-st...

There is no war. VS Code created the language server protocol, which works great inside Emacs. VS Code's existence has made Emacs even better.

If it were a war, they'd just DDoS gnu.org or something, not make Emacs better.

VSCode is winning the war that Sublime Text (and it's python api) was winning a few years back (and perhaps Notepad++ before that). A few years from now VSCode might still reign supreme... or it might not. If you're fine jumping to the next winner every few years, great. If you'd rather just invest in one editor platform and stick with it for a couple of decades, and know you can rely on it to stick around and be supported that long... well, you might want to take a look at emacs.

I think that elisp is one of the many a strengths of Emacs, along with it's strong extensibility, customization, and general user freedom. I think language choice is a smaller part of the pie compared to Microsoft's backing, networking effects within companies, and visual appeal and design.

However, I do agree with you that Emacs onboarding process can be difficult if you don't know lisp, in that you have to now learn a new language and the API for interacting with the editor. That is why some friends and I recently decided to embed JavaScript/TypeScript into Emacs as a means of controlling the editor [1]. We will see if we can prove you right.

[1] https://github.com/emacs-ng/emacs-ng

Reply on news.ycombinator.com