Hacker News new | ask | show | jobs
by rgoulter 1104 days ago
Analogously, compare Emacs with VSCode.

It's much easier for someone to be productive with VSCode without having to go out of their way to learn much.

Whereas, Emacs' requires much more effort to learn, even just to get started; but is much more extensible than VSCode is.

For the user who doesn't want to spend much time learning, surely VSCode is better. For the user who wants to get the most out of their editor, Emacs is a reasonable choice.

I think Nix is comparable. Much of the time, Nix is quite straightforward to use. But, when you do run into something that's hard, Nix can be very difficult to work with.

Maybe there'll be a tool that's to Nix/NixOS what VSCode is to Emacs; where you get the benefits of a declarative config.
1 comments
themoonisachees 1103 days ago
How is emacs more extensible than vscode when vscode is an electron app in which you're free to do anything a webpage might? I struggle to think of any thing emacs or its plugins can do that vscode extensions can't, and I'd be willing to bet that the extensions are already available and not "you could do it with dev time"
link
kartoshechka 1103 days ago
I think parent poster refers to emacs being essentially a lisp interpreter, plus lisp itself being a literal AST spit out, enabling all kinds of extensibility
link
rgoulter 1103 days ago
e.g. Elisp supports advising functions; so you can hook functions to act around other functions which get executed. https://www.gnu.org/software/emacs/manual/html_node/elisp/Ad... -- AFAIU, VSCode doesn't allow for anything that powerful.

With VSCode, you've got your settings, and you've got the extensions you can install. With Emacs, the line between "plugin" and "configuration" is more blurred; you can write your own commands to cover how you do your work. -- It's more likely that an Emacs user has touched ELisp, than that a VSCode user has extended VSCode.

I recall running into a problem with VSCode extensions where you couldn't ensure one plugin would be loaded before another plugin. (e.g. loading the direnv plugin, before loading some other program which uses the loaded environment).

link