4 ms·
I found the discussion on extensibility vs composability to be really fascinating. The author is right that extensibility gives you less freedom between tools.
by celeritascelery 3y ago
I found the discussion on extensibility vs composability to be really fascinating. The author is right that extensibility gives you less freedom between tools. You can't take magit to vim or helix, because it is an Emacs extension. And each tool has it's own way of extending it, which means you need to learn essentially a new API (if not an entire language) to extend a tool.
However extensibility makes it much easier to move within a tool. The authors sample kakoune config for doing splits is a great example. Since Kak doesn't support splits natively, you have to learn 3 separate tools do the spliting in a WM. In something like Emacs there is only one thing to learn to manage splits on all platforms. And it is using the same extension mechanisms you use for everything else.
I found this the paragraph just before the conclusion to be an interesting demonstration of these trade-offs:
> All of that to say that, the take of Helix is pretty good here, because all of those UNIX problems are not there in that editor: everything runs in the same process, inside the same memory region.
The author spends a lot of time praising composability over extensibility, but then admits that Helix has some real advantages because it is not composed with tree-sitter or lsp, it has those built in. Essentially it was extended with those features, they become part of editor, instead of trying to interact with them in a uniform way.
This reminded me of the xi-retrospective section[1] on modular software. composability works better on the small scale, but struggles when you have many independent things interacting with each other. It is fine for simple things like "using the shell to sort lines" or "bring your own fuzzy finder", but with more complicated integration it starts to falter.
[1]https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.html https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...
- taeric 3y agoI found https://yarchive.net/comp/linux/everything_is_file.html https://yarchive.net/comp/linux/everything_is_file.html a very compelling read today, on similar topics. Specifically, having a base set of abstractions that everything "speaks" is a huge boon that is often hard to articulate. Annoying, as the drawbacks and sheer number of edges is often much more easily described. TO that end, Emacs' "everything is open to everything else" works surprisingly well, once you get used to it. Especially so if you go with not introducing new primitives to makes things happen in the process. Even "async" is relatively easy once you get used to the sentinel approach. Can you imagine a better way? Almost certainly. I have yet to see one survive the test of so many contributors, though.